On Tue, 18 Jan 2005, Matthias Urlichs wrote: > Any ideas why this happens (after 4000+ cycles, no less) would be > appreciated. > > This is 2.6.11-rc1-mm1.. Will try plain -rc1 next. > > cardctl D C13F007B 0 11374 4366 (NOTLB) > c4787e40 00000082 c4787de4 c13f007b c13f6060 00000001 00000001 00000000 > 00000000 de493080 dbe9ac80 caa34680 c13f6060 00000000 c4787e20 001c5676 > 00000000 807cd580 000f6d17 db8feaa0 db8febfc c52d0024 00000286 c52d002c > Call Trace: > [<c027aa42>] __down+0x82/0xfc > [<c011a548>] default_wake_function+0x0/0xd > [<c027ac07>] __down_failed+0x7/0xc > [<e0695ea7>] .text.lock.usb+0x16/0xb7 [usbcore] > [<e0697281>] usb_disconnect+0x47/0x12b [usbcore]
usb_disconnect needs to lock the device before it can proceed. If some other driver owns the lock it will block usb_disconnect. So in a strict sense this probably is not a deadlock; you just have usb_disconnect waiting for that other driver to release its lock. If the other driver had hung or crashed, that would explain what you see. For debugging, it would help to see the stack trace for khubd plus whatever other processes are liable to be using the devices on your card. Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
