[Xen-ia64-devel] Re: [patch 00/15] ia64: kexec: Map EFI memory in the same location as Linux

[Alex Williamson <alex.williamson@xxxxxx>]

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.

Attachment: zx6000_base.txt
Description: Text document

Attachment: zx6000_kexec.txt
Description: Text document

Attachment: sd32_base.txt
Description: Text document

Attachment: sd32_kexec.txt
Description: Text document

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel