Udo A. Steinberg wrote:

>My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between ACPI
>and e100 an IRQ9 storm occurs when e100 is enabled, as can be seen in the
>dmesg output below. The kernel then disables IRQ9, thus preventing e100 from
>working properly. The problem does not occur, if I override the default PCI
>steering in the BIOS, e.g. by routing LNKA to IRQ11.
>
>Nonetheless it would be good if someone could figure out why sharing IRQ9 
>is problematic.
>  
>
Udo, please try the attached 2.6.9 patch.

I suspect intel e100 driver always had problems with shared interrupts, 
due to a classic case of
"executable comment syndrome" in the original intel driver.
I noticed races on some of our ancient boxes with e100s, sharing 
interrupts with other e100s, or other cards.

The intel e100 v2.0.40 e100intr() code says.....
        intr_status = readw(&bdp->scb->scb_status);
        /* If not my interrupt, just return */
        if (!(intr_status & SCB_STATUS_ACK_MASK) || (intr_status == 
0xffff)) {
                return IRQ_NONE;
        }

But the test above is *not* "not my interrupt" but "no interesting 
conditions".
Both tests are needed for reliable operation in a shared-irq scenario.

When the driver is meddling with e100 setup, causing intr_status bits to 
pop up, but has not yet enabled
e100 interrupts, a "stray" interrupt from a device sharing the IRQ will 
cause e100intr() to walk all over the
device even if the driver is in a critical section.  Chaos ensues -- in 
my case duplicate skb_free calls when
a parasitic interrupt "completed" processing of tx ring skbs which napi 
bh was still setting up.

Compare with becker's eepro100, where there are (IIRC) 3 locks -- a lock 
on tx resources, a lock on rx resources, and an implicit lock by way of 
the card's interrupt-enable bit.  If you enable interrupts, you're
allowing the irq-handler to play with tx,rx resources without any other 
locks.  So a courteous irq-handler will
check to see if it has been granted the privilege, by inspecting the 
interrupt-enable bit.
Other drivers follow this model, but e100 driver merely has a misleading 
comment instead of the check.

I'd guess that Udo's problem appears when...
- e100 driver is meddling with card, with e100 interrupt enable *off*
- ACPI interrupt causes e100intr to be invoked parasitcally, cleaning up 
(or breaking) some half-finished
   work intended to be guarded by interrupt-enable bit
- driver enables e100 interrupt
- e100-driven IRQ calls e100intr(), finds no work to do
- (conjecture) 2.6.10-rc1 actually checks the IRQ_NONE return, notes 
spurious interrupt & disables IRQ

Our e100 problems went away on hundreds of old linux-2.4 dual-e100 boxes 
when the attached e100-v2-irq-share.patch was applied. It applies 
cleanly to linux-2.4.27, but is untested there.
I'd seen no lkml mention of shared-irq e100 problems, so was letting it 
bake for a couple of weeks before
declaring success, porting it to recent 2.6 and publishing.

But Udo has a problem, so let's see if this fixes it...
My linux-2.6.9 patch is an untested transliteration to intel's e100-v3 
driver structure.
(v3 driver has one e100.c, v2 has e100/*.c tree, cutover was about 
2.6.4? 5?)

I'm not sure if this is implicated in the widespread mistrust of e100 
multiport cards under linux, the e100-eepro100 wars, or the recent 
e100-suspend problems. Could be the missing piece in all.


^..^ feedback very welcome
(oo)