Alan Stern wrote: > On Fri, 30 Apr 2004 [EMAIL PROTECTED] wrote: > >> So, it looks like several things aren't working right: First, I >> would *expect* the GET_DESCRIPTOR command to finish executing on >> endpoint 0 even after the bulk in pipe stalls, but this doesn't >> appear to be the case. It >> looks like a stall on endpoint 1 also stalls endpoint 0. I can't >> find anything in the USB spec that explicity says how this should >> work. > > That should never happen; endpoints are supposed to be independent. > Also, endpoint 0 isn't supposed to stall unless the device is given a > request that it can't carry out. > >> Second, >> the Teac drive is returning in invalid status of 4, which I'm >> assuming is related to all the overlapping commands, since it >> doesn't happen with the semaphore in place. And, finally, the drive >> doesn't respond to GET_DESCRIPTOR commands at all after the bulk >> reset... but this may be caused by the same thing that caused it to >> return a status of 4. >> >> Granted, it is possible that these problems *may* be caused by the >> Teac CD-ROM not being as robust as it should be. However, if the >> Teac has this problem, I'm betting other devices do, too. It looks >> like the semaphore patch may fix another problem we're seeing here >> with a USB key--Gary's still checking it out. > > I think you're right that the drive itself is not robust. I've heard > others mention devices that get mixed up when they receive control > requests while executing a SCSI command. > > We have this problem even under 2.6. Ultimately the solution will > have to be to make the device single-access only. It's not clear how > to do that, and usbfs doesn't enforce such limitations at the moment. > > Alan Stern
With Pete's patch, I think that is all that's going wrong. My proposal to fix the issue (I didn't post the patch on here) was to add a semaphore to struct usb_device, and make the usbdev_ioctl() (in devio.c) grab that semaphore before doing the ioctl, and also make transport.c's usb_stor_Bulk_transfer() grab the semaphore before sending out the CBW (and release it only after getting back the CSW). Same thing for the other mass storage transports (though I hadn't actually included that in the patch I sent Pete). As far as I can tell, usbdev_ioctl is the only way that a control message would go out to thet device at the same time that usb-storage is sending out a SCSI/ATAPI command. Stuart ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
