> 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.
> --- 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.
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.
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)
But Ctrl-C stops waiting "dd" immediately.
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.
> > usb-storage is very unstable when connect/disconnect/reconnect is considered
> > (but probably this is what I get for using *-bk* kernels).
>
> Yes. A patch to fix that was recently posted. See
>
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-May/000338.html
I will wait until official 2.6.7 is released before I test it.
> 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.
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.
> Let me know how your tests go, especially the Genesys change.
At the moment looks good.
Next week I will probably have questions about:
Bus 004 Device 005: ID 0424:223a Standard Microsystems Corp.
(6 in 1 reader UISDMC1S - can read only CF flash, does not register other SCSI
devices)
Bus 001 Device 005: ID 07cc:0201 Carry Computer Eng., Co., Ltd
(8 in 1 Card Reader USB 2.0, also reads only CF slot. I think in some older
kernels more SCSI devices were registered for them).
usb 1-2: new full speed USB device using address 5
scsi57 : SCSI emulation for USB Mass Storage devices
Vendor: SPRING Model: MultiCard Slot A Rev: 0100
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sdb at scsi57, channel 0, id 0, lun 0
USB Mass Storage device found at 5
usb 4-1: new high speed USB device using address 5
scsi58 : SCSI emulation for USB Mass Storage devices
Vendor: SMSC Model: 223 U HS-CF Rev: 1.95
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sdc at scsi58, channel 0, id 0, lun 0
USB Mass Storage device found at 5
Best regards,
--
Tomasz Motylewski
BFAD GmbH & Co. KG
P.S. Thank you very much for assistance.
-------------------------------------------------------
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
