Alan Stern wrote:
> This certainly does look like the classic Genesys Logic usb-storage
> problem. The workaround that was added to 2.6.9 has helped many people,
> but apparently it's not adequate for your drive.
>
> You could try increasing the internal time delay. If you edit the
> drivers/usb/storage/transport.c file in the kernel source and search for
> GENESYS, on the next line you'll see
>
> udelay(100);
>
> You could change the 100 to 200; maybe it will help.
Yes, it helped. :))
The appended patch fixes this problem for me. As I am not sure if waiting for
additional 100 �s causes a noticeable difference in regard of performance, I
wrote a few lines to distinguish the chips by idProduct and bcdDevice.
I am not happy with the "magic numbers", what's the best way to get rid of
them?
Thank you very much for your help!
Dieter Weber
*** linux-2.6.9/drivers/usb/storage/transport.c 2004-10-28 14:54:51.000000000 +0200
--- 2.6.9-modified/drivers/usb/storage/transport.c 2004-11-04 19:44:30.000000000 +0100
***************
*** 984,992 ****
/* Genesys Logic interface chips need a 100us delay between the
* command phase and the data phase */
! if (us->pusb_dev->descriptor.idVendor == USB_VENDOR_ID_GENESYS)
udelay(100);
!
if (transfer_length) {
unsigned int pipe = srb->sc_data_direction == DMA_FROM_DEVICE ?
us->recv_bulk_pipe : us->send_bulk_pipe;
--- 984,997 ----
/* Genesys Logic interface chips need a 100us delay between the
* command phase and the data phase */
! if (us->pusb_dev->descriptor.idVendor == USB_VENDOR_ID_GENESYS) {
udelay(100);
! /* At least one Genesys Logic interface chip needs
! * even more delay */
! if ( (us->pusb_dev->descriptor.idProduct == 0x0702)
! && (us->pusb_dev->descriptor.bcdDevice == 0x0002) )
! udelay(100);
! }
if (transfer_length) {
unsigned int pipe = srb->sc_data_direction == DMA_FROM_DEVICE ?
us->recv_bulk_pipe : us->send_bulk_pipe;
