On Wed, 31 Jan 2007, Michael Schmitz wrote:
> > > > 1. Don't exit the nubus interrupt handler until there's no irq > > > > flagged. > > > > > > Which may yet kill us if we don't manage to ack (think graphics > > > cards here). > > > > Yes. I've seen this occasionally on my LCIII (the 8390 network card > > IRQ) ... no problem yet on the Q650, LC630 and IIsi. But the cause is > > not what you suggest. Anyway, because CA1 is edge triggered, it is > > imperative that we don't exit the nubus handler before all active slot > > IRQs are de-asserted. For example: > > [snip] > > Color me corrected - I thought CA1 was level triggered, hence the > interrupt storm. > > If we changed it to edge triggered, we're safe from that but must make > sure all cards get serviced _and_ release \IRQ properly. My understanding is that the VIA only provides +ve or -ve edge triggering on CA1. And of course the IRQ lines are active low, so I don't think we get any choice. 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. 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. > > So, in essence, what you say is the interrupt trigger level and the > input low detection level may be different... did you actually see that > happen? Not sure. And I can't say it isn't happening either. It could be hidden in the interval between the CA1 interrupt being asserted and being cleared. Only after that moment do we check the slot flags. So, if you reduced the interrupt latency by overclocking etc, maybe you would see it (?) > But better be safe anyway. The other potential problem with driving IRQ lines high is that mac_irq_pending() can't work for disabled slots. > > I haven't yet tested NuBus video cards with my patches, but I did > > anticipate problems. I thought of a few possible solutions, for machines > > that have this issue: > > > > - Boot MacOS with extensions off, or > > - Use Emile, not penguin, or > > - Get the bootloader to disable a chip interrupt (as it does with sonic) > > or install dummy interrupt handlers for any problematic supported cards > > (ethernet, video), and remove unsupported cards. > > The attempt to disable problematic interrupts in Penguin didn't solve all > problems (Sonic perhaps needs to be shut down completely, not just the > interrupt), so emile or extensions off it is. I need to do some more tests with video cards. Thinking about it some more, turning of extensions or booting from emile may not work for those cards (I seem to recall that they use ROM drivers). Maybe the boot loaders can disable them... 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?? -f > > Michael > - 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
