Bug 188392 - Compaq V2405 fails to resume since FC5
Compaq V2405 fails to resume since FC5
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-08 18:53 EDT by gdelx001
Modified: 2008-06-16 21:12 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:12:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description gdelx001 2006-04-08 18:53:18 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:
100 %

Steps to Reproduce:
1.  Run pm-suspend in terminal
2.  Close laptop lid
3.  Open laptop lid
  
Actual results:
Opening laptop lid appears to turn on laptop: power light turns on and hard
drive sounds like it is powered, but LCD screen never activates.  After doing a
hard shutdown and reboot, there are no messages in /var/log/messages detailing
supsension or resume under the control of pm-utils. 

Expected results:
Complete resumption including messages in /var/log/messages.

Additional info:
The laptop is a Compaq V2405 running a Sempron and has ATI 200M mobile graphics
chip, runnning the ATI driver.  Also tried video drivers (Xorg) included in FC5
with no beneficial effect.  Under FC4 laptop worked flawlessly under ACPI
suspend with a couple small additions to the ACPI sleep action script (e.g.
software ejection of pcmcia cards).  It appears ACPI no longer works under FC5
in the same way - events in the registered section are not honored.  So it seems
that it is expected that one uses pm-utils to perform this action: but there are
many drawbacks to this method including the fact that it fails to resume
properly and doesn't [appear to] interact well with ACPI actuator (e.g. lid
close button) events.

How do I force diagnostics under pm-utils to find out what is wrong?  Without
any output captured during the process I can't generally help narrow down the
problem.
Comment 1 Leo 2006-04-12 20:46:08 EDT
I confirm that this bug has been in fc5 for a long time.
Comment 2 Thomas Engelschmidt 2006-04-19 04:25:33 EDT
I'm having the same problem with a Thinkpad x40 with Display controller: Intel
Corporation 82852/855GM Integrated Graphics Device (rev 02)

I can't reproduce it every time - but generally the system behaves the following
way after resume

1) LCD Screen is blank, hd and wireless less indicates activity.
2) Shows Gnomes Unlock dialog, except dialog text is missing, when unlocking
gnome fails to update foreground window - for example when scolling down in
firefox, thunderbird or other application - The screen isn't updated correct.
3) Works fine :-) Nice but this happens only approx. 1/4 times.. 

Solution: 
Reboot system when item 1) and 2) are encountered.
Comment 3 Phil Knirsch 2007-01-23 10:36:16 EST
Have you tried this with newer version of pm-utils? There are quite a few
changes in the FC6 version of it that might fix the problem you're describing.

Thanks,

Read ya, Phil
Comment 4 gdelx001 2007-01-23 11:07:29 EST
This also is a problem with the new pm-utils in FC6 over many of the kernel
revisions released and proprietary and xorg ati X drivers.  Suspending/resuming
out of run levels 1 and 3 confirmed that there is a resume problem (at least in
3, behaves erratically in 1) under pm-suspend without X, and that the machine is
dead upon resume (find / -print typed blindly to console produced no activity).

The _very_ recent FC6 update to kernel 2.6.19 and the associated new proprietary
X video kernel module are for once showing some positive signs of behaving well
with suspend and resume, at least avoiding pm-utils and using ACPI state change
directly (manually).  When there's time, will eventually test if pm-utils works
and if this problem could have been a long-standing kernel regression as far
back as FC5 (since it all worked well [under direct ACPI/acpid scripting] before
that).

Comment 5 gdelx001 2007-03-28 00:57:51 EDT
Full suspend/resume cycle initiatied with pm-suspend works when configured to
not use vbetool or radeontool to help the process (removing the file 20video
from /etc/pm/hooks).  If this change is not performed, post-resume freeze occurs
as before, using pm-suspend.  This is using kernel 2.6.20-1.2933.fc6 and kernel
module fglrx 8.34.8. 

