On Mon, 29 Jan 2007, Michael Schmitz wrote:
I'm guessing that possibly the interrupt is not being ack'd correctly
(perhaps the act of testing it clears it)... or maybe slot F doesn't get
latched like the others (perhaps because it is effectively cascaded 3
deep). I need to do more experimentation.
I've finally fixed it! (I started on these irq patches in 2005...)
Congratulations! Nubus had me baffled since much longer :-)
There's nothing wrong with the IDE driver. But nubus is another story
altogether... basically, the fix is,
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:
1. slot $D asserts /IRQ, causing a negative transition on CA1
(recall that CA1 is the (active low) OR function of all the slot lines)
2. CA1 interrupt invokes nubus irq handler which services slots in this
order $E ... $9, like so:
3. it checks $E (IRQ not asserted)
4. it checks $D and detects IRQ, invokes handler
5. assume that /IRQ on slot $E fires at this point, causing no transition
on CA1 since it is still asserted by slot $D
6. handler for $D clears that IRQ, and now it is only slot $E that is
keeping CA1 asserted
7. check $C ... $9 (IRQs not asserted)
8. nubus handler exits
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.
3. Since there's no slot irq mask on these macs, don't attempt to
disable nubus slots individually -- just mask the VIA2 CA1
interrupt. That way no nubus interrupts go missing.
Right ...
This is the real cause of the boot hang due to a nubus IRQ. But, according
to Designing Cards and Drivers, MacOS has the same problem. So, cards that
are well-behaved under macos shouldn't present great difficulty.
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.
4. When using the A/UX irq scheme, install sonic irq handlers on BOTH slot
9 and auto vector 3 -- otherwise, the 1-in-100000 slot 9 interrupt
kills us.
Ah, that's a new one :-)
Yes. So far I've seen this on both my Q630 and LC630.
-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
