Hi Alan, Thank you for your help and useful comment.
Alan wrote: Haruo> I tested using kernel 2.4.22-bk6. It failed by the Haruo> following two patterns. Haruo> 1. Bulk command transfer result=-104 Haruo> 2. usb_stor_bulk_msg() returned -32 Alan> This was two different failures on two separate runs? Yes. I tested separately. It is because it is hard to generate an error in testing two simultaneously. When testing simultaneously, much time is required by the time it generates an error. The reason is not known. Haruo> 1. Bulk command transfer result=-104 [skip] Alan> This was the same sort of pattern we saw before. No data was Alan> transferred from the drive, and the command timed out Ａｌａｎ> and was aborted. I am also looking at this pattern repeatedly. It seems that a device does not answer in the case of kernel 2.4. However, when operating by kernel 2.6 and two or more devices are connected simultaneously, it operates. I cannot think the error of a device. [skip] Haruo> hub.c: port 1, portstatus 503, change 10, 480 Mb/s Haruo> usb.c: ignoring set_interface for dev 3, iface 0, alt 0 Haruo> usb-storage: Examinging driver usb-storage...skipping ourselves. Haruo> usb-storage: bus_reset() complete Alan> This time the bus_reset() routine worked, which is an Alan> improvement over Alan> what you were seeing before. But the device still didn't respond: If a device becomes an error, it seems that reset is not effective. Using ioctl (fd, USBDEVFS_RESET, 0) and this device, Is checking whether a device can reset correctly by performing effective? [skip] Haruo> scsi: device set offline - not ready or command retry Haruo> failed after bus reset: host 0 channel 0 id 0 lun 0 Haruo> SCSI cdrom error : host 0 channel 0 id 0 lun 0 return code = 50000 Haruo> I/O error: dev 0b:00, sector 473224 Haruo> I/O error: dev 0b:00, sector 473228 Haruo> I/O error: dev 0b:00, sector 473476 Haruo> I/O error: dev 0b:00, sector 473224 Alan> Once that happened there were no error recovery procedures Alan> left to try, so Alan> the driver gave up and marked the device offline. Doesn't a device receive any commands? Alan> There's something a little strange I just noticed in the log. It's Alan> probably not related to your problem, but we should check it Alan> out anyway. Alan> Please send a copy of /proc/bus/usb/devices, with the drive Alan> plugged in. OK. > > 2. usb_stor_bulk_msg() returned -32 Alan> Under what circumstances did this error occur? It must have Alan> been quite different from the other error. The used device(Logitec LCW-WIN40U2) is different. It is the same circumstances except a device. Haruo> usb-storage: usb_stor_transfer_partial(): xfer 2048 bytes Haruo> usb-storage: usb_stor_bulk_msg() returned -32 xferred 0/2048 Haruo> usb-storage: -- code: 0x70, key: 0x2, ASC: 0x4, ASCQ: 0x1 Haruo> usb-storage: Not Ready: LUN in process of becoming ready Alan> That's normal. It means that the drive was just turned on or Alan> reset, and it's not yet ready to execute commands. I see. Haruo> usb-storage: Unit Attention: not ready to ready transition Haruo> More of the same. This means that the drive just finished its Haruo> initialization and now it's ready to operate. Haruo> usb-storage: scsi cmd done, result=0x2 Haruo> usb-storage: *** thread sleeping. Haruo> I/O error: dev 0b:00, sector 804236 Haruo> I/O error: dev 0b:00, sector 804240 Haruo> I/O error: dev 0b:00, sector 804492 Haruo> I/O error: dev 0b:00, sector 804236 Alan> But apparently at this point the SCSI driver got tired of Alan> waiting and set Alan> the drive offline. This should be fixed in the SCSI driver. If a SCSI driver performs retry, is it that usb-storage can also restart processing? Alan> That's why Alan> it's important to know what you were doing when the error occurred. Ok, echo is put into a script, and as processing can be distinguished, test it. Thanks again, Haruo ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
