On Fri, Mar 21, 2003 at 05:46:24PM -0700, Pat LaVarre wrote: > 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
Yep. Signature, Tag, Target/Reserved, LUN, data transfer length, flags,
command length.
> 2) By:
> Sig T R Stat
> we mean what appears on the bus in the same order in a CSW.
Yes. Signature, Tag, Residue, Status.
> 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.
Actually, we're trying to keep the debug data a little concise and
differentiate signature from status.
> > /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?
Yep. command_abort() is invoked by the SCSI layer when the command has
taken too long to process. That's about 20 seconds for a read command.
It's reasonable to assume that the device is NAKing during that time.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Somebody call an exorcist!
-- Dust Puppy
User Friendly, 5/16/1998
pgp00000.pgp
Description: PGP signature
