From: Dave Jones <davej@redhat.com>
To: Linus Torvalds <torvalds@osdl.org>,
Michal Piotrowski <michal.k.k.piotrowski@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.18-rc3-g3b445eea BUG: warning at /usr/src/linux-git/kernel/cpu.c:51/unlock_cpu_hotplug()
Date: Fri, 4 Aug 2006 22:49:47 -0400 [thread overview]
Message-ID: <20060805024947.GE13393@redhat.com> (raw)
In-Reply-To: <20060805022356.GC13393@redhat.com>
On Fri, Aug 04, 2006 at 10:23:56PM -0400, Dave Jones wrote:
> Duh. Everything becomes clearer the moment you post a diff to lkml.
Right, with that silly thinko out of the way, things make _slightly_
more sense, but I'm still puzzled. Here's the trace (with the DWARF
noise stripped out).
CPU1 called lock_cpu_hotplug() for app cpuspeed. recursive_depth=0
[<c0104edc>] show_trace_log_lvl+0x58/0x152
[<c01054c2>] show_trace+0xd/0x10
[<c01055db>] dump_stack+0x19/0x1b
[<c013e8c3>] lock_cpu_hotplug+0x39/0xbf
[<c029fbae>] store_scaling_governor+0x142/0x1a3
[<c029f1a5>] store+0x37/0x48
[<c01a6561>] sysfs_write_file+0xab/0xd1
[<c016f99f>] vfs_write+0xab/0x157
[<c016ffe4>] sys_write+0x3b/0x60
[<c0103db9>] sysenter_past_esp+0x56/0x8d
cpuspeed acquired cpu_bitmask_lock
CPU1 called lock_cpu_hotplug() for app cpuspeed. recursive_depth=0
[<c0104edc>] show_trace_log_lvl+0x58/0x152
[<c01054c2>] show_trace+0xd/0x10
[<c01055db>] dump_stack+0x19/0x1b
[<c013e8c3>] lock_cpu_hotplug+0x39/0xbf
[<c0132f3c>] __create_workqueue+0x52/0x122
[<f901234b>] cpufreq_governor_dbs+0x9f/0x2c3 [cpufreq_ondemand]
[<c029f7b6>] __cpufreq_governor+0x57/0xd8
[<c029f985>] __cpufreq_set_policy+0x14e/0x1bc
[<c029fbc5>] store_scaling_governor+0x159/0x1a3
[<c029f1a5>] store+0x37/0x48
[<c01a6561>] sysfs_write_file+0xab/0xd1
[<c016f99f>] vfs_write+0xab/0x157
[<c016ffe4>] sys_write+0x3b/0x60
[<c0103db9>] sysenter_past_esp+0x56/0x8d
Lukewarm IQ detected in hotplug locking
BUG: warning at kernel/cpu.c:46/lock_cpu_hotplug()
CPU1 called unlock_cpu_hotplug() for app cpuspeed. recursive_depth=1
[<c0104edc>] show_trace_log_lvl+0x58/0x152
[<c01054c2>] show_trace+0xd/0x10
[<c01055db>] dump_stack+0x19/0x1b
[<c013e980>] unlock_cpu_hotplug+0x37/0xb7
[<c0132fea>] __create_workqueue+0x100/0x122
[<f901234b>] cpufreq_governor_dbs+0x9f/0x2c3 [cpufreq_ondemand]
[<c029f7b6>] __cpufreq_governor+0x57/0xd8
[<c029f985>] __cpufreq_set_policy+0x14e/0x1bc
[<c029fbc5>] store_scaling_governor+0x159/0x1a3
[<c029f1a5>] store+0x37/0x48
[<c01a6561>] sysfs_write_file+0xab/0xd1
[<c016f99f>] vfs_write+0xab/0x157
[<c016ffe4>] sys_write+0x3b/0x60
[<c0103db9>] sysenter_past_esp+0x56/0x8d
CPU1 called unlock_cpu_hotplug() for app cpuspeed. recursive_depth=0
[<c0104edc>] show_trace_log_lvl+0x58/0x152
[<c01054c2>] show_trace+0xd/0x10
[<c01055db>] dump_stack+0x19/0x1b
[<c013e980>] unlock_cpu_hotplug+0x37/0xb7
[<c029fbe5>] store_scaling_governor+0x179/0x1a3
[<c029f1a5>] store+0x37/0x48
[<c01a6561>] sysfs_write_file+0xab/0xd1
[<c016f99f>] vfs_write+0xab/0x157
[<c016ffe4>] sys_write+0x3b/0x60
[<c0103db9>] sysenter_past_esp+0x56/0x8d
So in these traces we're seeing
lock
lock
unlock
unlock
But what I really don't understand is the ordering here.
Immediately after that first trace we should see an unlock.
store_scaling_governor does a lock/unlock pair, with no chance
of returning with the hotplug lock still held.
In the second trace however, cpuspeed is off doing something
completely different.
How can this happen?
My head hurts.
Dave
--
http://www.codemonkey.org.uk
next prev parent reply other threads:[~2006-08-05 2:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-04 19:04 2.6.18-rc3-g3b445eea BUG: warning at /usr/src/linux-git/kernel/cpu.c:51/unlock_cpu_hotplug() Michal Piotrowski
2006-08-04 19:24 ` Linus Torvalds
2006-08-04 22:24 ` Dave Jones
2006-08-05 0:31 ` Dave Jones
2006-08-05 2:10 ` Dave Jones
2006-08-05 2:23 ` Dave Jones
2006-08-05 2:49 ` Dave Jones [this message]
2006-08-05 6:47 ` Dave Jones
2006-08-05 7:46 ` Andrew Morton
2006-08-05 19:47 ` Dave Jones
2006-08-05 20:02 ` Andrew Morton
2006-08-06 1:12 ` Andrew Morton
2006-08-05 10:54 ` Michal Piotrowski
2006-08-05 11:11 ` Michal Piotrowski
2006-08-05 11:26 ` Michal Piotrowski
2006-08-05 18:47 ` Dave Jones
2006-08-05 21:15 ` Michal Piotrowski
2006-08-06 16:59 ` Michal Piotrowski
2006-08-06 18:05 ` Dave Jones
2006-08-06 19:32 ` Andrew Morton
2006-08-07 1:26 ` Andi Kleen
2006-08-07 8:18 ` Jan Beulich
2006-08-15 12:23 ` Jan Beulich
-- strict thread matches above, loose matches on Subject: below --
2006-08-05 22:14 art
2006-08-06 1:23 ` Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060805024947.GE13393@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.k.k.piotrowski@gmail.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox