cpuspeed lock dependency problem FC6 test1

[Peter Robinson]

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

Cheers,
Pete

On 7/20/06, Andrew Gray <andrewg at linnetsol.co.uk> 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 at redhat.com
> To unsubscribe:
> https://www.redhat.com/mailman/listinfo/fedora-test-list
>
>
>