On Thu, 14 Jul 2005, Pete Zaitcev wrote: > On Thu, 14 Jul 2005 22:06:04 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> > wrote: > > > > But calling this cancel adds an opportunity for racing somewhere. > > > > No it doesn't. The opportunity was there all along. Remember, the caller > > could call usb_sg_cancel from another thread at precisely this time. > > I don't think ub does that.
What happens if you rmmod ub just as the sg list is being submitted -- doesn't your disconnect routine cancel any I/O in progress? (Not to mention, what happens when some driver other than ub starts using your library routine?) > > Trusting unlinks is a separate matter. However I think they are pretty > > well under control now. I can't recall hearing of any problems in the HCD > > code relating to buggy unlinks for quite some time. > > OK, yes, they are much better than used to be. But still, I think that > invoking an unlink doesn't save us anything. The occasions where a submit fails and previous submissions continue to run are so few and far-between that it's not worth worrying about. > Not having a call to sg_cancel there is one more obstacle to factoring > submission out from usb_sg_wait like you proposed, but that is hindered > by other things as well (e.g. yield()). If those are gone, I'll think > about it again. > > BTW, I think I saw an unlink which did not return a callback today. > Not crashing, granted. It happens very infrequently... I saved a trace > accidentially: > > d83010e8 697580560 S Bo:005:01 -115 31 = 55534243 1b000000 00080000 80000a28 > 00000000 00000001 00000000 000000 > d83010e8 697580611 C Bo:005:01 0 31 > Send CBW for READ(10) command. > d83010e8 697580641 S Bi:005:02 -115 2048 < > d83010e8 697580862 C Bi:005:02 0 0 Receive 0-length packet for data. > d83010e8 697580895 S Bi:005:02 -115 13 < > d83010e8 697580986 C Bi:005:02 -32 0 Try to read CSW, get STALL. > d83010e8 697581018 S Co:005:00 s 02 01 0000 0082 0000 0 > d83010e8 697581112 C Co:005:00 0 0 Clear-Halt. > d83010e8 697581140 S Bi:005:02 -115 13 < > d83010e8 697581236 C Bi:005:02 0 13 = 55534253 1b000000 00080000 01 Read CSW, code indicates command failed. > d83010e8 697581267 S Bi:005:02 -115 13 < What's this? Trying to read another CSW? No wonder you hung... > d83010e8 881232539 C Bi:005:02 -71 0 <------ pulled plug > d83010e8 881232612 S Bi:005:02 -115 13 < > d83010e8 881232777 C Bi:005:02 -71 0 Try to read CSW yet again, immediate failure since the device is not attached. > d83010e8 881232820 S Bo:005:01 -115 31 = 55534243 1d000000 12000000 80000603 > 00000012 00000000 00000000 000000 > d83010e8 881232901 C Bo:005:01 -71 0 Try to send CBW for REQUEST SENSE, immediate failure. > Look at the jump in the timestamp. It's where I became tired from waiting > and pulled the cable. The unlink itself is not captured by usbmon, because > they are rather reliable normally, and you see a callback with status -104. > I skipped on implementing that. But I guarantee you that ub tries an unlink > from a timer. Are you sure it did so in this case? The presence of those two extra CSW reads indicates that _something_ in ub wasn't working right. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
