> > This one does need dealing with. It happens in the real world and the old > > IDE paths for this do get triggered and used now and then (we know this > > because bugs in them were found). All it takes is a device and a > > controller disagreeing about the length of a data transfer to get in a > > How would they disagree (excluding human error)? Human error with SG_IO is quite sufficient, or controller bugs. It happens: we see it happen and stuff gets stuck that way sometimes when you get a timeout. For some controllers a failure gets stuck because of the FIFO magic they do. > It's not really a good idea for SATA. The "FIFO" often co-emulated by > the SATA controller and SATA phy. You just want to kick SATA really > hard (i.e. bus reset and friends). Possibly we need a per controller ->drain_fifo method if available. It's precisely because the FIFO is "magic" that some of the PATA controllers get stuck in a mess (eg they hold off IRQ until the FIFO is drained) 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
