WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Thu, 9 Aug 2007 13:54:16 -0400
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 09 Aug 2007 10:55:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2E0D61D.13E50%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Keir Fraser <keir@xxxxxxxxxxxxx> wrote on 08/09/2007 09:33:01 AM:

> I'll wait for the real root cause to be discovered.


We have two blades of different type where we saw the problem with the time going backwards.

I used one of them to find out what is going on and where also the previous xm dmesg dumps are coming. I gave that blade a BIOS update two days ago. On this one Xen parsed the DSDT as the FADT (see posted xm dmesg), but in the meantime this has corrected itself (no idea what triggered this) and now the correct table is parsed and the correct PM-Timer port is picked up - the same as Linux has found out. So the first blade has become useless for this type of debugging.

The second blade is up-to-date in terms of BIOS and I even went into the BIOS setup to give it a chance to maybe correct some things from a previous update. On this one the allegded FADT's signature is 'A_AD' and a bogus timer port is still picked up there (0x4000 0837), while Linux (2.6.20) gets the port right (0x588) as it seems.


On this second blade I now call the function parsing the fadt multiple times, and here is what happens:


(XEN) System RAM: 1023MB (1047860kB)
(XEN) (1) Mapped 0xfdfc0 to ff0fdfc0
(XEN) ACPI: RSDP (v000 IBM                                   ) @ 0x000fdfc0
(XEN) (2) Mapped 0x3ffcff80 to fff9bf80
(XEN) (2) Mapped 0x3ffcff80 to fff9bf80
(XEN) sdt_entry[0].pa = 0x3ffcfec0
(XEN) sdt_entry[1].pa = 0x3ffcfe00
(XEN) sdt_entry[2].pa = 0x3ffcfdc0
(XEN) sign: RSDT; name=RSDT0
(XEN) ACPI: RSDT (v001 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @ 0x3ffcff80
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
(XEN) sign: FACP; name=FADT
(XEN) ACPI: FADT (v002 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @ 0x3ffcfec0
(XEN) std_entry[0].id = 7,matches sign FACP
(XEN) (2) Mapped 0x3ffcfe00 to fff9be00
(XEN) (2) Mapped 0x3ffcfe00 to fff9be00
(XEN) sign: APIC; name=MADT
(XEN) ACPI: MADT (v001 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @ 0x3ffcfe00
(XEN) std_entry[1].id = 1,matches sign APIC
(XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0
(XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0
(XEN) sign: MCFG; name=MCFG<
(XEN) ACPI: MCFG (v001 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @ 0x3ffcfdc0
(XEN) std_entry[2].id = 18,matches sign MCFG
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
(XEN) (2) Mapped 0x3ffbe4a8 to fff9b4a8
(XEN) sign: DSDT; name=DSDT
(XEN) ACPI: DSDT (v001 IBM    SERBLADE 0x00001000 INTL 0x02002025) @ 0x00000000
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-000000003ffb0000
(XEN) Xen heap: 9MB (10184kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) PAE enabled, limit: 16 GB
(XEN) found SMP MP-table at 0009d540
(XEN) DMI 2.3 present.
(XEN) (1) Mapped 0xf601f to ff0f601f
(XEN) Using APIC driver default
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
(XEN) ACPI: Invalid FADT signature A__ADR


That one is bad. It has a bad signature! First call.


(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
(XEN) ACPI: PM-Timer IO Port: 0x588


2nd call. This one is good! POrt is also good.

(XEN) (2) Mapped 0x3ffcfd80 to fff9bd80
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN)                  wakeup_vec[3ffcfd8c], vec_size[20]
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
(XEN) ACPI: PM-Timer IO Port: 0x588


3rd call. This one is also good!

Looks like the mapping does not work correctly.


   Stefan

>
>  -- Keir
>
> On 9/8/07 14:35, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:
>
> > Check the signature of the alleged FADT and only parse it if it really
> > is the FADT and not something else. I understand that this is not the
> > real solution, but prevents other bad things from happening, like the
> > timer going backwards if a bogus PM-Timer port is picked up.
> >
> > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel