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.
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.
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.
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
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.