Most recent kernel where this bug did not occur: not sure yet Distribution: Hardware Environment: Software Environment: Problem Description: Steps to reproduce: boot it. I just fired up this really old quad Xeon server I have. First time I turned it on in a year. It has a really old BIOS - 1999 or 2000. ACPI used to disable itself due to the age of the BIOS (I used to have to use acpi=force), but it no longer does so. ACPI now enables itself (without ACPI=force) and, for other reasons, crashes. It means that a vendor kernel won't work on this machine. So. What happened to the date-of-BIOS based ACPI blacklisting?
Created attachment 5939 [details] dmesg dmesg
Originally kernel.org didn't blacklist ACPI by BIOS date. Then I swiped the year-cutoff date idea from SuSE, I used #define ACPI_BLACKLIST_CUTOFF_YEAR 2001 For linux-2.6.9, I moved this policy decision to config time via CONFIG_ACPI_BLACKLIST_YEAR. The distros are free to choose their own policy by setting the CONFIG_ACPI_BLACKLIST_YEAR=1999, 2009, or whatever. The default is 0, which disables the cutoff date check. The reason is that for kernel.org we want folks who build ACPI into the kernel and run it on ACPI-enabled hardware/BIOS to get exactly what they asked for -- and to file bugs if it fails. Please re-open this bug if booting with "acpi=off" fixes the boot failure.
OK, thanks. Turns out that the machine was crashing for non-apci reasons (Zwane broke the MP parsing code) and acpi actually works OK on this ancient machine.