On Sun, 30 May 2004, Tomasz Motylewski wrote:
> > If you want, you can try applying the patch below to 2.6.6 or 2.6.7. It
> > changes the existing code to look for a short CSW rather than a 0-length
> > CSW. I don't think it's as safe as the existing code, but if it helps
> > people we'll try to put it in. Judging by other people's logs, though,
> > I'm not too confident. The problem with Genesys interfaces hasn't been
> > that they provide a short CSW, it's that they don't send any CSW at all --
> > they just stop working.
>
> Probably because the driver does not request status again after seeing short
> CSW. May be other reasons.
No, it's definitely "other reasons". The driver does not see a short CSW
-- it doesn't see any CSW at all. In fact, the transfer is aborted even
before the preceding write completes because the device stops responding.
And even after trying multiple resets, the device still doesn't respond.
> > --- usb-2.6/drivers/usb/storage/transport.c Fri May 28 17:09:18 2004
> > +++ usb-2.6/drivers/usb/storage/transport.c Sat May 29 15:12:27 2004
> > @@ -997,12 +997,9 @@
> > - if (result == USB_STOR_XFER_SHORT && cswlen == 0) {
> > + if (result == USB_STOR_XFER_SHORT) {
>
> Yes, this works as well. I have tested it in clean 2.6.6 kernel with and
> without above patch.
I think your problem must be different from what other people are seeing.
> Without above patch the error is not always easy to reproduce. What triggers it
> for me is:
>
> cat /dev/urandom > /dev/sda
> (after about 10 s red LED starts blinking about every 1 s, urandom is slower
> than the disk), then in fact it may work quite well for some time.
With other people the red LED goes on and stays on indefinitely.
> But it usually does not survive "sync" on another console. It causes about 2s
> long burst (flush) of data with the patch, and device hangs without.
>
> cat /dev/zero > /dev/sda somehow does not (always) hang it, despite it
> saturates the bandwidth similar like sync.
>
> Another problem (with both patched and not patched driver 2.6.6) is that every
> write access after the end of the raw /dev/sda device blocks.
> e.g. dd if=/dev/zero of=/dev/sda count=1 bs=1k seek=1000000000
> blocks for over 1 minute and then gives IO error (SCSI return code 0x8000002)
Is that true even if you haven't done anything else previously, i.e., no
bandwidth-saturating writes (or no writes at all)? If it is, post a
usb-storage debugging log showing the time delay.
> But Ctrl-C stops waiting "dd" immediately.
That makes it sound like the delay is not in usb-storage, since the driver
does not recognize interrupt signals.
> One more thing which has annoyed me with the nonpatched driver was that dd
> if=/dev/urandom of=/dev/sda did not recognize for more than 15 minutes (I did
> not wait longer) that the device is already offline (klog was full of
> "rejecting I/O to offline device", it was not possible to open() /dev/sda
> anymore, but write() was still returning success on the previously open
> device). I know that buffered write() can not guarantee success, but writing to
> device which is already offline since minutes should be detected. In my opinion
> device going offline should work like forced umount.
That may be an artifact of the way I/O is handled. Probably dd's write
calls to the system returned success and the data was buffered, and the
errors didn't start until the buffers were flushed to the device. But I
don't know the details.
> > Some of the USB hotplugging utilities can be very intrusive and interfere
> > with normal device operation. One that has been particularly bad is
> > usbmodules (I think that was the program). If you can disable it maybe
> > things will work better.
>
> I have it, but I do not think it is in use. End even no "new high speed USB
> device ..." appears.
Well, that's a different story. It could be that problems with
usb-storage have blocked the USB hub driver. If the hub driver is waiting
for usb-storage to finish disconnecting the disk drive then it can't
respond to additional devices being plugged in.
> The success rate on connecting is 60-70% (2.6.6, patched). But after it is not
> recognized once, then I have to unplug/plug is several times to get the
> device. I have a feeling this is Genesys problem as well. The success rate is
> tolerable a the moment.
If you turn on USB debugging in the kernel configuration then you'll be
able to see what happens when connecting a new device fails.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
