https://bugzilla.novell.com/show_bug.cgi?id=342148#c6 --- Comment #6 from Harald Koenig <koenig@linux.de> 2007-11-21 07:03:23 MST --- update: this morning I did not get a link connection at all (tried different cable, asked network/switch admin etc.) unless I did rmmod/modprobe e1000 again :-( obviously after rmmod, now everything works fine again and I couldn't trigger the problem with two short suspend2ram/resume cycles. (In reply to comment #5 from Brandon Philips)
It looks like you are running the fglrx driver. Can you reproduce the issue without it?
not possible right (at least as long as I don't know how to quickly trigger the problem). I need the fglrx module and I have the kill the X server and my whole display session to remove it. not an option right now, sorry.
Also, it looks like in some cases you are specifying parameters for `modprobe e1000`. Why are you doing this?
since the update 10.2 -> 10.3 I again suffer severe latency problems on our gigabit network (had similar problems already with 10.2, but with 10.2 "InterruptThrottleRate=0" fixed this and now with 10.3 I get ping output to local hosts or the gateway like this: 64 bytes from atuin (10.0.3.70): icmp_seq=1 ttl=63 time=99.4 ms 64 bytes from atuin (10.0.3.70): icmp_seq=2 ttl=63 time=108 ms 64 bytes from atuin (10.0.3.70): icmp_seq=3 ttl=63 time=0.639 ms 64 bytes from atuin (10.0.3.70): icmp_seq=4 ttl=63 time=108 ms 64 bytes from atuin (10.0.3.70): icmp_seq=5 ttl=63 time=0.562 ms 64 bytes from atuin (10.0.3.70): icmp_seq=6 ttl=63 time=108 ms 64 bytes from atuin (10.0.3.70): icmp_seq=7 ttl=63 time=1000 ms 64 bytes from atuin (10.0.3.70): icmp_seq=8 ttl=63 time=108 ms 64 bytes from atuin (10.0.3.70): icmp_seq=9 ttl=63 time=0.645 ms 64 bytes from atuin (10.0.3.70): icmp_seq=10 ttl=63 time=104 ms sustained throughput of tcp connections (e.g. scp) is ok though, but e.g. running X11 sessions over ssh completely sucks (starting a plain X client takes 20-30 seconds because of those latencies for every small packet!). with the 10.3 driver (and the most recent e1000 driver from intel.com) I get sustained good ping rates only with "RxIntDelay=0" -- and I have to patch the driver for this chip in order to get "RxIntDelay=0" working (this value is out of range by default). unfortuneately, this setting only optimizes ping/latency and reduces sustained unidirectional tcp stream throughput dramatically :-( all the switch/can't-ping problems have occured with the unpatched suse e1000.ko module -- patched/recompiled modules have been loaded only for short periods for some ping tests. so back to the original problem...
Can you reproduce the problem without specifying InterruptThrottleRate or RxIntDelay?
I've removed my modprobe.conf.local for now, I'll wait and see (possibly tomorrow morning...?!)
I am lowering the priority since there is no clear pattern to reproducing the issue and it seems to be working now.
ok. thanks for your input so far! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.