Comment 4 for bug 130075

I'm getting this message in Edubuntu Feisty AMD64 while doing tests with iperf on a gigabit link. Both iperf client and server are using the forcedeth driver on identical nic/motherboards. While the failing driver is running in the OS mentioned above, I've had no trouble on the second machine running Ubuntu server 7.04 AMD64.

I've found some potentially related threads in other forums:

http://lists.debian.org/debian-amd64/2006/08/msg00274.html
http://www.nvnews.net/vbulletin/showthread.php?t=57791&page=11

Here the command that causes it for me:

iperf -c 192.168.0.195 -i 2 -f mbps -t 30 -d -P 16

-P 8 doesn't seem to cause a problem.

Here's the partial output of dmesg when the link goes down:

[ 1235.537521] eth1: too many iterations (6) in nv_nic_irq.
[ 1247.641652] NETDEV WATCHDOG: eth1: transmit timed out
[ 1247.641657] eth1: Got tx_timeout. irq: 00000036
[ 1247.641660] eth1: Ring at 7b5ec000: next 2597442 nic 2597186
[ 1247.641662] eth1: Dumping tx registers
[ 1247.641667] 0: 00000036 000000ff 00000003 017203ca 00000000 00000000 00000000 00000000

I tried bringing down the link, reloading the forcedeth module and bringing the link back up, but then dmesg | tail gives:

[ 1301.525982] eth1: forcedeth.c: subsystem: 01043:816a bound to 0000:00:14.0
[ 1301.553024] eth1: no link during initialization.
[ 1301.553263] ADDRCONF(NETDEV_UP): eth1: link is not ready

although the interface is connected and lit up.

As per somebody's recommendation from an above-linked thread, I tried adding the following option to the forcedeth driver at boot, but I haven't succeeded in doing so:

"options forcedeth max_interrupt_work=20"

I've also attached the output of sudo lspci -vvn.