On Fri, 3 Sep 2004, Olaf Hering wrote: > Current Linus tree still doesnt work with this drive, the genesys patch > that went in recently does not help. > > Its stuck in partition type scan. Any ideas? > Maybe this 'Illegal Request: Invalid field in cdb' is the reason for the > failure?
No, it isn't. That's a harmless failure return for a command the device doesn't understand. > Initializing USB Mass Storage driver... > usb-storage 1-1:1.0: usb_probe_interface > usb-storage 1-1:1.0: usb_probe_interface - got id > usb-storage: USB Mass Storage device detected <...> > usb-storage: Command READ_10 (10 bytes) > usb-storage: 28 00 00 00 00 00 00 00 08 00 > usb-storage: Bulk Command S 0x43425355 T 0x3325 L 4096 F 128 Trg 0 LUN 0 CL 10 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_bulk_transfer_sglist: xfer 4096 bytes, 1 entries > usb 1-1: control timeout on ep0in > usb 1-1: control timeout on ep0in > usb 1-1: control timeout on ep0in > usb 1-1: control timeout on ep0in Where did these messages come from? usb-storage doesn't produce them. There must have been some other program trying to access the drive at the same time as usb-storage, interfering with its operation. Probably a hotplug program or an automounter. You might be able to learn more from usbfs_snoop. > usb-storage: command_abort called > usb-storage: usb_stor_stop_transport called > usb-storage: -- cancelling sg request > usb-storage: Status code -104; transferred 0/4096 > usb-storage: -- transfer cancelled > usb-storage: Bulk data transfer result 0x4 > usb-storage: -- command was aborted > usb-storage: usb_stor_Bulk_reset called > usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0 > SysRq : Show State > > sibling > task PC pid father child younger older <...> > scsi_eh_1 D 00000000 0 6082 1 6083 3947 (L-TLB) > Call trace: > [c000a0a8] __switch_to+0x48/0x70 > [c01f5510] schedule+0x2b0/0x5d0 > [c01f5ab0] wait_for_completion+0x7c/0xec > [f1161744] command_abort+0x94/0x10c [usb_storage] > [c014749c] scsi_error_handler+0x5fc/0xe68 > [c00096c4] kernel_thread+0x44/0x60 > usb-storage D 00000000 0 6083 1 6082 (L-TLB) > Call trace: > [c000a0a8] __switch_to+0x48/0x70 > [c01f5510] schedule+0x2b0/0x5d0 > [c01f5ab0] wait_for_completion+0x7c/0xec > [f1162414] usb_stor_msg_common+0x138/0x1ac [usb_storage] > [f116255c] usb_stor_control_msg+0xd4/0xf8 [usb_storage] > [f11626f4] usb_stor_reset_common+0xa4/0x1e0 [usb_storage] > [f11622cc] usb_stor_invoke_transport+0x368/0x378 [usb_storage] > [f1161d68] usb_stor_transparent_scsi_command+0x1c/0xd0 [usb_storage] > [f11646ec] usb_stor_control_thread+0x1ac/0x34c [usb_storage] > [c00096c4] kernel_thread+0x44/0x60 How long did you let that reset go on for before getting this stack dump? If it was less than 20 seconds then the reset simply hasn't timed out yet. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
