>>though I seem to have missed a post with the diagnostic saying
quoted text
>>what lock is being recursed.

[ INFO: possible recursive locking detected ]
2.6.37-rc4+ #1695
---------------------------------------------
ifconfig/536 is trying to acquire lock:
 (&(&list->lock)->rlock#2){-.-...}, at: [<401a63bc>] _defer_bh+0x24/0x124

but task is already holding lock:
 (&(&list->lock)->rlock#2){-.-...}, at: [<401a5f28>] _unlink_urbs+0x1c/0xa8

other info that might help us debug this:
2 locks held by ifconfig/536:
 #0:  (rtnl_mutex){+.+.+.}, at: [<4026b4f8>] _rtnl_lock+0x1c/0x2c
 #1:  (&(&list->lock)->rlock#2){-.-...}, at: [<401a5f28>] _unlink_urbs+0x1c/0xa8


We are using an OTG controller which isn't EHCI compliant and it has to
manage all the queues in software, thus unlinking URBs effectively
becomes synchronous. I cant see an easy solution to this short of modifying
the OTG-HCD driver to defer the unlinking to a workqueue, but even
then its still
possible to get this scenario.

Cheers

Neil


On Wed, Dec 8, 2010 at 4:55 AM, David Brownell <david-b@pacbell.net> wrote:
quoted text
> I'll look at this some later, though I seem to
> have missed a post with the diagnostic saying
> what lock is being recursed.
>
> That particular chunk of code has periodically
> turned up problems, and isn't very pretty.  But
> the most curious aspect of it is that it seemed
> to shake out HCD-specific behaviors.  (We've
> gotten rid of most such code by now, this is a
> slight exception.
>
> Specifically, HCDs that could unlink speedily
> without certain locking patterns (ISTR OHCI and
> EHCI, if not also UHCI) didn't trigger oddness.
> But some other HCDs, with different approaches
> to unlinking URBs, were less happy.  ( I was
> likely working with MUSB at the time.)
>
> I spent some time trying to rework that code in
> "usbnet", but no clean-and-obvious solutions
> became apparent when I did that (a few years
> back).  Plus, ISTR being the only person to
> find issues (back then), so I couldn't make
> an argument to spend much more time on it.
>
> Hope that helps anyone trying to fix this.
>
> - Dave
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html