On Thu, 1 Feb 2007, I wrote:
> Anyway, you can see now why I had to eliminate nubus_active (as well as > looping over the slot lines until none were asserted) -- If we drop an > interrupt by masking it with nubus_active, we don't get another CA1 > transition when we re-enable it, and the nubus stays wedged. > > These two fixes seem to be sufficient to fix IDE -- you don't really > need to give up disabling IRQs by making them outputs. But you have to > ask, what was nubus_active needed for in the first place? > > The only answer I could think of is that some cards in some machines > can't be disabled by making the IRQ line an output. That is, the > asserted /IRQ still reads low because the slot pulls it low despite the > VIA pulling it high. (The VIA datasheet warns against this possibility, > whereby the output register reads differently than whatever was written > to it when the outputs are loaded up). > > If this is true, I figured, then nubus_active and this method of > disabling slot IRQs are both beyond redemption. I just tested my Mac II and this certainly seems to be the case. The network card gives lots of NETDEV WATCHDOG TX timeouts and barely works when I remove nubus_active (see the irq_plan_d patch). Which brought to mind what Brad told me 18 months ago about how macs with genuine VIAs behave differently than those with emulated VIAs. > That was my motive for irq_plan_c, which just disables CA1 instead of > disabling individual slots... but is of course, subject to stray > interrupt problems. This approach works on all the macs I've tested. The only issue was the LCIII raising a nubus IRQ (DP8390) at the wrong moment. But when I think about it, this can only be because the early setup code is not working right on RBV (RBV and probably the others that have slot enable flags)... It would be nice if Penguin could disable DP8390 chips as well. [snip] > > > I haven't yet tested NuBus video cards with my patches, but I did > > > anticipate problems. Well, I have now. The TFB card in the Mac II posed no problem. I also checked the source code for Penguin and it deliberately disables the interrupts from video cards. > But I'm wondering if there is a better solution. We could unmask CA1 (by > installing the handler) only after all (supported) nubus cards have > their drivers loaded -- but before the kernel needs to use them. I've no > idea how to accomplish that order of operations. Can the device model > help?? This may not end up being necessary, since most unexpected IRQs can probably be solved by other means. -f - To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
