Subject: Re: Interrupt sharing
To: None <port-macppc@NetBSD.ORG>
From: Donald Lee <MacPPC1@caution.icompute.com>
List: port-macppc
Date: 12/05/2004 16:25:15
comment from the gallery...

This sounds really familiar.  I have seen something similar with my
Cyclades serial card.  I am convinced that interrupts get "lost".
I ended up "fixing it" by implementing a poll that processes the
by occasionally calling the interrupt handler directly from an
event loop.  Ugly, but it works.

In my case, the PCI serial card "fails" in this way in every machine I've
tried - 7300, Beige G3, PM G4. (posting "MacPPC interrupts - Cyclades"
12/31/2000)

If I get really worked up, I would be inclined to blame the problems with
IDE/ATA cards on this too.  I've not debugged that one myself, but
it sounds familiar - lost interrupts, timeouts, etc. (posting:
"Oops: pciide0:0:0: lost interrupt" from 3/11/2004)

How about the problems I posted with "NetBSD 1.6.2 ping times" (7/7/2004)?
This also sounds like potential "lost" interrupts.

In short, fixing the interrupt machinery is pure, powerful Goodness. ;->

-dgl-


>Hello,
>
>I have the following problem:
>all PCI devices behind the PCI bridge in my S900 share the same interrupt ( more or less because Apple tied interrupts to PCI slots and the bridge sits in one ). In my case that's an USB controller (ohci) and a Yamaha audio card (yds). Each one alone works fine, but things get awry when both are busy at the same time, like playing some music and fsck'ing a USB disk ( or moving the mouse for a while ) - then all processing for the shared IRQ stops. Other interrupts aren't affected, only the shared one. 
>After some hacking I found this:
>- the audio chip seems to generate a lot of interrupts, they queue up every couple of seconds 
>- the pending mechanism seems to work fine, the IRQ gets disabled, the pending flags are set and in do_pending_int() it's enabled again. 
>- when things lock up the IRQ is enabled, marked as pending and apparently gets processed but then it either doesn't fire again or doesn't get processed.
>
>I think there's a race somewhere - it looks like the shared interrupt gets processed but not always cleared so it doesn't fire again.
>
>have fun
>Michael