Re: cpuspeed lock dependency problem FC6 test1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Known issue.... see bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197803

Cheers,
Pete

On 7/20/06, Andrew Gray <andrewg@xxxxxxxxxxxxxxx> wrote:
AMD Athlon 64 Moblie 3400+
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3400+ processors
(version 2.00.00)
powernow-k8:    0 : fid 0xc (2000 MHz), vid 0x6
powernow-k8:    1 : fid 0xa (1800 MHz), vid 0xa
powernow-k8:    2 : fid 0x0 (800 MHz), vid 0x1

Kernel 2.6.17-1.2416.FC6.x86_64 SMP
cupspeed-1.2.1-1.36.fc6.1

On booting and in dmesg the following lock dependency is reported:-

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cpuspeed/1506 is trying to acquire lock:
 (&policy->lock){--..}, at: [<ffffffff80265ddf>] mutex_lock+0x2a/0x2e

but task is already holding lock:
 (cpucontrol){--..}, at: [<ffffffff80265ddf>] mutex_lock+0x2a/0x2e

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (cpucontrol){--..}:
       [<ffffffff802a8302>] lock_acquire+0x4a/0x69
       [<ffffffff80265c38>] __mutex_lock_slowpath+0xe4/0x261
       [<ffffffff80265dde>] mutex_lock+0x29/0x2e
       [<ffffffff802ab5bb>] __lock_cpu_hotplug+0x3c/0x5f
       [<ffffffff802ab5f8>] lock_cpu_hotplug+0xa/0xd
       [<ffffffff8040e88f>] __cpufreq_driver_target+0x1a/0x82
       [<ffffffff8040fb51>] cpufreq_governor_userspace+0x1e9/0x22c
       [<ffffffff8040e248>] __cpufreq_governor+0x74/0x107
       [<ffffffff8040e4b0>] __cpufreq_set_policy+0x1d5/0x1e7
       [<ffffffff8040e4fd>] cpufreq_set_policy+0x3b/0x96
       [<ffffffff8040f0d9>] cpufreq_add_dev+0x3ac/0x57b
       [<ffffffff803b2cd4>] sysdev_driver_register+0x7b/0xdc
       [<ffffffff8040e0f4>] cpufreq_register_driver+0xc1/0x1a1
       [<ffffffff8027d765>] powernowk8_init+0x7e/0x88
       [<ffffffff8026d2ac>] init+0x1fc/0x3cd
       [<ffffffff80260e9d>] child_rip+0x7/0x12

-> #1 (userspace_mutex){--..}:
       [<ffffffff802a8302>] lock_acquire+0x4a/0x69
       [<ffffffff80265c38>] __mutex_lock_slowpath+0xe4/0x261
       [<ffffffff80265dde>] mutex_lock+0x29/0x2e
       [<ffffffff8040f9cd>] cpufreq_governor_userspace+0x65/0x22c
       [<ffffffff8040e248>] __cpufreq_governor+0x74/0x107
       [<ffffffff8040e44f>] __cpufreq_set_policy+0x174/0x1e7
       [<ffffffff8040e4fd>] cpufreq_set_policy+0x3b/0x96
       [<ffffffff8040f0d9>] cpufreq_add_dev+0x3ac/0x57b
       [<ffffffff803b2cd4>] sysdev_driver_register+0x7b/0xdc
       [<ffffffff8040e0f4>] cpufreq_register_driver+0xc1/0x1a1
       [<ffffffff8027d765>] powernowk8_init+0x7e/0x88
       [<ffffffff8026d2ac>] init+0x1fc/0x3cd
       [<ffffffff80260e9d>] child_rip+0x7/0x12

-> #0 (&policy->lock){--..}:
       [<ffffffff802a8302>] lock_acquire+0x4a/0x69
       [<ffffffff80265c38>] __mutex_lock_slowpath+0xe4/0x261
       [<ffffffff80265dde>] mutex_lock+0x29/0x2e
       [<ffffffff8040e6a6>] store_scaling_governor+0x14e/0x19c
       [<ffffffff80274fb3>] store+0x4b/0x66
       [<ffffffff80309b18>] sysfs_write_file+0xd0/0x103
       [<ffffffff80217147>] vfs_write+0xce/0x175
       [<ffffffff80217a2f>] sys_write+0x46/0x70
       [<ffffffff8025ff4d>] system_call+0x7d/0x83

other info that might help us debug this:

1 lock held by cpuspeed/1506:
 #0:  (cpucontrol){--..}, at: [<ffffffff80265ddf>] mutex_lock+0x2a/0x2e

stack backtrace:

Call Trace:
 [<ffffffff8026e2a9>] show_trace+0xaa/0x23d
 [<ffffffff8026e451>] dump_stack+0x15/0x17
 [<ffffffff802a655c>] print_circular_bug_tail+0x6c/0x77
 [<ffffffff802a7b61>] __lock_acquire+0x853/0xa54
 [<ffffffff802a8303>] lock_acquire+0x4b/0x69
 [<ffffffff80265c39>] __mutex_lock_slowpath+0xe5/0x261
 [<ffffffff80265ddf>] mutex_lock+0x2a/0x2e
 [<ffffffff8040e6a7>] store_scaling_governor+0x14f/0x19c
 [<ffffffff80274fb4>] store+0x4c/0x66
 [<ffffffff80309b19>] sysfs_write_file+0xd1/0x103
 [<ffffffff80217148>] vfs_write+0xcf/0x175
 [<ffffffff80217a30>] sys_write+0x47/0x70
 [<ffffffff8025ff4e>] system_call+0x7e/0x83


Otherwise once booted cpuspeed seen to work and dynamically control the
Athlon 64 M 3400+

The full dmesg output is also attached.


Hope this helps in debugging.

Keep up the good work.

--Andrew Gray


--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list




--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]