[eepro100] Too many interrupts
infos chez fdrconseil
infos at fdrconseil.fr
Mon Apr 4 08:52:15 PDT 2005
Le Sun, 3 Apr 2005 20:54:34 -0700 (PDT), Donald Becker <becker at scyld.com>
a écrit:
> On Sat, 2 Apr 2005, infos chez fdrconseil wrote:
>
>> I am using an Intel eepro 100 dual port adapter and I have a problem.
>> I want to use only one port (eth0) and no cable is connected on the
>> second
>> one.
>> The board is using IRQ 6; Apparently, there is no IRQ sharing.
>
> The motherboard sets the IRQ assignment. It tries to map one device per
> IRQ. With the APIC, Advanced Programmable Interrupt Controller, the OS
> has the option of reconfiguing so that the interrupt arrives on a "high"
> IRQ.
>
>> The problem is that the network board is raising a huge amount of
>> interrupts and the CPUs
>> (bi pentium III motherboard) are busy processing these interrupts (about
>> 10%).
>
> What is the packet count? The eepro100 driver, before it was modified by
> others, should raise about one interrupt per Rx packet. With normal
> traffic it's possible that all Tx packet will be handled without
> interrupts. With heavy traffic there should be less than one interrupt
> per Rx packet.
The packet count seems normal :
cat /proc/net/dev ; sleep 10 ; cat /proc/net/dev
Inter-| Receive |
Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:85309643 107592 0 0 0 0 0 0
85309643 107592 0 0 0 0 0 0
eth0:41981809 476933 0 0 0 0 0 0
177882307 149047 0 0 0 0 0 0
eth1: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Inter-| Receive |
Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:85314415 107598 0 0 0 0 0 0
85314415 107598 0 0 0 0 0 0
eth0:41985205 476985 0 0 0 0 0 0
177883471 149055 0 0 0 0 0 0
eth1: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
I understand eth0 received 52 packets in 10 seconds.
> Sometime people don't notice that their machine is being attacked with
> packets that are being immediately discarded.
I don't notice the machine is being attacked...
>> Contents of /proc/interrupts :
>> 6: 501331320 501309654 IO-APIC-level eth0
>> The same file, few seconds later :
>> 6: 502333959 502312308 IO-APIC-level eth0
>
> About a million interrupts. That's pretty intense. I'm guessing that
> you
> don't have a million packets reported in /proc/net/dev?
You're right, I don't.
> Do you get the high interrupt rate as soon as you start the system? Or
> only later? If only later, there might be an interrupt source that can't
> be cleared.
I've got it since i start the system.
> Here is a quick check: when you start getting a high interrupt rate,
> disconnect the cable or use 'mii-diag -F 10baseT eth0' to force the
> interface into slow transfers.
I issued the command "mii-tool -F 10baseT-FD eth0"
but it did not change anything.
I went back with "mii-tool -F 100baseTx-FD eth0" as it was.
>> Here is the dmesg messages when starting the system :
>> Apr 2 15:52:47 localhost kernel: eepro100.c:v1.09j-t 9/29/99 Donald
>> Becker http://www.scyld.com/network/eepro100.html
>> Apr 2 15:52:47 localhost kernel: eepro100.c: $Revision: 1.36
>> $ 2000/11/17
>> Modified by Andrey V. Savochkin <saw at saw.sw.com.sg> and others
>> Apr 2 15:52:47 localhost kernel: eth0: Intel Corp. 82557/8/9 [Ethernet
>> Pro 100], 00:02:B3:B6:2B:39, IRQ 6.
>>
>> The questions are :
>> - Am i wrong saying the problem comes from the network card ?
>
> Perhaps not. There may be some other interrupt source on IRQ6. The
> eepro100 driver interrupt handler is being run, but usually has nothing
> to
> do. If you didn't have a SMP your machine would appear to be hung.
I'm not sure I understand you fully : do you mean that with only
one processor, the system would be frozen ???
>> - What can I do ? (CPU power is wasted and CPU temperature increases)
>
> Run the above tests.
Ok. Done. Does it help ?
> Install the driver with debugging turned on to see if there are any
> interrupt sources.
Pretty complicated. Isn't it possible to activate some more information
without
recompiling the module ?
> Move the card to a different physical PCI slot to try to get another IRQ
> assignment.
>
As I said before on the list, this is a production server. It's a bit
difficult to stop it.
Anyway, I'll try to find a moment to do that.
Thank you for these answers,
FdR.
More information about the eepro100
mailing list