Bug 496107 - pm-suspend freezes ocasionally before S3 sleep
pm-suspend freezes ocasionally before S3 sleep
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
10
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-16 12:58 EDT by Mike Ball
Modified: 2015-03-04 20:20 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 04:15:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
good and bad pm-suspend.log sequence (123.99 KB, application/octet-stream)
2009-04-16 13:01 EDT, Mike Ball
no flags Details

  None (edit)
Description Mike Ball 2009-04-16 12:58:23 EDT
Description of problem: 

Setup is mythdora 10.21 with all component updates current. using pm_suspend to put system in S3 sleep.  It works most of the time.  Occasionally, pm-suspend hangs before going into sleep (once every 5 to 10 times).

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

Mythdora 10.21, Fedora 10, Motherboard is ASUS M3N78-EM with current bios flashed (511). Memory is OCZ Reaper HPC 4GB (2 x 2GB), AMD Phenom 9350e CPU.

How reproducible: once every 5 to 10 times.

Steps to Reproduce:
1. execute "PM_DEBUG=true pm-suspend", if it goes to sleep, wake up system
2. repeat step 1 until system hangs going down.
3.
  
Actual results:
System hangs, have to cycle power or reset to reboot.

Expected results:
System goes to sleep without hanging. Able to wake system up.

Additional info:
I am using This to set the wakeup time (where $1 is epoch time):
echo 0 > /sys/class/rtc/rtc0/wakealarm      #this clears your alarm.
echo $1 > /sys/class/rtc/rtc0/wakealarm     #this writes your alarm

I have this file set up to remove/setup  modules that don't play well with suspend: /etc/pm/config.d/unload_module
SUSPEND_MODULES='ivtv saa7134_dvb saa7134_alsa saa7134'

log says can't remove saa7134_dvb, and suspend modules processing stops.  System seems to operate fine after resume, so I haven't yet removed "saa7134_dvb saa7134_alsa saa7134" from SUSPEND_MODULES.  The module ivtv is a must here for correct processing after resume.

I've attached one text file.  The file contains 2 pm_suspend.log files, first 1 from a locked up sequence, then 1 from a good sleep sequence.  They are separated by:

#--------------------------------------------------------------------
#--GOOD MB.-- The following is from a good pm-suspend sequence.
#--Search up for "--BAD MB.--" to see the start of a sequence that locked up

Any feedback is appreciated.
Comment 1 Mike Ball 2009-04-16 13:01:17 EDT
Created attachment 339875 [details]
good and bad pm-suspend.log sequence

Got: The bug was created successfully, but attachment creation failed. Please add your attachment by clicking the "Add an Attachment" link below. 

Trying to add attachment again.
Comment 2 Mike Ball 2009-04-17 10:49:01 EDT
More info:

[hball@mythtv ~]$ uname -a
Linux mythtv.ball.cc 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23 23:08:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[hball@mythtv ~]$


Guys, I have 2 ways to bring the system into sleep: 

1) use pm-suspend (which previous loaded log files shows).  This way saa7134_dvb isn't removed.  pm-suspend says it's in use - but I don't see any modules using it in the process map in the log file. Without the saa7134 modules removed and restarted after S3, the saa7134 board seems to work, but I get lots of these in /var/log/messages:
Apr 17 06:34:06 mythtv kernel: nxt200x: i2c_writebytes: i2c write error (addr 0x61, err == -5)
Apr 17 06:34:06 mythtv kernel: nxt200x: error writing to tuner
Apr 17 06:34:06 mythtv kernel: nxt200x: i2c_readbytes: i2c read error (addr 0x61, err == -5)
Apr 17 06:34:07 mythtv kernel: nxt200x: Timeout waiting for nxt2004 to init.
Apr 17 06:34:07 mythtv kernel: nxt200x: i2c_writebytes: i2c write error (addr 0x61, err == -5)
Apr 17 06:34:07 mythtv kernel: nxt200x: error writing to tuner
Apr 17 06:34:07 mythtv kernel: nxt200x: i2c_readbytes: i2c read error (addr 0x61, err == -5)
Apr 17 06:34:08 mythtv kernel: nxt200x: Timeout waiting for nxt2004 to init.
Apr 17 06:34:08 mythtv kernel: nxt200x: i2c_writebytes: i2c write error (addr 0x61, err == -5)
Apr 17 06:34:08 mythtv kernel: nxt200x: error writing to tuner
Apr 17 06:34:08 mythtv kernel: nxt200x: i2c_readbytes: i2c read error (addr 0x61, err == -5)
Apr 17 06:34:09 mythtv kernel: nxt200x: Timeout waiting for nxt2004 to init.

2) I can sidestep pm-suspend and force removal myself by:
modprobe -rf ivtv
modprobe -rf saa7134_dvb
modprobe -rf saa7134_alsa
modprobe -rf saa7134

echo -n mem > /sys/power/state

modprobe ivtv
modprobe saa7134
modprobe saa7134_dvb
modprobe saa7134_alsa

This way, ivtv and saa7134 plays nice with Fedora S3 (none of the above messages in /var/log/messages), but I don't get any info logged like pm-suspend does.

Either way, S3 works, but system ocassionally freezes going down.
Comment 3 Bug Zapper 2009-11-18 06:44:36 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 to the applicable version.  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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Bug Zapper 2009-12-18 04:15:54 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.