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.
That is, two slot interrupts but only one CA1 interrupt. The nubus is now
wedged, since there will be no further transitions on CA1.
2. On VIA2-based macs, don't attempt to disable nubus slots by making the
IRQ lines outputs and then driving them high (!)
IIRC we got that idea from BSD early on - what's wrong with this?
Problem is it implies the need for the nubus_active psuedo mask -- which
in its present form is guaranteed to lose interrupts. Eliminating
nubus_active is not so easy (see irq_plan_a & irq_plan_b patches --
artificially masking interrupts like this means you have to remember them
and also dispatch nubus IRQs upon enabling them).
But imagine this scenario: we disable a slot and drive the IRQ line high,
while the slot drives it low. Now we enable that slot (make it an input).
If this change of loading on the VIA's port A pin increases the settle
time, it is possible that the CA1 umbrella interrupt (the OR function of
all the nubus slots irqs) will fire before the VIA sees the port A pin go
low... this is because the via inputs and the OR gate inputs are not
electrically the same.
In this hypothetical, the nubus will get wedged, since there will be no
further transitions on CA1 to raise the VIA2 IRQ... things are much
simplier if we don't tie outputs together... it is true that some nubus
cards permit a wired-OR circuit on their /IRQ line, but "Designing Cards
and Drivers for Macintosh II and Macintosh SE" says Macs don't do that...
so what mac cards really do with their /IRQ line electrically is anyone's
guess.
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?
But better be safe anyway.
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.
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
