Description of problem: On an eMachines 300k (a 7-year old desktop), ACPI is disabled when running either of the recently released 2.6.17 kernels, so the machine uses APM instead. With 2.6.16 or earlier kernels, ACPI is enabled. Version-Release number of selected component (if applicable): 2.6.17-1.2141_FC4 How reproducible: always Steps to Reproduce: 1. Boot into one of the 2.6.17 kernels. Actual results: Machine is using APM. Expected results: Machine should be using ACPI.
Created attachment 132112 [details] dmesg output showing ACPI disabled when running 2.6.17-1.2141_FC4
The same issue exists on a similar machine (eMachines 333cs) with the same motherboard but a different CPU, running FC5. So I'm changing this to FC5. Below are two attachments, one for 2.6.16-1.2096_FC5 which enables ACPI, and one for 2.6.17-1.2145_FC5, which disables ACPI. This machine has what I thought was a BIOS bug which would cause an immediate call trace upon booting if APM was enabled. Interestingly, now it works! I haven't tested APM ever since ACPI became the default in Red Hat/Fedora, so I don't know when it started working or if it's related to the fact that ACPI is now disabled for this machine. The only thing I normally use APM/ACPI for is to have the machine automatically turn off on shutdown. I haven't tested suspending it.
Created attachment 132278 [details] dmesg for 2.6.16-1.2096_FC5 which enables ACPI
Created attachment 132279 [details] dmesg for 2.6.17-1.2145_FC5 which disables ACPI
Hmm, it seems that if we can't determine the age of the BIOS (the text about missing DMI), we're assuming its too old, and disabling acpi. Does it work again if you boot with acpi=force ?
Created attachment 132522 [details] dmesg output for 2157 kernel with acpi=force
Yes, it does. Attached above is dmesg output for this. The BIOS is from 1999. I'm unable to do any type of suspend while using ACPI - Suspend isn't in the menu, and there is no /proc/acpi/sleep file to echo a number to, though the line ACPI: (supports S0 S1 S5) appears in dmesg. While using APM, Suspend DOES appear in the menu, but it doesn't work - when I try it, it looks like it's getting ready to suspend, and a single line saying something like "preparing for mem sleep" appears in dmesg, but it finally gives up and just returns the system to its normal state. In Windows 98, "Stand by" does work, but I got a BSOD on shutdown afterwards. Power-off on shutdown in Fedora works either with APM or ACPI. All in all, I'd say that being conservative with old hardware like this is the right thing to do, especially when I can just override it. So feel free to close this as NOTABUG if you want.
Here is the old Bugzilla report from back when the 2.4 kernel was first introduced, and this machine suddenly started doing a call trace on startup unless APM was disabled. At the time it was thought to be a BIOS bug. Since APM works now, maybe it wasn't. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=39191
Should have mentioned that the machine is still using the same BIOS as during bug #39191. In that bug I included an attachment with the output of dmidecode in case that helps.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
As I mentioned above, this isn't really a bug since the kernel is just being cautious and it's possible to get ACPI with acpi=force. So I'm closing this as NOTABUG.