> alternative to the out of band approach for the purposes you described. > Now, I even think that I could perhaps fix the request aborting properly I'm not sure the two are mutually conflicting. The queued reset you've done is very much cleaner so in theory you can abort the command in the ioctl and then queue the rest of the reset/recovery as you have done > equivalent for HDIO_DRIVE_RESET in libata which makes me wonder whether > this ioctl has actually been used in real life for the purposes you > described. Its on the todo list along with more speed control - it gets hard to do right and cleanly. > My idea to solve this would be roughly this: Change ide_set_handler to > leave the ->handler and ->expiry members alone if they have been set on > entry. If a request is being processed by the time a HDIO_DRIVE_RESET The basic problem is that we have to issue a speed change and the driver layer speed change code assumed this was issued polled with a wait (in fact for some controllers/disks it has to be polled). Not a good thing to discover you are doing in an IRQ handler ... > Comments? I think your basic approach is right. It might be that the abort path wants to abort and then queue the rest. I could of course be completely wrong too 8) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
