> I have snipped part of the log ...
Re guessing what Windows may be doing that works ...
Anybody know the bInterfaceClass ...SubClass
...Protocol involved here?
Specifically does bInterfaceProtocol here != x06 Scsi?
> ...
Re guessing what Linux may be doing that breaks ...
Would just sending one read command via SG_IO, rather
than going for the whole mount of a volume, teach us
anything?
How about sending a read command to an Lba beyond the
capacity?
I presume Linux `dd` can't be persuaded to try reading
from a volume that hasn't yet been mounted?
Me, I have web-published an app that I like using to
do that kind of thing. Its internals are ugly because
I targetted Dos & Win, not just Linux, & because I
chose to parse a command line, & because I hadn't yet
discovered Linux Documentation/CodingStyle. But
mostly it works.
> some sort of USB snooping might provide a clue
Also, because my app runs elsewhere, I can try the
same CDB in Linux and elsewhere, to begin to get an
idea of how arrogantly each local pass thru mangles my
request.
> usb-storage: 28 00 00 00 00 00 00 00 08 00 9b cf
I interpret that log line to mean the first x0C (12)
bytes of the CBWCB is x 28 00 00:00:00:00 00 00:08 00
9B:CF.
I find that line intriguing because just now lately
I've heard people guessing the talk-like-Windows
protocol includes zeroing the CBWCB out at least thru
offset 11 i.e. substitute 00:00 for 9B:CF.
But I haven't yet heard any specific anecdotes of
actual devices seen to need such pampering.
> usb-storage: Bulk command S 0x43425355 T 0x20 Trg 0 LUN 0 L 4096 F 128 CL 10
"CL 10" here might mean bCWBCBLength = x0A (10).
A device that demands zeroed bytes beyond the
bCWBCBLength arguably falls outside the BBB spec, yet
within the view of people who hold firmly to the error
that the SFF texts imply bCWBCBLength = x0C (12)
always.
> usb-storage: Bulk command S 0x43425355 T 0x20 Trg 0 LUN 0 L 4096 F 128 CL 10
"L 4096" here might mean dCBWDataTransferLength =
x1000 (4096) = x00:08 * x200.
> I have snipped part of the log ...
Presuming that op x25 Read Capacity reported bytes per
block = x200 = 512, we have Hi = Di = x1000, no
worries.
> some sort of USB snooping might provide a clue
More folk could comment - though they may not be
subscribed here - if we could more easily access
translations to likely Usb bus traffic from Linux
kernel log jargon.
Specifically here now I wonder if "usb-storage:
usb_stor_transfer_partial(): xfer 4096 bytes" means we
copied In x1000 bytes before we saw trouble.
> ...
Curiously yours, Pat LaVarre
-----Original Message-----
From: Alan Stern [mailto:[EMAIL PROTECTED]
Sent: Fri 3/21/2003 12:21 PM
To: Dave Turner; Matthew Dharm
Cc: USB Storage List; USB development list
Subject: [usb-storage] Re: [linux-usb-devel] Belkin Compact Flash card reader
On Fri, 21 Mar 2003, Dave Turner wrote:
> On Fri, 21 Mar 2003 at 10:45am, Alan Stern wrote:
>
> > Dave, please try this patch, see what happens, and send another kernel
> > log extract. I don't think it will fix everything because it doesn't
> > address the root of your problem: your Microdrive isn't reading and
> > returning the data from the disc (or it's taking longer than 20 seconds
> > to do so). But it will move us one step closer towards solving this.
>
> You're right, still no luck with mounting the Microdrive. Here's the log
> from the patched kernel.
>
> Linux version 2.4.21-pre5 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315
> (release)) #1 Fri Mar 21 17:00:03 GMT 2003
I have snipped part of the log that shows the device successfully
completing a series of INQUIRY, TEST-UNIT-READY, REQUEST-SENSE,
READ-CAPACITY, and MODE-SENSE commands. But it doesn't do anything when
given a READ(10) command:
> 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.
> usb-storage: queuecommand() called
> usb-storage: *** thread awakened.
> usb-storage: Command TEST_UNIT_READY (6 bytes)
> usb-storage: 00 00 00 00 00 00 00 00 08 00 9b cf
> usb-storage: Bulk command S 0x43425355 T 0x20 Trg 0 LUN 0 L 0 F 0 CL 6
> usb-storage: command_abort() called
> usb-storage: Bulk command transfer result=-104
> usb-storage: -- transport indicates command was aborted
> usb-storage: scsi command aborted
> usb-storage: *** thread sleeping.
> usb-storage: device_reset() called
> usb-storage: Bulk reset requested
> usb_control/bulk_msg: timeout
> usb-storage: Bulk soft reset failed -110
> usb-storage: bus_reset() called
> hub.c: port 1, portstatus 103, change 0, 12 Mb/s
> usb.c: ignoring set_interface for dev 2, iface 0, alt 0
> usb-storage: Examinging driver usb-storage...skipping ourselves.
> usb-storage: bus_reset() complete
> usb-storage: queuecommand() called
> usb-storage: *** thread awakened.
> usb-storage: Command TEST_UNIT_READY (6 bytes)
> usb-storage: 00 00 00 00 00 00 00 00 08 00 9b cf
> usb-storage: Bulk command S 0x43425355 T 0x20 Trg 0 LUN 0 L 0 F 0 CL 6
> usb-storage: Bulk command transfer result=0
> usb-storage: Attempting to get CSW...
> usb-storage: Bulk status result = 0
> usb-storage: Bulk status Sig 0x53425355 T 0x20 R 0 Stat 0x0
> usb-storage: scsi cmd done, result=0x0
> usb-storage: *** thread sleeping.
> 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.
> scsi: device set offline - not ready or command retry failed after bus
reset: host 0 channel 0 id 0 lun 0
> SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 50000
> I/O error: dev 08:00, sector 0
> I/O error: dev 08:00, sector 2
> I/O error: dev 08:00, sector 0
> VFS: Disk change detected on device 08:00
> /dev/scsi/host0/bus0/target0/lun0: I/O error: dev 08:00, sector 0
> I/O error: dev 08:00, sector 0
As far as I can see, at this point the kernel is doing everything
correctly. It even negotiated a complex series of reset commands and
reacted properly in the end by taking the device offline. The drive just
doesn't read its data, and in fact it seems to hang: After the READ
command it doesn't respond to TEST-UNIT-READY or drive reset. This
certainly has the appearance of a firmware problem.
I'm not sure what more can be done. Since the drive works okay with
Windows, some sort of USB snooping might provide a clue. I believe there
are programs available to do this sort of thing under Windows, although I
don't have any details.
My hope is that someone else on the mailing list can provide a suggestion.
Sorry I can't do any more.
Alan Stern
_______________________________________________
usb-storage mailing list
[EMAIL PROTECTED]
http://www2.one-eyed-alien.net/mailman/listinfo/usb-storage
NHY隊X'u*m(ZW謞(z+i"v^y+)n
)~ڝayZǨ)jp)W>alqz܂&v*reMzybn^elqz{.n+azV+֭ilqzlX)ߣbn^
