Bug 74315 - (Sony Vaio FXA series) apm=idle_threshold poweroff/crash
Summary: (Sony Vaio FXA series) apm=idle_threshold poweroff/crash
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-20 10:58 UTC by Warren Togami
Modified: 2007-04-18 16:46 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-12-24 05:19:27 UTC
Embargoed:


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

Description Warren Togami 2002-09-20 10:58:18 UTC
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:
https://listman.redhat.com/pipermail/limbo-list/2002-September/005875.html
https://listman.redhat.com/pipermail/limbo-list/2002-September/005929.html
https://listman.redhat.com/pipermail/limbo-list/2002-September/005933.html
https://listman.redhat.com/pipermail/limbo-list/2002-September/006236.html

Hardware:
Sony Vaio FXA36 Athlon laptop
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62295
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:
Always

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-15 02:38:30 UTC
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 11:08:56 UTC
interesting

could you try adding

apm=idle_threshold=100 

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 20:41:59 UTC
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 20:45:28 UTC
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 09:47:09 UTC
Created attachment 81284 [details]
dmidecode with latest BIOS (R0121K5)

Comment 6 Warren Togami 2002-10-21 09:49:30 UTC
https://bugzilla.redhat.com/bugzilla/showattachment.cgi?attach_id=51326
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 09:40:36 UTC
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
donw.

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 05:19:27 UTC
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.