https://bugzilla.novell.com/show_bug.cgi?id=342148#c2 Brandon Philips changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bphilips@novell.com, kkeil@novell.com --- Comment #2 from Brandon Philips 2007-11-20 11:57:35 MST --- Could you attach the output from `dmesg` while you are seeing the issue? Is there any pattern to the times it works and the times it doesn't? Have you tried other wired networks? Perhaps you could try testing the latest kernel-default from this repository? http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/ -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=342148#c4 --- Comment #4 from Harald Koenig 2007-11-20 12:58:53 MST --- (In reply to comment #2 from Brandon Philips)

Could you attach the output from `dmesg` while you are seeing the issue?

done (without/before the test suspend cycles below).

Is there any pattern to the times it works and the times it doesn't? Have you tried other wired networks?

not that I'd realize. right now I have the impression that once "it happens" the driver/stack is stuck until I rmmod/modprobe e1000 driver... any idea how to query some driver (tcp stack?) data before/after rmmod/modprobe such that a comparision might give some hints ? I just did a rmmod/modprobe e1000 and then did a few suspend/resume from/to ram cycles with unplug/replug ethernet etc (typical very day duty cycle) but I haven't been successfull trying to trigger problme -- right now ping works fine without tcpdump...

Perhaps you could try testing the latest kernel-default from this repository? http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/

can't promise it but I'll try to... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=342148#c6 --- Comment #6 from Harald Koenig 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.

https://bugzilla.novell.com/show_bug.cgi?id=342148#c7 --- Comment #7 from Brandon Philips 2007-11-21 15:30:47 MST --- Are you sure that the interface is up when you resume? Can you run `rcnetwork restart` or `ifconfig ethX up` to fix the issue without the rmmod/modprobe cycle? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=342148#c9 Karsten Keil changed: What |Removed |Added ---------------------------------------------------------------------------- CC|kkeil@novell.com | --- Comment #9 from Karsten Keil 2007-11-22 07:18:59 MST --- This looks like the driver doesn't see the packet and since setting promiscuous mode helps it looks like that the HW lost the MAC address in the receive path. If you are in the fail situation, can you please do a ifconfig and check if the MAC address is correct ? I do not remember that we changed the driver since RC1, so I do not understand why this problem comes from a recent kernel update, but I'll recheck. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=342148#c11 Karsten Keil changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkeil@novell.com --- Comment #11 from Karsten Keil 2007-11-22 11:35:19 MST --- OK I verified that here were no changes in e1000 since RC1. Best for you would be to go back to the old kernel to verify that this was OK and then do something like a bisect, to find the critical change. The fglrx driver is still a problem, was it updated or recompiled to match the kernel version ? -- 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.