Hello, On 01/11/2010 06:41 PM, Benjamin Herrenschmidt wrote: > On Mon, 2010-01-11 at 16:01 +0900, Tejun Heo wrote: >> It would be best if the controller has an IRQ pending bit and IRQ can >> be cleared as spurious on those bogus interrupts. The reason why SFF >> IDE interface is so prone to IRQ storm is because there's no way the >> driver can tell whether the controller is raising interrupt or not. >> Does the controller have a way to clear IRQ other than reading the >> status reg? > > Nope. Those old Apple controllers have neither a pending bit nor a > clear, I think the disk interrupt is wired pretty much directly to > the PIC. Eh.... I really hate this part of IDE. :-( > I can't tell for sure about Mikael's precise case because I can't > reproduce it, but in the past, I've seen the CD drive act up similarily > when touching NIEN on a wallstreet powerbook (same controller, though > for some reason it doesn't act up for me right now) and reading the > status reg wasn't clearing the IRQ neither. > > I suspect those guys have the IRQ in some kind of floating state after > the HW reset and don't get it "right" until they get the first taskfile > to kick them into some kind of shape... I think the only solution then is to disable the IRQ from the PIC. We'll probably need to generalize there a bit as it seems there are odd cases where we fall into IRQ storm but for now I think adding special case code with sufficient comment should do it. Thanks. -- tejun -- 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
