On Mon, 16 Jun 2003, Major A wrote: > > > It wouldn't be surprising if the file that cp hung on was the same one > > that generated those usb_bulk/control_msg timeouts in the previous set of > > I did a simpler version of what you told me, and it's the file > > /sys/devices/pci0/00:09.2/usb5/5-1/product > > that hangs. I can still read any other file, but that single file > fails.
Not too surprising, since reading that file causes a USB transfer to be performed, see core/driverfs.c:show_product(). However, the .../manufacturer file should do the same thing; maybe your device doesn't define that string. > Here is a trace for the relevant processes: > > > Jun 16 22:49:10 ventus kernel: cp D FFFE7555 4287842736 2176 2009 > > (NOTLB) > > Jun 16 22:49:10 ventus kernel: Call Trace: > > Jun 16 22:49:10 ventus kernel: [<c012b168>] schedule_timeout+0xa8/0xd0 > > Jun 16 22:49:10 ventus kernel: [<c012b0b0>] process_timeout+0x0/0x10 > > Jun 16 22:49:10 ventus kernel: [<c02ae7d7>] usb_start_wait_urb+0xd7/0x190 > > Jun 16 22:49:10 ventus kernel: [<c011c290>] default_wake_function+0x0/0x20 > > Jun 16 22:49:10 ventus kernel: [<c011c290>] default_wake_function+0x0/0x20 > > Jun 16 22:49:10 ventus kernel: [<c02ae913>] usb_internal_control_msg+0x83/0xa0 > > Jun 16 22:49:10 ventus kernel: [<c02ae99e>] usb_control_msg+0x6e/0x90 > > Jun 16 22:49:10 ventus kernel: [<c02af44f>] usb_get_string+0x3f/0x50 David, what can you make of that? It looks like it's stuck in schedule_timeout() waiting for a timer that must have already expired. Unless I'm reading it wrong and it's actually stuck in process_timeout() -- but all that does is call wake_up_process(). -?? > Furthermore, this is the full log that I get when I unplug the device > (in the hung state). The cp completes successfully on unplugging, and > from then on any new cp also works fine. Its contents are "VIA > Technologies, In USB 2.0". Are you sure that's the same file? I would expect that to be the contents of .../usb5/product, not .../usb5/5-1/product. The rest of the log looks normal for a failing connection. The oops is reiserfs getting upset about its journalling device going offline. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
