Re: Too many interrupts
"infos chez fdrconseil" <[email protected]> Mon, 04 Apr 2005 17:52:15 +0200
| Newsgroups | gmane.linux.drivers.eepro100.devel |
|---|---|
| Organization | FdR Conseil |
| Message-ID | <[email protected]> |
Le Sun, 3 Apr 2005 20:54:34 -0700 (PDT), Donald Becker <[email protected]>= =20 a =E9crit: > 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 =20 >> 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 pe= r > 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 (abo= ut >> 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 | =20 Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes = =20 packets errs drop fifo colls carrier compressed lo:85309643 107592 0 0 0 0 0 0 =20 85309643 107592 0 0 0 0 0 0 eth0:41981809 476933 0 0 0 0 0 0 =20 177882307 149047 0 0 0 0 0 0 eth1: 0 0 0 0 0 0 0 0 = =20 0 0 0 0 0 0 0 0 Inter-| Receive | =20 Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes = =20 packets errs drop fifo colls carrier compressed lo:85314415 107598 0 0 0 0 0 0 =20 85314415 107598 0 0 0 0 0 0 eth0:41985205 476985 0 0 0 0 0 0 =20 177883471 149055 0 0 0 0 0 0 eth1: 0 0 0 0 0 0 0 0 = =20 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 = =20 > 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 =20 >> $ 2000/11/17 >> Modified by Andrey V. Savochkin <[email protected]> and others >> Apr 2 15:52:47 localhost kernel: eth0: Intel Corp. 82557/8/9 [Etherne= t >> 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= =20 > 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 =20 without recompiling the module ? > Move the card to a different physical PCI slot to try to get another IR= Q > assignment. > As I said before on the list, this is a production server. It's a bit =20 difficult to stop it. Anyway, I'll try to find a moment to do that. Thank you for these answers, FdR.