Hello,

> There are 64 possible hardware irqs (ICU_LEN), the virq mechanism is nothing
> more than a renumbering of the hardware irq numbers into a smaller range
> that allows a single int to be used to hold a bitfield of masked or pending
> interrupts.  The virqs are dynamically allocated in mapirq(), if devices
> share a hardware irq they will correctly map to the same virq.
Ok, so I was completely off the mark :)

> >>So I guess everything on the USB card ( 3xOHCI, 1x EHCI ) should share the
> >>same virq, but the audio card >should get a different one.
> > 
> > 
> > It seems to me that devices with different IPL levels shouldn't share
> > virqs, too.
> 
> The levels blocked by intr_calcmasks() is the union of the IPL levels of
> all devices sharing the IRQ.  Sharing an IRQ between an audio and a USB
> device would be particularly bad: USB is supposed to be at a low priority
> (IPL_USB == IPL_BIO), but this device gets elevated to IPL_AUDIO.  Even
> worse, any code running at IPL_BIO would block the shared IRQ, so the audio
> interrupt will experience high latency.
Well, I can't help it - the slots not controlled by the PCI bridge hold the E100 which doesn't fit anywhere else and the graphics board which needs to sit in a slot directly controlled by a bandit because of firmware stupidity. 
Isn't there some way to differentiate between the bridge-controlled devices?

have fun
Michael