Hi,

ext Alan Stern wrote:
quoted text
> On Tue, 24 Jun 2008, Stefan Becker wrote:
> 
>> So the lockup is caused by an already locked hcd_urb_list_lock. Is there 
>> a way to see the lock holder? Or any other suggestions how to proceed?
> 
> Good work!

Well, I guess I'm just lucky it didn't turn into a heisenbug with all 
those printk's in the code :-)

quoted text
> The usage in usb_hcd_link_urb_to_ep() appears benign; the code doesn't 
> do anything that might hang while holding the lock.  All it does is 
> manipulate a linked list.

Unfortunately I could only run a small test today. I added some simple 
debugging code for the spinlock usage in hcd.c (see attached diff) and I 
get the following message at lockup (I tried it twice just to be sure):

HCD URB list locked by usb_hcd_link_urb_to_ep!

As far as I understand the matter this only can happen if 
usb_hcd_link_urb_to_ep() gets interrupted while holding the spinlock. 
But according to the contract at the header of the function it should be 
called with interrupts disabled!

I guess the obvious way forward from here is:

  - replace the spin_lock() in the function with the irqsave version

  - if that fixes the problem add debugging code to the function and 
panic with a stack trace when the interrupts aren't disabled one entry 
(don't know how to detect that yet, any suggestions?) That hopefully 
identifies the culprit that calls the function with interrupts enabled.

Regards,

	Stefan

---
Stefan Becker
E-Mail: Stefan.Becker@nokia.com