On Tue, 18 Jan 2005, Matthias Urlichs wrote: > Suspect 1: > > hald D 00000000 0 4942 1 4996 4938 (NOTLB) > c17d1c98 00000082 00000002 00000000 00000002 016d2980 ddb4b580 d990bcfc > dd86fe84 00000286 df098980 dd86fe84 e06a5065 da589a80 c13f6060 00000000 > 8b05fbc0 000f424d de03b6ac c17d0000 c17d1d5c c17d1cb8 c17d1cf0 c027fb34 > Call Trace: > [<e06a5065>] ohci_urb_enqueue+0x155/0x360 [ohci_hcd] > [<c027fb34>] wait_for_completion+0x94/0xe0 > [<c0118640>] default_wake_function+0x0/0x10 > [<c0118640>] default_wake_function+0x0/0x10 > [<e06b981a>] usb_start_wait_urb+0xfa/0x1c0 [usbcore] > [<e06b9710>] timeout_kill+0x0/0x10 [usbcore] > [<e06b9971>] usb_internal_control_msg+0x91/0xb0 [usbcore] > [<e06b9a20>] usb_control_msg+0x90/0xb0 [usbcore] > [<e06ba2c2>] usb_get_string+0x62/0x80 [usbcore] > [<e06ba368>] usb_string_sub+0x28/0xe0 [usbcore] > [<e06ba4ff>] usb_string+0xdf/0x1b0 [usbcore] > [<e06c1b61>] usb_dump_device_strings+0xc1/0x120 [usbcore] > [<e06c1c0d>] usb_dump_desc+0x4d/0xb0 [usbcore] > [<e06c1dd3>] usb_device_dump+0x163/0x300 [usbcore] > [<c013e2c0>] __free_pages_ok+0xc0/0xe0 > [<e06c1ee3>] usb_device_dump+0x273/0x300 [usbcore] > [<e06c2078>] usb_device_read+0x108/0x130 [usbcore] > [<c0157d01>] vfs_read+0xe1/0x160 > [<c0157ff7>] sys_read+0x47/0x80 > [<c0103157>] syscall_call+0x7/0xb > > khubd S E06B3FBC 0 943 1 1213 434 (L-TLB) > deb13f90 00000046 0000006b e06b3fbc ddf51b80 00000000 d9f73800 00000286 > d9f73800 c0280c41 da94d380 198d1050 000f424d dedfba80 c13f6060 0003640e > 20ed56c0 000f424d df054bdc deb13fc0 ffffe000 deb12000 deb13fcc e06b733e > Call Trace: > [<e06b3fbc>] .text.lock.usb+0x16/0xba [usbcore] > [<c0280c41>] _spin_unlock_irq+0x21/0x50 > [<e06b733e>] hub_thread+0xce/0x120 [usbcore] > [<c0130fe0>] autoremove_wake_function+0x0/0x50 > [<c0103032>] ret_from_fork+0x6/0x14 > [<c0130fe0>] autoremove_wake_function+0x0/0x50 > [<e06b7270>] hub_thread+0x0/0x120 [usbcore] > [<c0101355>] kernel_thread_helper+0x5/0x10
Khubd isn't doing anything. But hald sure is! It's trying to read /proc/bus/usb/devices, and in the process it locks each device as it reads the information for that device. Apparently it has worked its way up to one of the devices on your card, and it holds the lock on that device thus blocking usb_disconnect. It's hard to tell exactly what's going on with hald, but it seems clear that hald is waiting for ohci-hcd to do something. Presumably the reason ohci-hcd isn't doing it is because the card is no longer accessible. This sounds like a problem in ohci-hcd. Beyond that I can't help. Dave Brownell may have some ideas. 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
