On Sun, 11 Jul 2004, Florian Schmitt wrote: > Ok, I did some more testing with 2.6.5. > > > Try looking at more logs and see if they all fail at the same place, i.e., > > during the INQUIRY command. > > Now it gets interesting: with 2.6.5 the INQUIRY works as expected:
Hmm... I see two separate problems here. > Jul 10 23:46:36 phoenix kernel: usb-storage: USB Mass Storage device detected > Jul 10 23:46:36 phoenix kernel: usb-storage: altsetting is 0, id_index is 122 > Jul 10 23:46:36 phoenix kernel: usb-storage: -- associate_dev > Jul 10 23:46:36 phoenix kernel: usb-storage: Transport: Bulk > Jul 10 23:46:36 phoenix kernel: usb-storage: Protocol: Transparent SCSI > Jul 10 23:46:36 phoenix kernel: usb-storage: Endpoints: In: 0xd84cdb94 Out: > 0xd84cdb80 Int: 0xd84cdba8 (Period 1) > Jul 10 23:46:36 phoenix kernel: usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 > value=0000 index=00 len=1 > Jul 10 23:46:36 phoenix kernel: usb-storage: GetMaxLUN command result is -32, data > is 0 > Jul 10 23:46:36 phoenix kernel: usb-storage: *** thread sleeping. Notice that with 2.6.5, when GetMaxLUN fails the system does not try to do a Clear Halt. That may be the first problem you face in 2.6.7. You can test this by editing the source code for 2.6.7. In the file drivers/usb/storage/transport.c, locate the subroutine usb_stor_Bulk_max_lun() and comment out the two lines that call usb_stor_clear_halt(). > After that, there is a lot of output (I don't want to flood the list with it)... > it looks to me as if the problems in 2.6.5 arise at following point: > Jul 10 23:46:39 phoenix kernel: usb-storage: Attempting to get CSW... > Jul 10 23:46:39 phoenix kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 > bytes > Jul 10 23:46:39 phoenix kernel: usb-storage: Status code 0; transferred 13/13 > Jul 10 23:46:39 phoenix kernel: usb-storage: -- transfer complete > Jul 10 23:46:39 phoenix kernel: usb-storage: Bulk status result = 0 > Jul 10 23:46:39 phoenix kernel: usb-storage: Bulk Status S 0x53425355 T 0x15 R 512 > Stat 0x1 > Jul 10 23:46:39 phoenix kernel: usb-storage: Bulk logical error You cut out too much of the log above, so I can't tell what command failed or why. I'm going to guess that it's the same as the next command (i.e., the command was retried after the first failure). > Jul 10 23:46:39 phoenix kernel: usb-storage: -- auto-sense failure > Jul 10 23:46:39 phoenix kernel: usb-storage: usb_stor_Bulk_reset called > Jul 10 23:46:39 phoenix kernel: usb-storage: usb_stor_control_msg: rq=ff rqtype=21 > value=0000 index=00 len=0 > Jul 10 23:46:39 phoenix kernel: usb-storage: Soft reset failed: -32 > Jul 10 23:46:39 phoenix kernel: usb-storage: scsi cmd done, result=0x70000 > Jul 10 23:46:39 phoenix kernel: usb-storage: *** thread sleeping. > Jul 10 23:46:39 phoenix kernel: usb-storage: queuecommand called > Jul 10 23:46:39 phoenix kernel: usb-storage: *** thread awakened. > Jul 10 23:46:39 phoenix kernel: usb-storage: Command INQUIRY (6 bytes) > Jul 10 23:46:39 phoenix kernel: usb-storage: 12 01 80 00 ff 00 > Jul 10 23:46:39 phoenix kernel: usb-storage: Bulk Command S 0x43425355 T 0x16 L 512 > F 128 Trg 0 LUN 0 CL 6 Here is the second problem: a very nasty INQUIRY command. It tells the device to transfer 255 bytes (that's the "ff" byte above) while telling the usb-storage driver that 512 bytes will be transferred (that's the "L 512" in the Bulk Command line). This sort of thing is strictly illegal; the two transfer lengths _must_ be equal. The command also requests "vital product data" (that's the "01" byte above). The USB and SCSI drivers never issue such a command by themselves. It must be coming from somewhere else, and the most likely source is a hotplug program. I suggest you see what happens when you turn off hotplug support. 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-users
