A TLB flushing issue (perhaps not even in software, as map_pages_to_xen()
appears to not have any problems in that respect)? Can you check what
is at the offset into the mapped page after mapping the DSDT (which is the
one place where the virtual page fff9bXXX gets associated with a different
physical one; all other mappings map the same physical page), but before
(re-)mapping the FADT? If that's not the data you observe, any chance
you can find out (e.g. under native Linux) where the observed data really
lives, to get an understanding where else such a broken translation could
come from?
Jan
>>> Stefan Berger <stefanb@xxxxxxxxxx> 09.08.07 19:54 >>>
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