[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Bad FADT and timer going backwards




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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.