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

Reply via email to