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. -- Random pauses when transferring data at gigabit speeds with forcedeth driver https://bugs.launchpad.net/bugs/130075 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
