card error (& crash & irq sharing)

[James Harper]

> > i just noticed this error in my event log, the first line is
complaining
> > abount a situation that is obviously not true
> >  
> > wlan0: Interrupt, but SWSUPPORT0 does not match: 8A32 != 8A32 - card
> > removed?
> 
> Actually, that situation was probably true, but not anymore at the
point
> that line was printed. SWSUPPORT0 registers is read twice, but the
> result from the first read is not reported here. I have seen this
> happening with PCI Prism2.5 cards. Which card and firmware versions
were
> you using (i.e., NICID, PRI and STA f/w versions)?
> 
> Obviously the reset would not be needed if the register was correct.
In
> fact, this SWSUPPORT0 magic number verification code could be
commented
> out anyway. It is there just to recover from error situations (mostly,
> card hang/firmware confused, etc.). In ideal world those would not
occur
> ;-).

Yeah. I noticed that. I think I have also tracked down what preempts
this...
My computer is SMP, I have the following PCI adapters in my system:

IDE0 - on board BX chipset ide on irq 14
IDE1 - on board BX chipset ide on irq 15
ETH0 - on irq 16
NVIDIA - on irq 16
BTTV0 - bt849 tv tuner/video capture on irq 17
IDE2 - on board hpt366 chipset ide on irq 18
UHCI-HCD - on board USB adapter on irq 19
WLAN0 - Dlink prism 2.5 wireless adapter on irq 19
ENS1371 - sound adapter on irq 19

I set up a test where I was ping flooding on both the wlan0 and eth0
adapters, it went for about 5 minutes without problems. The moment I
started playing sound the system gave the 'wlan0: Interrupt, but
SWSUPPORT0 does not match...' error, started a card reset, then hung the
whole system (everything frozen, need power off).

There is no way I can change the configuration of my pci devices. My tv
card refuses to work if it shares an irq, and anything sharing an irq
with IDE2 also causes problems. (failure is immediate rather than after
a while as with the wireless card)

Isn't PCI supposed to like (or at least not dislike) sharing an IRQ with
another card? Is my problem likely to be a hardware or a software issue?
How exactly does linux cope with the shared irq? Does the _interrupt
proc get called for every device connected to an irq or does the kernel
figure out which device was responsible and only call that one? (if the
former is the case, then it looks like we are trying to read the
SWSUPPORT0 number when it didn't generate an irq, and is probably in the
middle of doing something else - is that a bad thing?)

Is it worth my while commenting out the card verification code? It
appears that it doesn't do it if it's not using PCI bus master, but I'm
not and I'm still getting the SWSUPPORT0 misread that the comments refer
to. 

It will typically crash within an hour or two of being turned on, but
occasionally within minutes.

Thanks

James