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):
Steps to Reproduce:
1. Boot into one of the 2.6.17 kernels.
Machine is using APM.
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.
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.
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