Best solution would be to automatically adjust to not use vbetool/radeontool
when driver interacts properly with ACPI (black/whitelist?).  Second best would
be to provide cleaner configuration that could keep pm-utils from using the
adjunct video tools in the suspend+resume process.
Comment 6 Till Maas 2007-12-30 15:24:30 EST
Does running
gnome-power-cmd.sh suspend
(it's in the gnome-power-manager package) work better for you?
Comment 7 Till Maas 2008-01-08 11:39:59 EST
Do you still have problems?
Comment 8 gdelx001 2008-01-09 11:46:21 EST
(In reply to comment #7)

Yes, although I have not had much time to investigate them, and I've moved on to
Fedora 8 with this particular equipment.  The file in question of course has
moved to /usr/lib/pm-utils/sleep.d

There seems to be a way to say not to run vbetool, i.e. not having any of the
relevant environment variables set in the configuration, but I have continued to
only have some success by eliminating the script entirely (it was as if the
absence of configuration variables were not being respected), and adding a list
for unloading a number of modules (which does appear to be respected) to now
allow it to suspend in the first place.  To improve resume I had to add the hack
(without apparent support in the "quirks" available) to jigger the 8042 for
keyboard and mouse to come back reliably.

This allows me to suspend, and resume if I do it nearly immediately.  But now if
I let it suspend overnight (and I believe it is actually any period longer than
about two hours) the machine doesn't resume.  The power light comes on, but no
screen, and  I can't blindly type to create any disk activity.  This happens in
run level 3 using pm-suspend and with the gui using the gnome power manager menu
(which I assume is connected to the mechanism used by the command
"gnome-power-cmd.sh suspend").

A casual inet search brings up a couple people that have a similar issue on
different hardware, but little investigation appears to have been accomplished.
 This is so frustrating because it used to work just fine on this particular
machine, and has become worse and worse as supposedly the suspend/resume support
has been improved.  Likely changing details of the modules and kernel operation
have upset this.
Comment 9 Till Maas 2008-01-09 12:15:43 EST
Can you please paste the output of these five commands after a fresh reboot and
before suspending?

lshal | egrep
(system.hardware.(product|vendor|version)|smbios.bios.version|power_management.quirk)"
cat /proc/sys/kernel/acpi_video_flags
ls -la /etc/pm/config.d/
cat /etc/pm/config.d/*
ls -la /etc/pm/sleep.d/

(In reply to comment #8)

> There seems to be a way to say not to run vbetool, i.e. not having any of the
> relevant environment variables set in the configuration, but I have continued to
> only have some success by eliminating the script entirely (it was as if the
> absence of configuration variables were not being respected), and adding a list

Instead of removing the script, it should be enough to put an empty shell-script
to /etc/pm/sleep.d/20video and make it executable.

> for unloading a number of modules (which does appear to be respected) to now
> allow it to suspend in the first place.  To improve resume I had to add the hack
> (without apparent support in the "quirks" available) to jigger the 8042 for
> keyboard and mouse to come back reliably.

What exactly did you need to do here?

> This allows me to suspend, and resume if I do it nearly immediately.  But now if
> I let it suspend overnight (and I believe it is actually any period longer than
> about two hours) the machine doesn't resume.  The power light comes on, but no
> screen, and  I can't blindly type to create any disk activity.  This happens in
> run level 3 using pm-suspend and with the gui using the gnome power manager menu
> (which I assume is connected to the mechanism used by the command
> "gnome-power-cmd.sh suspend").

When you use the gnome power manager or the shell script, then quirks are used,
in case there are some defined. pm-suspend by itself does not use any quirks.

> A casual inet search brings up a couple people that have a similar issue on
> different hardware, but little investigation appears to have been accomplished.
>  This is so frustrating because it used to work just fine on this particular
> machine, and has become worse and worse as supposedly the suspend/resume support
> has been improved.  Likely changing details of the modules and kernel operation
> have upset this.
 
In another bug report is was written, that the flgrx driver may not work too
well with suspend.
Comment 10 gdelx001 2008-01-10 12:33:06 EST
(In reply to comment #9)
> Can you please paste the output of these five commands after a fresh reboot and
> before suspending?
> 
> lshal | egrep
>
(system.hardware.(product|vendor|version)|smbios.bios.version|power_management.quirk)"
> cat /proc/sys/kernel/acpi_video_flags
> ls -la /etc/pm/config.d/
> cat /etc/pm/config.d/*
> ls -la /etc/pm/sleep.d/
> 

Eventually.

> (In reply to comment #8)
> 
> > There seems to be a way to say not to run vbetool, i.e. not having any of the
> > relevant environment variables set in the configuration, but I have continued to
> > only have some success by eliminating the script entirely (it was as if the
> > absence of configuration variables were not being respected), and adding a list
> 
> Instead of removing the script, it should be enough to put an empty shell-script
> to /etc/pm/sleep.d/20video and make it executable.
> 

I've tried that at some point, and I think it did work.  There was some strange
problem with the addition disappearing on (yum) updates that I never had the
time to figure out.

> > for unloading a number of modules (which does appear to be respected) to now
> > allow it to suspend in the first place.  To improve resume I had to add the hack
> > (without apparent support in the "quirks" available) to jigger the 8042 for
> > keyboard and mouse to come back reliably.
> 
> What exactly did you need to do here?
> 

echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind
echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind

The symptoms appear on an increasing number of Linux laptops I see these days:
even ones where it wasn't necessary before.  Whether this is the true fix or
not, I don't know, but maybe the driver has just become less reliable.  It just
seems to reduce the chance to near zero of the mouse and keyboard coming up dead
if you're lucky enough to have the screen come back.

> > This allows me to suspend, and resume if I do it nearly immediately.  But now if
> > I let it suspend overnight (and I believe it is actually any period longer than
> > about two hours) the machine doesn't resume.  The power light comes on, but no
> > screen, and  I can't blindly type to create any disk activity.  This happens in
> > run level 3 using pm-suspend and with the gui using the gnome power manager menu
> > (which I assume is connected to the mechanism used by the command
> > "gnome-power-cmd.sh suspend").
> 
> When you use the gnome power manager or the shell script, then quirks are used,
> in case there are some defined. pm-suspend by itself does not use any quirks.
> 
> > A casual inet search brings up a couple people that have a similar issue on
> > different hardware, but little investigation appears to have been accomplished.
> >  This is so frustrating because it used to work just fine on this particular
> > machine, and has become worse and worse as supposedly the suspend/resume support
> > has been improved.  Likely changing details of the modules and kernel operation
> > have upset this.
>  
> In another bug report is was written, that the flgrx driver may not work too
> well with suspend.

It always has been dicey according to various sources, but it worked nearly
out-of-the-box for me at the time, until the transition to FC7 (and associated
updates to the flgrx driver).  I've been willing to try quirk fixes and so on,
but nothing I've tried so far with limited time available has made it all the way.

Comment 11 gdelx001 2008-01-11 03:07:56 EST
(In reply to comment #9)
> Can you please paste the output of these five commands after a fresh reboot and
> before suspending?
> 
> lshal | egrep
>
(system.hardware.(product|vendor|version)|smbios.bios.version|power_management.quirk)"
> cat /proc/sys/kernel/acpi_video_flags
> ls -la /etc/pm/config.d/
> cat /etc/pm/config.d/*
> ls -la /etc/pm/sleep.d/
> 

# lshal | egrep
(system.hardware.(product|vendor|version)|smbios.bios.version|power_management.quirk)
  smbios.bios.version = 'F.11'  (string)
  system.hardware.product = 'Presario V2000 (EH458UA#ABA)'  (string)
  system.hardware.vendor = 'Hewlett-Packard'  (string)
  system.hardware.version = 'Rev 1'  (string)
# cat /proc/sys/kernel/acpi_video_flags
0
# ls -la /etc/pm/config.d/
total 24
drwxr-xr-x 2 root root 4096 2008-01-10 23:33 .
drwxr-xr-x 7 root root 4096 2007-10-23 13:25 ..
-rwxr-xr-x 1 root root  131 2007-06-26 20:28 unload_modules
# cat /etc/pm/config.d/unload_modules
SUSPEND_MODULES="fglrx rfcomm wlan_scan_sta ath_rate_sample ath_pci
bcm43xx_mac80211 ssb ath_hal rc80211_simple mac80211 cfg80211"
# ls -la /etc/pm/sleep.d/
total 48
drwxr-xr-x 2 root root 4096 2007-10-23 13:25 .
drwxr-xr-x 7 root root 4096 2007-10-23 13:25 ..
-rw-r--r-- 1 root root    0 2007-09-30 22:06 20video
-rwxr-xr-x 1 root root  299 2006-06-02 07:34 30pccard
-rwxr-xr-x 1 root root  277 2007-06-26 21:58 92iochip
-rwxr-xr-x 1 root root  145 2007-07-05 17:33 97harddrive
-rw-r--r-- 1 root root    0 2007-09-30 22:06 99video


So my memory isn't so good.  I am using the wipeout feature of
/etc/pm-utils/sleep.d although is it now supposed to have the execute bit set? 
I believe it used to need the execute bit cleared to obviate the running of the
script.  Also I now recall after moving to Fedora 7, suddenly 99video had to be
eliminated as well as 20video to get suspending to work.  We've discussed iochip
(i8042 jiggering) and 30pccard simply "ejects" the pccard at suspend, nothing at
resume: as mentioned in an earlier comment at one time the pcmcia card would not
work properly at resume without it.   harddrive simply sets some hdparm
parameters that I used to set under acpi for suspend and resume (DMA off/on and
some sleep timer settings): it may not be necessary.  It was another experiment
to see if it would help long term suspend and resume.

The module unload list may yet be too inclusive, but has been pared down some
from a larger list that seemed to work.  Under Fedora 7 for example the fglrx
module _had_ to be removed for suspend to not be rejected: ironic since I've
seen more recently that many people report needing this to _not_ be unloaded at
suspend, and I didn't worry about unloading it or any module at all in the
"early days" when acpid was the only tool available.



 
Comment 12 Till Maas 2008-01-11 04:37:43 EST
> So my memory isn't so good.  I am using the wipeout feature of
> /etc/pm-utils/sleep.d although is it now supposed to have the execute bit set? 
> I believe it used to need the execute bit cleared to obviate the running of the
> script.  Also I now recall after moving to Fedora 7, suddenly 99video had to 

In Fedora 7, the execute bit has to be set, to overwrite the system default
sleep.d files. In case there is a file in /etc/pm/sleep.d that does not have the
execute bit set, it will be ignored.

be
> eliminated as well as 20video to get suspending to work.  We've discussed 

When I read the code of 20video and 99video, they both should not change
anything on your system.

> The module unload list may yet be too inclusive, but has been pared down some
> from a larger list that seemed to work.  Under Fedora 7 for example the fglrx
> module _had_ to be removed for suspend to not be rejected: ironic since I've
> seen more recently that many people report needing this to _not_ be unloaded at
> suspend, and I didn't worry about unloading it or any module at all in the
> "early days" when acpid was the only tool available.

For every module you really need to unload and that is included in the Fedora
kernel, afaik you should file a bug for the kernel package. Maybe this can be
fixed, too.

Would you please file a bug against the kernel about the i8042 issue, too.
Please add me to CC there.

Also I reassign this bug to the kernel package.
Comment 13 gdelx001 2008-01-13 19:34:51 EST
i8042 issue is already reported under (kernel) bug 250683, although it mentions
only the keyboard.  The touchpad in this case is also affected.

Comment 14 Bug Zapper 2008-05-14 08:00:55 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Bug Zapper 2008-06-16 21:12:31 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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