> That's not an error. 36 bytes is the normal length of an INQUIRY > response. I'm not quite sure why the driver asks for 255 bytes; under 2.6 > it only asks for 36. The FIX_INQUIRY flag isn't needed.
INQUIRY len seems to be (errouneously?) hardcoded into scsi layer: 2.4.22 [scsi_scan.c:589] --------- scsi_cmd[0] = INQUIRY; [.....] scsi_cmd[4] = 255; --------- 2.6 [scsi_scan.c:333] --------- scsi_cmd[0] = INQUIRY; scsi_cmd[4] = 36; /* issue conservative alloc_length */ --------- So the problem is this other reader that successfully (but not correctly if the INQ is only 36 bytes long!) transfer all 255 bytes: ============================= Nov 26 17:16:06 epia kernel: usb-storage: *** thread awakened. Nov 26 17:16:06 epia kernel: usb-storage: Command INQUIRY (6 bytes) Nov 26 17:16:06 epia kernel: usb-storage: 12 00 00 00 ff 00 1b c0 84 67 5e c5 Nov 26 17:16:06 epia kernel: usb-storage: Bulk command S 0x43425355 T 0x1 Trg 0 LUN 0 L 255 F 128 CL 6 Nov 26 17:16:06 epia kernel: usb-storage: Bulk command transfer result=0 Nov 26 17:16:06 epia kernel: usb-storage: usb_stor_transfer_partial(): xfer 255 bytes Nov 26 17:16:06 epia kernel: usb-storage: usb_stor_bulk_msg() returned 0 xferred 255/255 Nov 26 17:16:06 epia kernel: usb-storage: usb_stor_transfer_partial(): transfer complete Nov 26 17:16:06 epia kernel: usb-storage: Bulk data transfer result 0x0 Nov 26 17:16:06 epia kernel: usb-storage: Attempting to get CSW... Nov 26 17:16:06 epia kernel: usb-storage: Bulk status result = 0 Nov 26 17:16:06 epia kernel: usb-storage: Bulk status Sig 0x53425355 T 0x1 R 0 Stat 0x0 Nov 26 17:16:06 epia kernel: usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0 Nov 26 17:16:06 epia kernel: usb-storage: scsi cmd done, result=0x0 Nov 26 17:16:06 epia kernel: usb-storage: *** thread sleeping. =============================k stefano On Friday 28 November 2003 05:12, Alan Stern wrote: > On Thu, 27 Nov 2003, Stefano Barbato wrote: > > Alan, > > > > I got some more cards to try and all worked correctly. > > > > It seems that the card I was using for testing (it's an old 8Mb compact > > flash) confuses this reader (oh, btw, it's called Atech PRO-9 [search > > engines this is for you]) that stop working after receiving the first > > command when such card is inserted. > > > > other info: > > - the same card work on other readers and it also worked (but it took > > about a minute or more thinking...) on a windows (ME) laptop. > > - on 2.6 the same happens. > > - I've got two of those readers and both hang with the same 8Mb card. > > Weird. Some sort of strange card <-> reader interaction. > > If you're _really_ curious about why it works (albeit after a long delay) > under Windows, there is a freely-available program called USB-Snoopy you > can use to monitor the communication between Windows and the reader. But > it's probably not worth the trouble. > > > I also noticed that the device fails answering correctly to the first > > INQUIRY command. I don't know much about the driver code but the > > usb_stor_bulk_msg() just transfered 36 of 255 bytes but apart of the > > strange info returned everything work properly after that. I think that > > a US_FL_FIX_INQUIRY would be needed if correct device info are preferred. > > That's not an error. 36 bytes is the normal length of an INQUIRY > response. I'm not quite sure why the driver asks for 255 bytes; under 2.6 > it only asks for 36. The FIX_INQUIRY flag isn't needed. > > > Here is the INQUIRY log: > > ========================================== > > Nov 26 17:20:10 epia kernel: usb-storage: *** thread awakened. > > Nov 26 17:20:10 epia kernel: usb-storage: Command INQUIRY (6 bytes) > > Nov 26 17:20:10 epia kernel: usb-storage: 12 00 00 00 ff 00 1b c0 84 73 > > 5d c5 Nov 26 17:20:10 epia kernel: usb-storage: Bulk command S 0x43425355 > > T 0x1 Trg 0 LUN 0 L 255 F 128 CL 6 > > Nov 26 17:20:10 epia kernel: usb-storage: Bulk command transfer result=0 > > Nov 26 17:20:10 epia kernel: usb-storage: usb_stor_transfer_partial(): > > xfer 255 bytes > > Nov 26 17:20:10 epia kernel: usb-storage: usb_stor_bulk_msg() returned 0 > > xferred 36/255 > > Nov 26 17:20:10 epia kernel: usb-storage: Bulk data transfer result 0x1 > > Nov 26 17:20:10 epia kernel: usb-storage: Attempting to get CSW... > > Nov 26 17:20:10 epia kernel: usb-storage: Bulk status result = 0 > > Nov 26 17:20:10 epia kernel: usb-storage: Bulk status Sig 0x53425355 T > > 0x1 R 0 Stat 0x0 > > That R(esidue) value of 0 is wrong, however. It should be 255 - 36 = 219. > Fortunately it doesn't matter. > > > Nov 26 17:20:10 epia kernel: usb-storage: Fixing INQUIRY data to show > > SCSI rev 2 - was 0 > > Nov 26 17:20:10 epia kernel: usb-storage: scsi cmd done, result=0x0 > > Nov 26 17:20:10 epia kernel: usb-storage: *** thread sleeping. > > ========================================== > > > > Thanks for your help. > > > > stefano > > You're welcome. > > Alan Stern > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
