On Tue, 31 Mar 2009, Johannes Berg wrote:

quoted

quoted

quoted

quoted

quoted

[20920.458587] =======================================================
[20920.458944] [ INFO: possible circular locking dependency detected ]
[20920.459231] 2.6.29-rc3-wl-12787-g17d9115-dirty #38
[20920.459449] -------------------------------------------------------
[20920.459736] events/0/9 is trying to acquire lock:
[20920.459951]  (&dev->mutex){--..}, at: [<ffffffff804be0ac>] input_disconnect_device+0x2c/0xf0
[20920.460369] 
[20920.460370] but task is already holding lock:
[20920.460637]  (&usbhid->reset_work){--..}, at: [<ffffffff8025a933>] run_workqueue+0xb3/0x250
[20920.461049] 
[20920.461050] which lock already depends on the new lock.

Ping? I just ran into it again on 2.6.29-rc8-wl-18593-gef1cb6f-dirty.

I haven't still fully gone through the whole dependency chain, was quite 
overloaded lately, sorry.

There is a patch from Oliver Neukum, that fixes workqueue usage semantics 
around hid_reset() on [1], could you please check whether it also fixes 
the report you are seeing? Thanks.
[1] http://lkml.org/lkml/2009/3/18/39

That patch doesn't even apply against a current tree.

I wasn't able to reproduce this report on my test systems; did you use 
only Linus' current tree, or did it have any other trees pulled in? (I am 
referring to the -wl- in the version string).

-wl is the wireless-testing tree, but it has no input stuff in it.

Well as the dependency chain is fairly non-trivial, even some non-input 
stuff could be involved in the circular depepndency.

quoted

Could you please send me your config?

Sure, attached. I haven't yet tried to reproduce on .29 though, which 
this config is for (but I haven't changed it since, only taken it 
forward).

Thanks,

-- 
Jiri Kosina
SUSE Labs