Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 74315 - (Sony Vaio FXA series) apm=idle_threshold poweroff/crash
(Sony Vaio FXA series) apm=idle_threshold poweroff/crash
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-09-20 06:58 EDT by Warren Togami
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-24 00:19:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmidecode with latest BIOS (R0121K5) (6.15 KB, patch)
2002-10-21 05:47 EDT, Warren Togami
no flags Details | Diff

  None (edit)
Description Warren Togami 2002-09-20 06:58:18 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
6 hours.

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)

How reproducible:

Steps to Reproduce:
1. Leave laptop idle for several hours in Gnome desktop.

Actual Results:  
Come back and find it powered off.  Turn on and it runs the ext3 journal replay,
indicating that it had crashed.

Expected Results:  
Shouldn't mysteriously power off.  When I boot back into
kernel-2.4.18-12.5.athlon.rpm I am 100% stable again.
Comment 1 Warren Togami 2002-10-14 22:38:30 EDT
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.
Comment 2 Arjan van de Ven 2002-10-15 07:08:56 EDT

could you try adding


to the kernel commandline? that would be the only place where the kernel calls
APM code in normal use
Comment 3 Warren Togami 2002-10-17 16:41:59 EDT
I am happy to report that apm=idle_threshold=100 appears to work.

I am curious, why was it changed?
Comment 4 Arjan van de Ven 2002-10-17 16:45:28 EDT
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....
Comment 5 Warren Togami 2002-10-21 05:47:09 EDT
Created attachment 81284 [details]
dmidecode with latest BIOS (R0121K5)
Comment 6 Warren Togami 2002-10-21 05:49:30 EDT
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.
Comment 7 Warren Togami 2002-10-30 04:40:36 EST
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?
Comment 8 Warren Togami 2002-12-24 00:19:27 EST
This doesn't seem to occur anymore in Phoebe's kernel.

Note You need to log in before you can comment on or make changes to this bug.