Bug 572868 - INFO: possible recursive locking detected - cpufreq_governor_dbs
Summary: INFO: possible recursive locking detected - cpufreq_governor_dbs
Keywords:
Status: CLOSED DUPLICATE of bug 571969
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 576055 577502 579128 579794 580716 585142 585687 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-12 08:29 UTC by Stefan Ring
Modified: 2010-04-28 13:45 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-28 13:45:38 UTC
Type: ---


Attachments (Terms of Use)
New kernel, same behavior - dump attached (4.26 KB, text/plain)
2010-04-09 20:18 UTC, Bill Davidsen
no flags Details
2.6.33.2-41.fc13.x86_64 crashes too (4.03 KB, text/plain)
2010-04-14 22:14 UTC, Bill Davidsen
no flags Details

Description Stefan Ring 2010-03-12 08:29:17 UTC
Description of problem:


Version-Release number of selected component (if applicable):
2.6.33-1.fc13.x86_64 #1

How reproducible:
This happens during system shutdown.

CPU is a Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz

Mar 11 17:19:48 localhost cpuspeed: Disabling ondemand cpu frequency scaling governor
Mar 11 17:19:48 localhost kernel:
Mar 11 17:19:48 localhost kernel: =============================================
Mar 11 17:19:48 localhost kernel: [ INFO: possible recursive locking detected ]
Mar 11 17:19:48 localhost kernel: 2.6.33-1.fc13.x86_64 #1
Mar 11 17:19:48 localhost kernel: ---------------------------------------------
Mar 11 17:19:48 localhost kernel: K99cpuspeed/25783 is trying to acquire lock:
Mar 11 17:19:48 localhost kernel: (s_active){++++.+}, at: [<ffffffff81176f02>] sysfs_addrm_finish+0x36/0x55
Mar 11 17:19:48 localhost kernel:
Mar 11 17:19:48 localhost kernel: but task is already holding lock:
Mar 11 17:19:48 localhost kernel: (s_active){++++.+}, at: [<ffffffff811770bd>] sysfs_get_active_two+0x24/0x48
Mar 11 17:19:48 localhost kernel:
Mar 11 17:19:48 localhost kernel: other info that might help us debug this:
Mar 11 17:19:48 localhost kernel: 4 locks held by K99cpuspeed/25783:
Mar 11 17:19:48 localhost kernel: #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81175b9f>] sysfs_write_file+0x3c/0x144
Mar 11 17:19:48 localhost kernel: #1:  (s_active){++++.+}, at: [<ffffffff811770bd>] sysfs_get_active_two+0x24/0x48
Mar 11 17:19:48 localhost kernel: #2:  (s_active){++++.+}, at: [<ffffffff811770ca>] sysfs_get_active_two+0x31/0x48
Mar 11 17:19:48 localhost kernel: #3:  (dbs_mutex){+.+.+.}, at: [<ffffffffa0164da2>] cpufreq_governor_dbs+0x2a0/0x352 [cpufreq_ondemand]
Mar 11 17:19:48 localhost kernel:
Mar 11 17:19:48 localhost kernel: stack backtrace:
Mar 11 17:19:48 localhost kernel: Pid: 25783, comm: K99cpuspeed Not tainted 2.6.33-1.fc13.x86_64 #1
Mar 11 17:19:48 localhost kernel: Call Trace:
Mar 11 17:19:48 localhost kernel: [<ffffffff8107e94f>] __lock_acquire+0xcb5/0xd2c
Mar 11 17:19:48 localhost kernel: [<ffffffff8107cf48>] ? mark_held_locks+0x52/0x70
Mar 11 17:19:48 localhost kernel: [<ffffffff8107d329>] ? debug_check_no_locks_freed+0x12e/0x145
Mar 11 17:19:48 localhost kernel: [<ffffffff8107d1c8>] ? trace_hardirqs_on_caller+0x111/0x135
Mar 11 17:19:48 localhost kernel: [<ffffffff8107eaa2>] lock_acquire+0xdc/0x102
Mar 11 17:19:48 localhost kernel: [<ffffffff81176f02>] ? sysfs_addrm_finish+0x36/0x55
Mar 11 17:19:48 localhost kernel: [<ffffffff8107c300>] ? lockdep_init_map+0x9e/0x113
Mar 11 17:19:48 localhost kernel: [<ffffffff8117690f>] sysfs_deactivate+0x9a/0x103
Mar 11 17:19:48 localhost kernel: [<ffffffff81176f02>] ? sysfs_addrm_finish+0x36/0x55
Mar 11 17:19:48 localhost kernel: [<ffffffff8107120a>] ? sched_clock_cpu+0xc3/0xce
Mar 11 17:19:48 localhost kernel: [<ffffffff81476e44>] ? __mutex_unlock_slowpath+0x120/0x132
Mar 11 17:19:48 localhost kernel: [<ffffffff81176f02>] sysfs_addrm_finish+0x36/0x55
Mar 11 17:19:48 localhost kernel: [<ffffffff81175254>] sysfs_hash_and_remove+0x53/0x6a
Mar 11 17:19:48 localhost kernel: [<ffffffff811782f9>] sysfs_remove_group+0x91/0xca
Mar 11 17:19:48 localhost kernel: [<ffffffffa0164db6>] cpufreq_governor_dbs+0x2b4/0x352 [cpufreq_ondemand]
Mar 11 17:19:48 localhost kernel: [<ffffffff8107d1f9>] ? trace_hardirqs_on+0xd/0xf
Mar 11 17:19:48 localhost kernel: [<ffffffff813a289b>] __cpufreq_governor+0x9b/0xde
Mar 11 17:19:48 localhost kernel: [<ffffffff813a36e7>] __cpufreq_set_policy+0x1ce/0x275
Mar 11 17:19:48 localhost kernel: [<ffffffff813a3c0b>] store_scaling_governor+0x1a7/0x1fb
Mar 11 17:19:48 localhost kernel: [<ffffffff813a3f14>] ? handle_update+0x0/0x39
Mar 11 17:19:48 localhost kernel: [<ffffffff8147775f>] ? down_write+0x7a/0x81
Mar 11 17:19:48 localhost kernel: [<ffffffff813a34f4>] store+0x61/0x86
Mar 11 17:19:48 localhost kernel: [<ffffffff81175c6b>] sysfs_write_file+0x108/0x144
Mar 11 17:19:48 localhost kernel: [<ffffffff8111ed9d>] vfs_write+0xae/0x10b
Mar 11 17:19:48 localhost kernel: [<ffffffff8107d1c8>] ? trace_hardirqs_on_caller+0x111/0x135
Mar 11 17:19:48 localhost kernel: [<ffffffff8111eeba>] sys_write+0x4a/0x6e
Mar 11 17:19:48 localhost kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b

