We haven't named the bridge chip yet, have we? Anybody got a utility that can send vendor-specific commands, read unindexed string descriptors, etc.? Often different genetic families of Usb Mass chips can be fingerprinted that way.
> From: Dave Turner [mailto:[EMAIL PROTECTED] > Sent: Fri 3/21/2003 10:47 AM ... > > usb-storage: queuecommand() called > usb-storage: *** thread awakened. > usb-storage: Command MODE_SENSE (6 bytes) > usb-storage: 1a 00 3f 00 ff 00 00 00 00 00 9b cf > usb-storage: Bulk command S 0x43425355 T 0x1f Trg 0 LUN 0 L 255 F 128 CL 6 > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_transfer_partial(): xfer 255 bytes > usb-storage: usb_stor_bulk_msg() returned 0 xferred 12/255 > usb-storage: Bulk data transfer result 0x1 > usb-storage: Attempting to get CSW... > usb-storage: clearing endpoint halt for pipe 0xc0010280 > usb-storage: usb_stor_clear_halt: result=0 > usb-storage: Attempting to get CSW (2nd try)... > usb-storage: Bulk status result = 0 > usb-storage: Bulk status Sig 0x53425355 T 0x1f R 243 Stat 0x0 > usb-storage: scsi cmd done, result=0x0 > usb-storage: *** thread sleeping. > sda: Write Protect is off More legal but rude Di < Hi stress, curiously enough, immediately prior to the read failure. But apparently squeaky clean results e.g. R 243 + xferred 12 = xfer 255. I say this supposing: 1) By: S T Trg:LUN L F CL we mean what appears on the bus in a CBW as: S T L F Reserved:LUN CL 2) By: Sig T R Stat we mean what appears on the bus in the same order in a CSW. 3) By switching to the abbreviation Sig from the abbreviation S for what in the merely public standard appears twice as "Signature" we're just torturing newbies for fun. > /dev/scsi/host0/bus0/target0/lun0:<7>usb-storage: queuecommand() called > usb-storage: *** thread awakened. > usb-storage: Command READ_10 (10 bytes) > usb-storage: 28 00 00 00 00 00 00 00 08 00 9b cf > usb-storage: Bulk command S 0x43425355 T 0x20 Trg 0 LUN 0 L 4096 F 128 CL 10 > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes > usb-storage: command_abort() called > usb-storage: usb_stor_bulk_msg() returned -104 xferred 0/4096 > usb-storage: usb_stor_transfer_partial(): transfer aborted > usb-storage: Bulk data transfer result 0x3 > usb-storage: -- transport indicates command was aborted > usb-storage: scsi command aborted > usb-storage: *** thread sleeping. I presume "usb-storage: command_abort() called" here is key. That implies the timeout mentioned previously? Host logs look precisely like this if a device responds to Data IN requests by indefinitely NAK'ing? Cluelessly, curiously, thankfully yours, Pat LaVarre NHY隊X'u*m(ZW謞(z+i"v^y+)n )~ڝayZǨ)jp)W>alqz܂&v*reMzybn^elqz{.n+azV+֭ilqzlX)ߣbn^
