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@lists.xensource.com
http://lists.xensource.com/xen-devel