Alex:
I was very pleased to get your message. You are giving the driver a good
workout!
On Tue, 2 Sep 2003, Alex Sanks wrote:
> Anyway, I've tried running it with a 2280 board attached to a Windows XP
> host and ran into some problems. I don't know if you've ever watched
> what mass storage on Windows does, but it seems to always try to execute
> SCSI command 0x23. What this is, I have no idea (it's vendor specific
> according to the SCSI spec) In any case, naturally this command fails
> and the endpoint is stalled and an INVALID COMMAND status is returned in
> the CSW. So far so good.
>
> After the failed command, a REQUEST SENSE (0x03) command is called by
> the host to see what happened. Unfortuantely, for some reason, the CBW
> is sent with bCBWCBLENGTH == 12, while the spec indicates command 0x03
> is a 6 byte command. I confirmed this is really happening with a CATC
> trace. Of course 12 != 6 so the device reports a phase error, resets,
> and this repeats forever. My driver simply didn't check if the lengths
> were sane so I never encountered this problem, but it looks to me like
> Windows isn't following the spec, although I haven't seen anyone else
> mention this problem. Disabling the cmnd_size == fsg->cmnd_size in
> check_command gets around that (temporarily for testing purposes anyway)
I'll put in a test to allow for this special case. See below.
> From there I can partition the drive just fine and its state is
> remembered when the device is disconnected. Unfortunately, the
> partitions won't format for me. Odd, since the partition is created
> just fine. I'm not entirely sure why this is. A trace show no obvious
> errors (no stalling, resets, etc.). And I can see a successful CSW
> returned for the last CBW sent out. But CBWs just stop coming for some
> reason.
>
> I tried formatting from Linux, but mkfs.msdos appeared to have hung.
> Eventually I pulled the plug and switched it to a Windows host and saw
> that it had formatted fine. The last commands I see are disk reads, so
> I have a feeling that the drive is getting formatted more or less
> correctly, but something's failing when it's verifying the filesystem.
> If I try to format it as ext2, it makes it past "writing inode tables"
> but hangs on "writing superblocks and filesystem accounting information".
I'll try doing this with the dummy_hcd driver. Up to now I've only tried
ordinary filesystem reads and write, not format operations.
Later: it worked. Of course, plenty of things that work okay with
dummy_hcd can still fail with other drivers.
> Additionally, and I don't know if this is related or not, just after
> enumeration I see a MODE SENSE requested with a page code of 0x1c. This
> stalls since it's an unhandled page code, and is followed by a REQUEST
> SENSE. Then a MODE SENSE with page_code=0x3f is sent. It returns the
> 16 bytes that it should and I see them on the USB. But a CSW is never
> sent and the device resets. Here's a little except from syslog (it has
> a few extra printks I put in to see what was going on, since I don't
> know your code that well):
I wonder if the problem could be related to the size of the reply. When a
reply message is shorter than the host expects (which doesn't happen too
often -- MODE-SENSE is one of the few cases where it does occur) the
gadget driver sets the request->zero flag, telling the controller to send
an extra 0-length packet if the reply is an exact multiple of the bulk-in
endpoint's maxsize. That's the only place the zero flag is set; maybe
it's causing your problem? You could try commenting out the line near the
end of decode_scsi_cmnd() that says
bh->inreq->zero = 1;
It might make a difference.
> file-storage gadget: SCSI command length = 10: 25 00 00 00 00 00 00 00 00 00
> file-storage gadget: SCSI command length = 6: 1a 00 1c 00 c0 00
> valid_page=0, page_code=0x1c
> !valid_page (0) || len (4) > limit (255), page_code=0x1c
> file-storage gadget: phase-error=0, reply=-22, stalling
> file-storage gadget: sending command-failure status 336896
> file-storage gadget: SCSI command length = 12: 03 00 00 00 12 00 00 00
> 00 00 00 00
> SC_REQUEST_SENSE
> file-storage gadget: SCSI command length = 6: 1a 00 3f 00 c0 00
> valid_page=1, page_code=0x3f
> file-storage gadget: Returning 16
> net2280 0000:00:0e.0: disconnect file-storage
> file-storage gadget: bulk_out_complete --> -108, 0/31
> file-storage gadget: invalid CBW: status -108 len 0 sig f cmdlen 255
> file-storage gadget: reset config
> file-storage gadget: reset interface
> net2280 0000:00:0e.0: high speed
> net2280 0000:00:0e.0: disconnect file-storage
> net2280 0000:00:0e.0: high speed
> file-storage gadget: set interface 0
> net2280 0000:00:0e.0: enabled ep-a (ep1in-bulk) dma max 0200
> net2280 0000:00:0e.0: enabled ep-b (ep2out-bulk) dma max 0200
Given what you described, this looks about right -- except for the
unwanted disconnect. That could be the result of the controller driver
getting confused somehow.
> Right now the disk file is pointed to a 100MB file dd'd from /dev/zero
> (I don't have a spare drive to try in there).
>
> I can provide you with a CATC trace of an attempted format, if you have
> a way to view it (there is a free viewer for Windows available from
> http://www.catc.com, but I don't know if there's a way to do it from Linux).
>
> Anyway, I'll keep looking into these problems, but I've got several
> things on my plate right now so I don't know how much help I can be, but
> it'd be great if we can get this up and running. It looks like it's
> almost there. Not bad at all, considering you've been doing this
> without hardware!
>
> regards,
> Alex Sanks
> NetChip Technology, Inc.
If my suggestion doesn't help, send the CATC trace. I can use the free
viewer, and maybe looking at it will help.
Thanks for your efforts on this!
Alan Stern
--- gadget-2.6/drivers/usb/gadget/file_storage.c.old Tue Sep 2 11:47:43 2003
+++ gadget-2.6/drivers/usb/gadget/file_storage.c Wed Sep 3 16:22:17 2003
@@ -1862,8 +1862,14 @@
int i;
int lun = fsg->cmnd[1] >> 5;
- if (cmnd_size != fsg->cmnd_size)
- goto illegal_command;
+ if (cmnd_size != fsg->cmnd_size) {
+
+ /* Special case workaround: MS-Windows issues REQUEST-SENSE
+ * with cbw->Length == 12 (it should be 6). */
+ if (!(fsg->cmnd[0] == SC_REQUEST_SENSE &&
+ fsg->cmnd_size == 12))
+ goto illegal_command;
+ }
if (fsg->data_dir == DATA_DIR_UNKNOWN) {
fsg->data_dir = data_dir;
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
