Hello,
I think there is some kind of bug or something in the driver 8139too.
Supossedly, receive interrupts are disabled when a hardware interruption
is received, but anyway receive interrupts keep on triggering. Below I show
the two interruption masks are used throughtout the driver. The first is set
in the NIC whenever there is not "work" for the card, i mean, all the packets
have been received. The second is set whenever a receive interrupt arrives.
static const u16 rtl8139_intr_mask =
PCIErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOver |
TxErr | TxOK | RxErr | RxOK;
static const u16 rtl8139_norx_intr_mask =
PCIErr | PCSTimeout | RxUnderrun |
TxErr | TxOK | RxErr ;
I have added a trace in rtl8139_interrupt() in order to know which
interruptions get triggered each time. When receiving a packet the
normal thing is:
8139too (eth1): Interrupt: mask= intr_mask (49279) status= RxOK (1)
But if the receive interrupts are disabled for a quite long time I can
get messages like these:
8139too (eth1): Interrupt: mask= norx_intr_mask (49198) status= RxOK (1)
............
8139too (eth1): Interrupt: mask= norx_intr_mask (49198) status= RxOK
RxOverflow RxFIFOOver (81)
As you see, the mask is norx_intr_mask (in parentheses you have the
integer value of the appropiate register). In status, you can see the
interrupt status register of the NIC when the interruption is
triggered.
Now, how can this be possible?
The only flags that are set are those that cannot trigger a hardware
interrupt (see the definition of norx_intr_mask above). Then how
triggered the hardware interrupt? Is there a timeout or something in
the rtl8139 which, after a certain time, triggers interrupts even if
they are disabled?
Note also that there are not transmission interrupts here, as these
are the results of a machine which just captures the traffic on a
Ethernet link, it does passive capturing, and does not send anything.
Regards
Aritz
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
