Red Hat Bugzilla – Bug 74315
(Sony Vaio FXA series) apm=idle_threshold poweroff/crash
Last modified: 2007-04-18 12:46:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
Description of problem:
Ever since I upgraded to kernel-2.4.18-14.athlon.rpm I have had this one strange
problem where I would leave my laptop unattended for several hours, and come
back to find that it had mysteriously powered itself off. When I boot up again
it goes through the ext3 journal replay, indicating that it had indeed crashed.
I had been observing this since early September when I installed 2.4.18-14.
Since then I had rebooted back into 2.4.18-12.5 several times in order to
confirm that this problem is in fact caused by the newer kernel. I am now at 2
days uptime in 2.4.18-12.5, while 2.4.18-14 would usually not survive more than
Strangely I had never observed this laptop mysteriously poweroff while I was
actively using it in 2.4.18-14. It only did only mysteriously poweroff during
idle (while Gnome's screensaver was active).
Something between 2.4.18-12.5 and 2.4.18-14 introduced this problem.
The following are limbo-list posts pertaining to this problem:
Sony Vaio FXA36 Athlon laptop
Same machine as mentioned in this earlier report, dmesg and lspci output are in
the first few attachments here.
Version-Release number of selected component (if applicable):
Red Hat (null)
Steps to Reproduce:
1. Leave laptop idle for several hours in Gnome desktop.
Come back and find it powered off. Turn on and it runs the ext3 journal replay,
indicating that it had crashed.
Shouldn't mysteriously power off. When I boot back into
kernel-2.4.18-12.5.athlon.rpm I am 100% stable again.
I have figured out that 2.4.18-14 wont mysteriously poweroff my machine if I
keep my laptop lid open. 2.4.18-12.5 will keep my laptop on as expected with
the lid open or closed.
could you try adding
to the kernel commandline? that would be the only place where the kernel calls
APM code in normal use
I am happy to report that apm=idle_threshold=100 appears to work.
I am curious, why was it changed?
ok can you get me the dmidecode for that machine?
It was changed because it saves a LOT of power on the machines that do support
this feature properly....
Created attachment 81284 [details]
dmidecode with latest BIOS (R0121K5)
This is the dmidecode from late last year, with an older version of the BIOS.
2.4.18-17.8.0 no longer powers off mysteriously, but appears to lock up instead.
I still need to test whether this is caused by the new BIOS or the new kernel,
so please don't change anything yet.
Okay I have confirmed that this latest version of the BIOS has changed the
behavior of this problem. Rather than powering off while the lid is closed, the
machine would simply lockup. Screen remains on and laptop powered up, but it
seizes to respond. Only recourse is to hold down power button to force a power
I see this same lockup when this laptop returns from "Suspend to RAM" which
occurs if I hit the Power button during normal operation.
With "apm=idle_threshold=100" my laptop doesn't power off or lockup without
warning while the lid is closed.
Any other suggestions?
This doesn't seem to occur anymore in Phoebe's kernel.