Comment 8 for bug 130075

I've played around with it a bit more, and even with the options max_interrupt_work=20 set in /etc/modprobe.d/forcedeth, it still happens. Only additional thing to report, is I happened upon an easy way to reproduce the hangup every time:

1. Login to machine1 which has a gigabit ethernet card in it and is attached to a gigabit switch. Run "iperf -s"

2. Login to a machine that has the gigabit forcedeth adapter in it - also hooked up to a gigabit switch. Run "iperf -c machine1 -d".

The command in step two generates a lot of traffic in that it tells it to test speeds going both ways at once. On both my forcedeth systems, it will lock up the interface almost immediately, requiring a full reboot (i.e. /etc/init.d/networking restart has no effect). Note the problem only occurs under heavy load - if you just run iperf -c machine1 without the -d option, it usually won't lock up.

Should we report this bug to the kernel mailing list? I see that back in August, someone reported similar behavior in 2.6.22.1 but said adding the forcedeth.max_interrupt_work=20 option to their bootline fixed it (FWIW, I tried that and just go invalid option with feisty). Here is the thread:

http://lkml.org/lkml/2007/8/5/92

Does anyone know how to tell if the options in modprobe.d are in effect - dmesg doesn't show anything and lsmod doesn't have any flags? I have tried putting the appropriate line in /boot/grub/menu.lst, in /etc/modprobe.d/options, and in /etc/modprobe.d/forcedeth and as best as I can tell none have had any effect.

P.S. I'm now wishing I had spent a little more and bought Intel boards with Intel NICs.