On Tue, 2008-03-04 at 12:27 +0900, Simon Horman wrote:
> Hi,
>
> This series is what I believe to be a fairly complete set of patches
> to map
> EFI memory into the same location that Linux does. The memory is
> protected
> by an RID so that it doesn't conflict with domain memory - which also
> protects it from malicious access from HVM domains.
Hi Simon,
I'm still seeing problems :( On my zx6000, SAL calls still fail to
work after the entire series is applied. This should be reproducible on
any rx2600/zx6000/zx2000 with firmware 2.31 (I think). Console log
attached. Also, on a superdome partition, I get stuck here after the
last patch is applied:
(XEN) ACPI: IOSAPIC (id[0x18] address[00000f8910018800] gsi_base[274])
(XEN) ACPI: IOSAPIC (id[0x19] address[00000f891001c800] gsi_base[285])
(XEN) 8 CPUs available, 8 CPUs total
(XEN) MCA related initialization done
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) CPU 0: base freq=200.000MHz, ITC ratio=15/2, ITC freq=1500.000MHz+/-750ppm
(XEN) Time Zone is not specified on EFIRTC
(XEN) Time init:
(XEN) .... System T[HANG]
I tried to do an INIT, but didn't get a log. Console logs attached,
note that it reports a PAL call failing along the way.
I also noticed that my systems failed to boot after patch 13/15. On
my zx6000, I got this far in console output:
(XEN) Init boot pages: 0x40ffd28000 -> 0x40ffd80000.
(XEN) Init boot pages: 0x40ffe80000 -> 0x40fffb4000.
(XEN) System RAM: 10206MB (10451392kB)
(XEN) size of virtual frame_table: 25584kB
(XEN) virtual machine to physical table: f6fffffff7e00098 size: 5200kB
(XEN) max_page: 0x103ffed
(XEN) allocating frame table/mpt table at mfn 0.
Then it took an MCA:
GRs NaT bits 0x0000000000000000
PR (Predicates) 0x6569a0155aa61319
BR0 0xf00000003fadffe0
RSC 0x0000000000000003
IIP 0xf400000004004c60
IPSR 0x0000000800000000
IFS 0x8000000000000000
XIP 0xf00000003fae0100
XPSR 0x00001210084a2010
XFS 0x800000000000048d
BR1 0xf00000003fac8010
Static General Registers (GR 0-15)
000-003 0x0000000000000000 f00000003f930000 0000000000000100 0000000000000200
004-007 0x00000000ffdc5c30 00000010084a2010 0000000000000000 f2000000fed00000
008-011 0xffffffffffffffff 0000000000000000 0000000000000000 0000000000000000
012-015 0xf00000000413bc00 f000000004134000 0000000000000208 0000000000000105
Bank 0 Static General Registers (GR 16-31, bank 0)
016-019 0xf4ffffffffff0360 0010000000000661 0000000000000000 0000000000000018
020-023 0xf00000003f930000 0009804c8a74433f 000000000000001e 0000000000000000
024-027 0x0000000000000000 0000000000000000 0000000000000da0 0000000000000003
028-031 0xf00000003fae0100 00001210084a2010 0000000000000000 6569a0155aa61319
0xf400000004004c60 <dispatch_to_fault_handler+64>:
[MMI] adds r16=1492,r16;;
It looks like we took a fault out of firmware (0xf00000003f......). The
chipset error log shows that we apparently tried to do a physical access
to that address in r16.
The good news is that newer boxes like an rx6600 and rx3600 booted
fine, except for the patch 13 issue. Where do we go from here? Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
zx6000_base.txt
Description: Text document
zx6000_kexec.txt
Description: Text document
sd32_base.txt
Description: Text document
sd32_kexec.txt
Description: Text document
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home