On Thu, 20 Mar 2014, James Bottomley wrote: > OK, so I think we have three things to do > > 1. Investigate SCSI and fix it's abort state problem that's causing > it not to send the abort second time around > 2. Fix usb-storage to fail a reset it can't do (i.e. device reset > with outstanding commands) > 3. Find out why we're sending a spurious request sense. > > I can look at 1 and 3 if you want to take 2.
I wrote a patch for 2. It turned out not to help much, because I was wrong -- while a command is running, usb-storage won't do a bus reset either. The lock occurs in a separate part of the code, where I wasn't looking earlier. When I tested the patch, the device reset failed immediately (as desired) and then the attempted bus reset hung. Overall, not much of an improvement... In fact, this restriction on bus resets is important and necessary. USB devices can be composite, meaning they can contain several functions all packed into a single device. If a driver for one of the other functions needs to perform a bus reset, we don't want it to interrupt an ongoing mass-storage command. Thus, it is important for the reset routine to wait for an outstanding command to complete. Anyway, this looks to be a moot point. With your fix for 1, neither sort of reset was necessary. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