Comment 1 Robert de Rooy 2010-03-26 11:36:53 UTC

*** This bug has been marked as a duplicate of bug 571969 ***

Comment 2 Anton Arapov 2010-03-26 11:46:54 UTC
bug is duplicate, but the issue is still exists. don't close please.

Comment 3 Chuck Ebbert 2010-03-30 16:32:31 UTC
*** Bug 576055 has been marked as a duplicate of this bug. ***

Comment 4 Chuck Ebbert 2010-03-30 23:21:40 UTC
*** Bug 577502 has been marked as a duplicate of this bug. ***

Comment 5 Anton Arapov 2010-04-06 07:57:03 UTC
*** Bug 579128 has been marked as a duplicate of this bug. ***

Comment 6 Anton Arapov 2010-04-07 07:29:24 UTC
*** Bug 579794 has been marked as a duplicate of this bug. ***

Comment 7 Chuck Ebbert 2010-04-09 00:22:48 UTC
*** Bug 580716 has been marked as a duplicate of this bug. ***

Comment 8 Bill Davidsen 2010-04-09 20:18:19 UTC
Created attachment 405637 [details]
New kernel, same behavior - dump attached

If the "patch is in the queue" it hasn't come out yet. This is from kernel 2.6.33.1-24.fc13.x86_64 and still means the system can't be shut down cleanly.

Comment 9 Bill Davidsen 2010-04-14 22:14:33 UTC
Created attachment 406656 [details]
2.6.33.2-41.fc13.x86_64 crashes too

I had hopes that the new kernel would fix something. Perhaps something else, but not the crash and burn. Here's the detail from the log.

Comment 10 Anton Arapov 2010-04-23 11:08:46 UTC
*** Bug 585142 has been marked as a duplicate of this bug. ***

Comment 11 Anton Arapov 2010-04-26 05:33:08 UTC
*** Bug 585687 has been marked as a duplicate of this bug. ***

Comment 12 Robert de Rooy 2010-04-28 08:19:01 UTC
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@redhat.com> 2.6.33.2-66 - Turn off debugging and enable debug kernel builds.

Comment 13 Chuck Ebbert 2010-04-28 13:45:38 UTC

*** This bug has been marked as a duplicate of bug 571969 ***


Note You need to log in before you can comment on or make changes to this bug.