On Thu, 2014-03-20 at 15:59 -0400, Alan Stern wrote: > 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... Hm, yes, sorry, after the bus reset fails, we'll just take the device offline. > 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. Well as long as the tiny hammer works ... but there are going to be devices that need the bigger one one day. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
