has been fixed in upstream with commits:
b253d2b2d28ead6fed012feb54694b3d0562839a
b14893a62c73af0eca414cfed505b8c09efc613c

it's in fedora 2.6.32 already, got in as part of one of the 2.6.32.? stable releases.

I believe it's either addressed F13/2.6.33. Just wait for the new kernel.

Thanks for the report.

*** Bug 556462 has been marked as a duplicate of this bug. ***

This bug is filed against F13, not F12.

The reporter reports it against the 2.6.33-1 kernel which you say addresses the problem.

I am seeing the same problem on both an x86_64 and i686 system running F13alpha, and am still seeing it with 2.6.33.1-21 which for the moment is the latest build available in Koji.

I do not see this problem with F12 with either the 2.6.31 or 2.6.32 kernel.

*** Bug 572868 has been marked as a duplicate of this bug. ***

*** Bug 569945 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> *** Bug 569945 has been marked as a duplicate of this bug. ***    

This bug was reporting two distinct messages:
...
Mar  2 07:04:51 spruce kernel: 94cpufreq/25179 is trying to acquire lock:
...
Mar  2 11:51:02 spruce kernel: K99cpuspeed/3406 is trying to acquire lock:
...

Similar here:

=============================================
[ INFO: possible recursive locking detected ]
2.6.33.1-19.fc13.x86_64 #1
---------------------------------------------
94cpufreq/3017 is trying to acquire lock:
 (s_active){++++.+}, at: [<ffffffff81177332>] sysfs_addrm_finish+0x36/0x55

but task is already holding lock:
 (s_active){++++.+}, at: [<ffffffff811774ee>] sysfs_get_active_two+0x24/0x48

other info that might help us debug this:
4 locks held by 94cpufreq/3017:
 #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81175edb>] sysfs_write_file+0x3c/0x144
 #1:  (s_active){++++.+}, at: [<ffffffff811774ee>] sysfs_get_active_two+0x24/0x48
 #2:  (s_active){++++.+}, at: [<ffffffff811774fb>] sysfs_get_active_two+0x31/0x48
 #3:  (dbs_mutex){+.+.+.}, at: [<ffffffffa012cda2>] cpufreq_governor_dbs+0x2a0/0x352 [cpufreq_ondemand]

stack backtrace:
Pid: 3017, comm: 94cpufreq Not tainted 2.6.33.1-19.fc13.x86_64 #1
Call Trace:
 [<ffffffff8107e96b>] __lock_acquire+0xcb5/0xd2c
 [<ffffffff8107cf64>] ? mark_held_locks+0x52/0x70
 [<ffffffff8107d345>] ? debug_check_no_locks_freed+0x12e/0x145
 [<ffffffff8107d1e4>] ? trace_hardirqs_on_caller+0x111/0x135
 [<ffffffff8107eabe>] lock_acquire+0xdc/0x102
 [<ffffffff81177332>] ? sysfs_addrm_finish+0x36/0x55
 [<ffffffff8107c31c>] ? lockdep_init_map+0x9e/0x113
 [<ffffffff81176b02>] sysfs_deactivate+0x9a/0x103
 [<ffffffff81177332>] ? sysfs_addrm_finish+0x36/0x55
 [<ffffffff81071226>] ? sched_clock_cpu+0xc3/0xce
 [<ffffffff8147748c>] ? __mutex_unlock_slowpath+0x120/0x132
 [<ffffffff81177332>] sysfs_addrm_finish+0x36/0x55
 [<ffffffff81175590>] sysfs_hash_and_remove+0x53/0x6a
 [<ffffffff81178729>] sysfs_remove_group+0x91/0xca
 [<ffffffffa012cdb6>] cpufreq_governor_dbs+0x2b4/0x352 [cpufreq_ondemand]
 [<ffffffff8107d215>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff813a2e37>] __cpufreq_governor+0x9b/0xde
 [<ffffffff813a3c83>] __cpufreq_set_policy+0x1ce/0x275
 [<ffffffff813a41a7>] store_scaling_governor+0x1a7/0x1fb
 [<ffffffff813a44b0>] ? handle_update+0x0/0x39
 [<ffffffff81477da7>] ? down_write+0x7a/0x81
 [<ffffffff813a3a90>] store+0x61/0x86
 [<ffffffff81175fa7>] sysfs_write_file+0x108/0x144
 [<ffffffff8111f0e5>] vfs_write+0xae/0x10b
 [<ffffffff8107d1e4>] ? trace_hardirqs_on_caller+0x111/0x135
 [<ffffffff8111f202>] sys_write+0x4a/0x6e
 [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b

...but my posted report has been detected just after resuming my laptop from HDD.

*** Bug 572868 has been marked as a duplicate of this bug. ***

As I already commented in bug 572868

With kernel-2.6.33.3-71.fc13 I no longer get the trace. But looking at the
changelog I have the suspicion that it is because of this;

* Mon Apr 26 2010 Chuck Ebbert <cebbert> 2.6.33.2-66 - Turn off
debugging and enable debug kernel builds.

I'm pretty sure it disappeared in -68 for me, so perhaps it is the change mentioned in Comment 10.

Gene

*** Bug 588800 has been marked as a duplicate of this bug. ***

I no longer experience this bug in FC13.

Systematically reproducing with  2.6.33.5-112.fc13.x86_64.debug  the backtrace in comment 7 every time I go suspended to RAM (which succeeds anyway).

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.