Dmesg logs the messages of the most recent boot, and as such it is useful for debugging all sorts of problems. Its messages can be cryptic to the uninitiated, so this article documents those messages that stumped me and what they mean. …
Dmesg can be read with less /var/log/dmesg. It's a good place to look when troubleshooting problems, particularly boot or hardware difficulties. I also like to check it after installing a new distro or kernel, or after making hardware changes, even if everything seems to be normal.
The log is organized chronologically, newest entries last.
DMESG ENTRIES I'VE LOOKED INTO
ACPI: RSDP 000f03c0 00024 (v02 INTEL) ACPI: XSDT 3f462f10 00044 (v01 INTEL DG31GL 06222004 MSFT 00010013) ACPI: FACP 3f460d90 000F4 (v04 INTEL DG31GL 06222004 MSFT 00010013) ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tables! (20091214/tbfadt-369) ACPI Warning: 32/64X FACS address mismatch in FADT - 3F465F40/000000003F461F40, using 32 (20091214/tbfadt-486)
This message was seen on a box running Mandriva 2010.2, kernel-desktop586-188.8.131.52-2mnb-1-1mnb2, cleanly installed, shortly after installation. Processor is an Intel Pentium Dual-Core E2140 mounted on an Intel DG31GL motherboard. The message was observed during a routine post-installation check of all logs; the box seemed to be working properly without issue.
The error message is generated by /usr/src/linux-184.108.40.206-2mnb/drivers/acpi/acpica/tbfadt.c. From the comments there:
March 2009: We now always use the 32-bit address if it is valid (non-null). This is not in accordance with the ACPI specification which states that the 64-bit address supersedes the 32-bit version, but we do this for compatibility with other ACPI implementations. Most notably, in the case where both the 32 and 64 versions are non-null, we use the 32-bit version. This is the only address that is guaranteed to have been tested by the BIOS manufacturer.
So all it means is that the BIOS does not fully follow the ACPI specifications. (Thanks for nothing, Intel.) Given that the box seemed to be working properly, I chose to ignore the message.
The Linux Gazette article dmesg explained is old but still relevant and useful.