On Fri, 2006-07-14 at 06:58 -0500, Jay Cliburn wrote:
> [jcliburn@osprey ~]$ uname -rm
> 2.6.17-1.2391.fc6 x86_64
>
> After updating FC6T1 in the past 12 hours, I see the following lockdep
> message.
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> -------------------------------------------------------
> cpuspeed/1527 is trying to acquire lock:
> (&policy->lock){--..}, at: [<ffffffff802681da>] mutex_lock+0x2a/0x2e
>
> but task is already holding lock:
> (cpucontrol){--..}, at: [<ffffffff802681da>] mutex_lock+0x2a/0x2e
>
<snip>
After today's rawhide kernel update, the same lockdep shows up. Should
I be filing a BZ on these?
[jcliburn@osprey ~]$ uname -rm
2.6.17-1.2396.fc6 x86_64
=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cpuspeed/1480 is trying to acquire lock:
(&policy->lock){--..}, at: [<ffffffff8026875a>] mutex_lock+0x2a/0x2e
but task is already holding lock:
(cpucontrol){--..}, at: [<ffffffff8026875a>] mutex_lock+0x2a/0x2e
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (cpucontrol){--..}:
[<ffffffff802abb1c>] lock_acquire+0x4a/0x69
[<ffffffff8026857c>] __mutex_lock_slowpath+0xeb/0x29f
[<ffffffff80268759>] mutex_lock+0x29/0x2e
[<ffffffff802af048>] __lock_cpu_hotplug+0x3c/0x5f
[<ffffffff802af085>] lock_cpu_hotplug+0xa/0xd
[<ffffffff8041a7fd>] __cpufreq_driver_target+0x1a/0x81
[<ffffffff8041babe>] cpufreq_governor_userspace+0x1e9/0x22c
[<ffffffff8041a1b5>] __cpufreq_governor+0x74/0x107
[<ffffffff8041a41d>] __cpufreq_set_policy+0x1d5/0x1e7
[<ffffffff8041a46a>] cpufreq_set_policy+0x3b/0x97
[<ffffffff8041b046>] cpufreq_add_dev+0x3ac/0x57b
[<ffffffff803ba8fa>] sysdev_driver_register+0xa7/0x13a
[<ffffffff8041a061>] cpufreq_register_driver+0xc1/0x1a1
[<ffffffff8028044c>] powernowk8_init+0x7e/0x88
[<ffffffff8026fde4>] init+0x1fc/0x3cd
[<ffffffff8026315d>] child_rip+0x7/0x12
-> #1 (userspace_mutex){--..}:
[<ffffffff802abb1c>] lock_acquire+0x4a/0x69
[<ffffffff8026857c>] __mutex_lock_slowpath+0xeb/0x29f
[<ffffffff80268759>] mutex_lock+0x29/0x2e
[<ffffffff8041b93a>] cpufreq_governor_userspace+0x65/0x22c
[<ffffffff8041a1b5>] __cpufreq_governor+0x74/0x107
[<ffffffff8041a3bc>] __cpufreq_set_policy+0x174/0x1e7
[<ffffffff8041a46a>] cpufreq_set_policy+0x3b/0x97
[<ffffffff8041b046>] cpufreq_add_dev+0x3ac/0x57b
[<ffffffff803ba8fa>] sysdev_driver_register+0xa7/0x13a
[<ffffffff8041a061>] cpufreq_register_driver+0xc1/0x1a1
[<ffffffff8028044c>] powernowk8_init+0x7e/0x88
[<ffffffff8026fde4>] init+0x1fc/0x3cd
[<ffffffff8026315d>] child_rip+0x7/0x12
-> #0 (&policy->lock){--..}:
[<ffffffff802abb1c>] lock_acquire+0x4a/0x69
[<ffffffff8026857c>] __mutex_lock_slowpath+0xeb/0x29f
[<ffffffff80268759>] mutex_lock+0x29/0x2e
[<ffffffff8041a614>] store_scaling_governor+0x14e/0x19c
[<ffffffff80277bda>] store+0x4b/0x66
[<ffffffff8030ff92>] sysfs_write_file+0xd0/0x103
[<ffffffff8021785e>] vfs_write+0xce/0x175
[<ffffffff8021814c>] sys_write+0x46/0x70
[<ffffffff8026220d>] system_call+0x7d/0x83
other info that might help us debug this:
1 lock held by cpuspeed/1480:
#0: (cpucontrol){--..}, at: [<ffffffff8026875a>] mutex_lock+0x2a/0x2e
stack backtrace:
Call Trace:
[<ffffffff80270de5>] show_trace+0xaa/0x23d
[<ffffffff80270f8d>] dump_stack+0x15/0x17
[<ffffffff802a9d76>] print_circular_bug_tail+0x6c/0x77
[<ffffffff802ab37b>] __lock_acquire+0x853/0xa54
[<ffffffff802abb1d>] lock_acquire+0x4b/0x69
[<ffffffff8026857d>] __mutex_lock_slowpath+0xec/0x29f
[<ffffffff8026875a>] mutex_lock+0x2a/0x2e
[<ffffffff8041a615>] store_scaling_governor+0x14f/0x19c
[<ffffffff80277bdb>] store+0x4c/0x66
[<ffffffff8030ff93>] sysfs_write_file+0xd1/0x103
[<ffffffff8021785f>] vfs_write+0xcf/0x175
[<ffffffff8021814d>] sys_write+0x47/0x70
[<ffffffff8026220e>] system_call+0x7e/0x83
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list