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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
