Created attachment 407127 [details] Smolt profile Description of problem: If I suspend my system once, everything seems to work fine: the screen, the hard disk and the fans turn off and the power button light starts blinking; after pressing the power button, Fedora correctly resumes. But if I try to suspend the system for the second time, the screen switches to console; the hard disk turns off, but the fans continue spinning; some tens of seconds later, the power button light starts blinking. The system no longer responds nor can be resumed and I have to power it down. Version-Release number of selected component (if applicable): 2.6.33.1-24.fc13.x86_64 2.6.33.2-43.fc13.x86_64 How reproducible: Always Steps to Reproduce: 1. Suspend the system by pressing "System -> Shutdown -> Suspend" (or via "pm-suspend") 2. Resume the system 3. Suspend it again Actual results: The screen switches to console; the hard disk turns off, but the fans continue spinning; some tens of seconds later, the power button light starts blinking. The system no longer responds nor can be resumed and I have to power it down. Expected results: The system should suspend correctly and resume after pressing the power button. Additional info: I noticed this bug while using the special live CD provided for the Radeon Test Day (https://fedoraproject.org/wiki/Test_Day:2010-04-14_Radeon), which ships with kernel 2.6.33.2-43.fc13.x86_64. Then I encountered the same bug while trying Fedora 13 Beta (kernel 2.6.33.1-24.fc13.x86_64) via live USB. The problem also happens if suspending the system via "pm-suspend" in runlevel 3.
If I boot into runlevel 3 and launch "pm-suspend" for the first time, suspension apparently works fine. But when the system resumes, the following message appears on console (I've copied it here from /var/log/messages): Apr 16 15:11:05 localhost kernel: ============================================= Apr 16 15:11:05 localhost kernel: [ INFO: possible recursive locking detected ] Apr 16 15:11:05 localhost kernel: 2.6.33.1-24.fc13.x86_64 #1 Apr 16 15:11:05 localhost kernel: --------------------------------------------- Apr 16 15:11:05 localhost kernel: 94cpufreq/2019 is trying to acquire lock: Apr 16 15:11:05 localhost kernel: (s_active){++++.+}, at: [<ffffffff81177332>] sysfs_addrm_finish+0x36/0x55 Apr 16 15:11:05 localhost kernel: Apr 16 15:11:05 localhost kernel: but task is already holding lock: Apr 16 15:11:05 localhost kernel: (s_active){++++.+}, at: [<ffffffff811774ee>] sysfs_get_active_two+0x24/0x48 Apr 16 15:11:05 localhost kernel: Apr 16 15:11:05 localhost kernel: other info that might help us debug this: Apr 16 15:11:05 localhost kernel: 4 locks held by 94cpufreq/2019: Apr 16 15:11:05 localhost kernel: #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff81175edb>] sysfs_write_file+0x3c/0x144 Apr 16 15:11:05 localhost kernel: #1: (s_active){++++.+}, at: [<ffffffff811774ee>] sysfs_get_active_two+0x24/0x48 Apr 16 15:11:05 localhost kernel: #2: (s_active){++++.+}, at: [<ffffffff811774fb>] sysfs_get_active_two+0x31/0x48 Apr 16 15:11:05 localhost kernel: #3: (dbs_mutex){+.+.+.}, at: [<ffffffffa03c5da2>] cpufreq_governor_dbs+0x2a0/0x352 [cpufreq_ondemand] Apr 16 15:11:05 localhost kernel: Apr 16 15:11:05 localhost kernel: stack backtrace: Apr 16 15:11:05 localhost kernel: Pid: 2019, comm: 94cpufreq Not tainted 2.6.33.1-24.fc13.x86_64 #1 Apr 16 15:11:05 localhost kernel: Call Trace: Apr 16 15:11:05 localhost kernel: [<ffffffff8107e96b>] __lock_acquire+0xcb5/0xd2c Apr 16 15:11:05 localhost kernel: [<ffffffff8107cf64>] ? mark_held_locks+0x52/0x70 Apr 16 15:11:05 localhost kernel: [<ffffffff8107d345>] ? debug_check_no_locks_freed+0x12e/0x145 Apr 16 15:11:05 localhost kernel: [<ffffffff8107d1e4>] ? trace_hardirqs_on_caller+0x111/0x135 Apr 16 15:11:05 localhost kernel: [<ffffffff8107eabe>] lock_acquire+0xdc/0x102 Apr 16 15:11:05 localhost kernel: [<ffffffff81177332>] ? sysfs_addrm_finish+0x36/0x55 Apr 16 15:11:05 localhost kernel: [<ffffffff8107c31c>] ? lockdep_init_map+0x9e/0x113 Apr 16 15:11:05 localhost kernel: [<ffffffff81176b02>] sysfs_deactivate+0x9a/0x103 Apr 16 15:11:05 localhost kernel: [<ffffffff81177332>] ? sysfs_addrm_finish+0x36/0x55 Apr 16 15:11:05 localhost kernel: [<ffffffff81071226>] ? sched_clock_cpu+0xc3/0xce Apr 16 15:11:05 localhost kernel: [<ffffffff8147748c>] ? __mutex_unlock_slowpath+0x120/0x132 Apr 16 15:11:05 localhost kernel: [<ffffffff81177332>] sysfs_addrm_finish+0x36/0x55 Apr 16 15:11:05 localhost kernel: [<ffffffff81175590>] sysfs_hash_and_remove+0x53/0x6a Apr 16 15:11:05 localhost kernel: [<ffffffff81178729>] sysfs_remove_group+0x91/0xca Apr 16 15:11:05 localhost kernel: [<ffffffffa03c5db6>] cpufreq_governor_dbs+0x2b4/0x352 [cpufreq_ondemand] Apr 16 15:11:05 localhost kernel: [<ffffffff8107d215>] ? trace_hardirqs_on+0xd/0xf Apr 16 15:11:05 localhost kernel: [<ffffffff813a2e37>] __cpufreq_governor+0x9b/0xde Apr 16 15:11:05 localhost kernel: [<ffffffff813a3c83>] __cpufreq_set_policy+0x1ce/0x275 Apr 16 15:11:05 localhost kernel: [<ffffffff813a41a7>] store_scaling_governor+0x1a7/0x1fb Apr 16 15:11:05 localhost kernel: [<ffffffff813a44b0>] ? handle_update+0x0/0x39 Apr 16 15:11:05 localhost kernel: [<ffffffff81477da7>] ? down_write+0x7a/0x81 Apr 16 15:11:05 localhost kernel: [<ffffffff813a3a90>] store+0x61/0x86 Apr 16 15:11:05 localhost kernel: [<ffffffff81175fa7>] sysfs_write_file+0x108/0x144 Apr 16 15:11:05 localhost kernel: [<ffffffff8111f0e5>] vfs_write+0xae/0x10b Apr 16 15:11:05 localhost kernel: [<ffffffff8111f202>] sys_write+0x4a/0x6e Apr 16 15:11:05 localhost kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b If I try to enter suspension again, the system behaves as described above.
*** Bug 590263 has been marked as a duplicate of this bug. ***
The problem persists with kernel 2.6.33.3-85.fc13.x86_64, with only two differences: - the kernel trace shown in Comment 1 doesn't appear any more; - after resuming from the first suspension, the system runs extremely slow.
The issue, as described in Comment 3, persists after the upgrade to kernel 2.6.33.5-112.fc13.x86_64.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.