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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
