On Fri, 12 Jan 2007, Michael Schmitz wrote:
However, there is still a very old bug there, where heavy IDE and
SONIC traffic together cause all the NuBus interrupts (which are only
SONIC & IDE on this machine) to cease altogether. I'll probably do
some more work on this, but I'm not optimistic; others have tried and
failed --
http://marc.theaimsgroup.com/?l=netbsd-port-mac68k&m=96498911504667&w=2
Maybe the max. loop count in the Nubus inthandler gets exceeded, and the
nubus int gets disabled? We used to do that :-(
You are right that clearing the nubus irq flag was done in the wrong order
since about v2.3, but we fixed that upstream for via2 about a year ago. I
noticed recently that it wasn't just the VIA IRQs that were broken, it was
PSC & OSS too. I have patches to fix up the other IRQ controllers
(untested on OSS).
The loop counter looks correct. The IDE interrupt is cascacded off slot F.
And it would appear that IDE used to be polled from the VIA1 IRQ
handler (I guess the F108 chip is another of Apple's mysteries...)
I think we found out the interrupt source for IDE? That polling would
then be leftover crud and should be killed.
Yeah, the polling code is #if 0. Which is fine by me.
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.
-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
-
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
