On Sun, 11 Jul 2004, Gerd v. Egidy wrote: > Ok, here we go with full logging: > > [...] > Jul 11 00:11:38 fire kernel: usb-storage: *** thread awakened. > Jul 11 00:11:38 fire kernel: usb-storage: Command READ_10 (10 bytes) > Jul 11 00:11:38 fire kernel: usb-storage: 28 00 00 00 4d 97 00 00 40 00 > Jul 11 00:11:38 fire kernel: usb-storage: Bulk Command S 0x43425355 T 0x73d L 32768 > F 128 Trg 0 LUN 0 CL 10 > Jul 11 00:11:38 fire kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > Jul 11 00:11:38 fire kernel: usb-storage: Status code 0; transferred 31/31 > Jul 11 00:11:38 fire kernel: usb-storage: -- transfer complete > Jul 11 00:11:38 fire kernel: usb-storage: Bulk command transfer result=0 > Jul 11 00:11:38 fire kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 32768 > bytes, 1 entries > Jul 11 00:11:38 fire kernel: usb-storage: Status code -71; transferred 11264/32768 > Jul 11 00:11:38 fire kernel: usb-storage: -- unknown error
This is slightly different from the normal failure mode of Genesys devices. You got error code -71, but the normal failure is a timeout. I don't know if this means anything. > This is from trying to mount my 200G reiser partition through dm-crypt. > The bug is 100% reproducable with this. It makes you wonder what's so special about dm-crypt? Maybe it just does more I/O than normal mounting, so it's more likely to provoke the problem. > I can sometimes reproduce it without dm-crypt: seldom at write and more > often with mounting. Another oddity; these problems usually show up more often with writing than with reading. > Ok, at first glance it looks like it's working with delay >= 350us > (I tried 200, 600, 400, 300, 350). > I can mount and have transferred some gigs - even with dm-crypt. > I'll run a torture test over night to find out if 350us is really working for me. > > It seems like it hurts performance a bit. I haven't done very reliable testing, > but it seems I can now (350us) write with 9,5 MB/s where I could do > 10,5-11 with 100us (when it was working, both times without dm-cyrpt > and debugging off). > > But isn't it strange that I need more than 3 times the delay than others do? > Maybe the position of the delay is wrong or we need to sleep at two different > positions (e.g. not just a delay between command and data, but maybe also > between data and the next command). You can try adding a delay there too, if you want. The appropriate place would be at the start of the usb_stor_Bulk_transport() subroutine. The technical support staff at Genesys Logic did not say that such a delay was needed, but they did say the one before the data phase was necessary. > After some hours of testing it still fails. And now it isn't even mounting > with 600us... > > As working and not working is this unpredictable and not consistent I think > there must be something else missing in the driver. I think there might be something else wrong with your device. It's behaving differently from other Genesys devices... Can you try to exchange it? Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
