# eth0: excessive work at interrupt

## hoosierpeschke

I constantly see this error in my /var/log/messages.  It wouldn't bother me so much is that I have severe network performance problems.  Mainly I see it when I'm accessing my NFS profile share.  I also use my computer as a backup for my server so when I perform a backup I'm usually transferring around 3-5GB.  When I had SUSE installed on this same computer I had no issues and the transfer would complete in just under 20 minutes.  Now it takes almost 2 hours.  Googling the subject I get kernel code for the via_velocity module.  Here's my ethernet output for lspci

```

peschke01 ~ # lspci | grep Ethernet

00:07.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11)

```

I have the via_velocity compiled into the kernel... I know I have the correct driver, just not sure what my problem is.

I'm wondering if anyone has seen this problem before, has this problem, or could otherwise help before I try the genkernel.  I much prefer compiling my own (that's why I use Gentoo in the first place   :Wink:  ).  Thanks!

----------

## sdpeterson

I did an emerge update world yesterday and I now suffer from the 'eth0:  Too much work in interrupt' issue as well.  Networking will work fine for half an hour then bonk (network completely drops; loss of IP address).  Restarting network services does not resolve the issue, though a reboot does.  Restarting net.eth0 results in an invalid DHCP server response.  Normally I would start systematically going through the packages that were updated to find the culprit, but there were 246 of them.  They were mostly KDE 3.5.3 packages, excepting libutempter, firefox, and some seemingly innocuous cruft.  Any suggestions other than 'don't emerge masked packages'     :Wink:  ?  Thanks in advance.

----------

## sdpeterson

It turns out that if I wait long enough a timeout will occur and eth0 will reset itself, giving me network again.  dmesg reports:

```

NETDEV WATCHDOG: eth0: transmit timed out

eth0: transmit timed out, tx_status 00 status e000.

  diagnostics: net 0c4c media 8880 dma 00000032 fifo 8000

  Flags; bus-master 1, dirty 0(0) current 16(0)

  Transmit list 00000000 vs. f7b59200.

  0: @f7b59200  length 80000070 status 0c010070

  1: @f7b592a0  length 80000070 status 0c010070

  2: @f7b59340  length 8000004a status 0001004a

  3: @f7b593e0  length 8000004a status 0001004a

  4: @f7b59480  length 80000047 status 0c010047

  5: @f7b59520  length 8000002a status 0001002a

  6: @f7b595c0  length 80000047 status 0c010047

  7: @f7b59660  length 8000002a status 0001002a

  8: @f7b59700  length 80000047 status 0c010047

  9: @f7b597a0  length 80000047 status 0c010047

  10: @f7b59840  length 8000002a status 0001002a

  11: @f7b598e0  length 8000005a status 0c01005a

  12: @f7b59980  length 8000002a status 0001002a

  13: @f7b59a20  length 8000002a status 0001002a

  14: @f7b59ac0  length 8000002a status 8001002a

  15: @f7b59b60  length 8000002a status 8001002a

eth0: Resetting the Tx ring pointer.

bridge-eth0: disabling the bridge

bridge-eth0: down

ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11

bridge-eth0: enabling the bridge

bridge-eth0: up

```

Any ideas?

----------

## hoosierpeschke

I'm at my wit's end with this issue although mine doesn't sound as bad as yours.  Mine is just painfully slow network across nfs, which, I use nfs to backup data and for my wife's and my profiles.

----------

## sdpeterson

I'm beginning to worry that my problem is hardware related.  I booted this morning and the kernel didn't detect eth0.  I was able to power cycle and get it back, but that has me concerned.  I'm now sitting in Windows waiting to see if network disappears in this platform as well.  Argh I say, argh.

----------

## hoosierpeschke

I loaded up SUSE 10.1, did a backup from my server, and I'm getting the same error.  I'm beginning to think it's a kernel driver issue.  I'm continuing to troubleshoot but I gotta reload gentoo back on.... so I can look again in about a week!

----------

## perfessor101

I just got a sabrent via velocity gigabit network adapter on Gentoo (current updates) and I'm getting the eth0: excessive work at interrupt. error.  When I type dmesg it just gives me eth0: excessive work at interrupt fifty times and nothing else is listed.

I'm getting about 150Mbps through the card with no lockups, but I miss my dmesg  :Wink: 

Bobby

----------

## hoosierpeschke

I have gentoo loaded back up on my rig... I created a problem for myself on my server which has helped me troubleshoot a little more...  Here's the story.

In the midst of compiling kde, I was working with my server, trying to reformat my external usb hard drive.  I had lost my thumb drive and needed some FAT space for the unfortunate use of Windows at work.  No matter how many times it can be said that a user is the weakest point in the system, it never fails for me to have a lapse in judgement and prove it.

Anywho, I'm fdisk'd in to /dev/sda and happily `d, n, 1, [enter], +5G, n, 2, [enter], [enter], w`.  For those who don't speak fdiskese I deleted the 1 partition that was on the drive, and created a 5GB partition and another partition that filled up the rest.  I try and format the second partition (dosfstools wasn't done emerging) and I get an error, filesystem in use by kernel or something along those lines.  WTF.  I cycle the power on the usb drive and try again.  Same error.  I hit the good 'ole ALT+F12 to check out the log and to my dismay, the usb drive was device /dev/hdc.

GAH!!!

Did I mention I was working on my server by the way?  Did I mention I have a 200GB SATA drive that I keep all of my profile, cd images, media (mp3s, funny clips, etc.), Windows programs, and just about every bit of vital and useful data.  Thankfully, the kernel had locked the in-use filesystem so my data was still intacted although as soon as I would reboot I'd essentially lose all that data (yes, I'm aware of data recovery, but I didn't have to go that route).  I had my main rig up enough to setup the nfs server and everything mounted to perform the backup. 

Now, more on topic, as stated in previous threads, I noticed my error when backing up the 200GB SATA drive on the server, to the 200GB SATA drive on my main rig.  As I began the backup this time, I was monitoring the logs, hoping that a fresh install or a couple of kernel settings I changed might adjust this.  Nope.  Same error.  But, as before it took around 2-3 hours to backup the essential data, it only took 18 minutes.

So long story short (too late), my problem is somewhat solved.  In my original setup, nfs support was built into the kernel.  This time, I built nfs server support into the kernel and voila, awesome transfer speeds.  Now this stays until I load all the rest of the crap back onto my system to ensure that my fast speeds stay consistent.

As for the "excessive work" error, I know that's built into the via_velocity driver as Google reveals the code for.  I'm going to find a good branch to study but I'm starting to think it's nothing more than a printf %DEBUG% message that didn't get deleted or commented out.

----------

