Bug 583065

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.