Hello!
I am encountering a problem with
one of the machines I am using and the timer going backwards. It looks
like the problem is due to to a bad PM-Timer entry being found. Though
when debugging further, the real source of the problem stems from an ACPI
table of type DSDT being parsed as an FADT during boot and certainly a
bogus PM-Timer is found there.
Here's the output from 'xm dmesg' with
an additional signature check of the alleged FADT, which now prevents it
from picking the bogus PM-Timer port. I am also dumping how the addresses
of the tables are being mapped. Linux does find the correct PM-Timer port,
though (0x2208).
(XEN) Command line: /xen.gz console=vga
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN) EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009d000 (usable)
(XEN) 000000000009d400 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000003ffcd000 (usable)
(XEN) 000000003ffcdec0 - 000000003ffd0000 (ACPI data)
(XEN) 000000003ffd0000 - 0000000040000000 (reserved)
(XEN) 00000000fec00000 - 0000000100000000 (reserved)
(XEN) System RAM: 1023MB (1047976kB)
(XEN) ACPI table at 0xfdfc0 mapped to address ff0fdfc0
(XEN) ACPI: RSDP (v000 IBM
)
@ 0x000fdfc0
(XEN) ACPI table at 0x3ffcff80 mapped to address fff9bf80
(XEN) ACPI table at 0x3ffcff80 mapped to address fff9bf80
(XEN) ACPI: RSDT (v001 IBM SERBLADE 0x00001000 IBM 0x45444f43)
@ 0x3ffcff80
(XEN) ACPI table at 0x3ffcfec0 mapped to address fff9bec0
(XEN) ACPI table at 0x3ffcfec0 mapped to address fff9bec0
(XEN) ACPI: FADT (v002 IBM SERBLADE 0x00001000 IBM 0x45444f43)
@ 0x3ffcfec0
(XEN) ACPI table at 0x3ffcfe00 mapped to address fff9be00
(XEN) ACPI table at 0x3ffcfe00 mapped to address fff9be00
(XEN) ACPI: MADT (v001 IBM SERBLADE 0x00001000 IBM 0x45444f43)
@ 0x3ffcfe00
(XEN) ACPI table at 0x3ffcfec0 mapped to address fff9bec0
(XEN) ACPI table at 0x3ffcdec0 mapped to address fff9bec0
(XEN) ACPI: DSDT (v001 IBM SERBLADE 0x00001000 INTL 0x02002025)
@ 0x00000000
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-000000003ffcd000
(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) ACPI table at 0xf5fcf mapped to address ff0f5fcf
Caused by acpi_table_parse(ACPI_BOOT, ...)
(XEN) Using APIC driver default
(XEN) ACPI table at 0x3ffcfec0 mapped to address fff9bec0
Caused by acpi_table_parse(ACPI_FADT, ...)
(XEN) ACPI: Invalid FADT signature DSDT
I added checking of the signature inside the FADT
parser.
The ACPI table of the FADT really is a DSDT?! No wonder
the parsing and PM-Timer went all wrong. Wonder how Linux finds it, though.
A mistake in the mapping function?
Though this likely does not mean anything, the DSDT
string is immediately followed by FADT -- so it's there.
Stefan
(XEN) ACPI table at 0x3ffcfe00 mapped to address fff9be00
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI table at 0x3ffcff80 mapped to address fff9bf80
(XEN) ACPI table at 0x3ffcff80 mapped to address fff9bf80
(XEN) ACPI table at 0x3ffcfec0 mapped to address fff9bec0
(XEN) ACPI table at 0x3ffcfe00 mapped to address fff9be00
(XEN) ACPI table at 0x3ffcfe00 mapped to address fff9be00
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel