Bugzilla Bug 185491

Hi,
Running latest stable 2.6.21-r4, after random time and heavy load networking
breaks (only icmp works)
Found a thread about same issue here:
http://marc.info/?l=linux-kernel&m=118202978609968&w=2
Also a Bug-report:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243960
Still haven't looked at the Bug but can confirm it on one system i'm using.
Will post emerge --info later, the computer is at work.
Thanks.Rumen

Reproducible: Always

Same here, but only when I boot with vesafb mode.
It hangs at runlevel 3 when lights up eth interfaces.
Do you use a framebuffer console?

Hi,

Yes, i'm using FB-mode but that not a problem for me, boot&log etc OK.
The problems start later afterwards at random time.
All is Ok with 2.6.20-r8
Regards, Rumen

For me it hangs at runlevel 3 only when I append
"video=vesafb,option1,option2..." to bootloader (grub).
The vesafb mode is 1280x1024-32@60 in kernel defaults when no video option is
specified at boot time.
If I boot without options, the kernel boot normally and this bug doesn't
appears EVER.
When I boot with parameters (videomode) the kernel hangs at runlevel 3 when try
to activate eth ifaces.

I have similar problems at my box, but I'm not sure, if they are related.
I'm running on an amd64-system using a wireless networking setup with an
atheros chipset (thus using the madwifi driver).
My graphic adapter is an ATI Radeon 9550 (i.e. an RV350 chipset). When using
the fglrx driver within X, everything is OK, but when using the open sourced
driver from the X.org project (i.e. the radeon driver), the networking locks
after a random time.
dmesg shows:
   wifi0: rx FIFO overrun; resetting
   wifi0: ath_reset: unable to reset hardware: 'Hardware didn't respond as
expected' (HAL status 3)

Nicola: your problem is unrelated -- yours happens at boot, but the original
report here talks about random amounts of time after boot.

Sebastian: I also don't see any reason why yours might be the same problem.

Please file new bugs, don't pollute existing ones unless you are >=90% sure
they are the same.

Rumen, which is the last known working kernel for you? Have you tried 2.6.22?
Please attach dmesg output from after the point where networking breaks, and
also please clarify exactly what you mean by "networking breaks"

Hi,

Still haven't tried 2.6.22 (will do), running a stable kernel here in order to
minimize surprises etc.
gentoo-sources-2.6.20-r8 is the latest stable kernel for me (running it now).
Networking breaks means: after some random time (from 5-10 min. to 1,2 hours)
browser stops loading pages (connects and waits till connection timeout).
Same for ssh-sessions, connection stops working at the middle of a keystroke.
Strange is that ping (ICMP) works with same sites.
Usually restarting fixes it for some time, than it breaks again.
Will attach it (dmesg output) but only later (can't break my connection right
now, sorry). Will check the logs too.
Thanks. Rumen

Hi,

More info, my network-card is:
02:02.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip
compatible 10/100 Ethernet (rev 40) - lspci info
Using "Davicom DM910x/DM980x support" driver in the kernel.
Suspect some ACPI-issues to cause this, in the logs:
Jul 15 11:38:04 rumen dmfe: Change Speed to 100Mhz full duplex
...end...
Just now saw that the driver in the kernel config *changed*
Seems the oldconfig is using one for DM910x/DM980x (dmfe) while the real chip
is:21x4x DEC-Tulip.
All this is from newest 2.6.22-r1 kernel-config (suspect same is in 2.6.21-r4).
Will recompile the kernel with DECchip Tulip (dc2114x) PCI support (tulip) or
Generic DECchip & DIGITAL EtherWORKS PCI/EISA (de4x5).
My current 2.6.20-r8 config is using dmfe too, but it works here.
Will try 'pci=routeirq" in the kernel boot line too.
Thanks. Rumen

Hi,

Forgot to mention that due to many (bad) problems with oom-killer in 2.6.22-r1
stopped running this kernel (very heavy disk IO overload). 2.6.20-r8 again.
Rumen

I doubt the oom-killer problems you're experiencing with 2.6.22-r1 are related
to this. Surely you can run 2.6.22-r1 for long enough to trigger the networking
breaking?

Please post your .config and dmesg for both 2.6.20-r8 and 2.6.22-r1.

If you decide to also try the "Early DECchip Tulip (dc2104x)" (CONFIG_DE2104X)
and the "DECchip Tulip (dc2114x)" (CONFIG_TULIP) drivers, please also post the
dmesg output from running those.

Hi,

Posting (attaching) dmesg-2.6.20-r8.txt & config-2.6.20-r8.txt
The ones for 2.6.22-r1 will follow later as running this kernel very fast locks
the computer (last time nearly broke the FS, had to run from liveCD etc.) and i
need it now :-)
Also playing again with 2.6.21-r4
Agree that oom-killer probably has nothing to do with networking problems, it
just posts one more problem to solve :-(
Thanks, Rumen

Created an attachment (id=125623) [details]
config-2.6.20-r8.txt

Created an attachment (id=125625) [details]
dmesg-2.6.20-r8.txt

Created an attachment (id=125658) [details]
dmesg-2.6.21-r4.txt

2.6.21-r4 using Tulip driver doesn't work at all.
eth0 is up but no connection.
Seems that ACPI is the culpit.

Created an attachment (id=125660) [details]
config-2.6.21-r4.txt

Hi,

Al last some good news, 2.6.21-r4 works for > 2 hours w/o problems.
Using "dmfs" for networking (as module) with initrd.
Another news setting is "pci=routeirq" on kernel load line.
Also have Generic-DAVICOM driver also as module 'de4x5'.
Will attach this kernel-config and resolve the Bug as 'WorksForMe'.
Thanks, Rumen

Created an attachment (id=125832) [details]
config-2.6.21-r4-works

Hi,

Have to reopen this Bug :-(
Last time 2.6.21-r4 worked for almost 2 hours then started losing
http-connections
Even more strange is, that two days ago, http worked OK, but 'scp' sessions
quickly stopped (as staled), after first couple of KB (4-5 tries to copy ~200
MB).
ssh worked OK, as far as i can judge.
Now with 2.6.20-r8 scp finished in a flash w/o any problems with same settings
as 2.6.21-r4
Will try 2.6.22 again plus new/different net-card.
Rumen

Hi,

New info, gentoo-sources-2.6.22-r1 works for some hours w/o problems.
Rumen

Hi,

Resolving this Bug as "WorksForMe" (not closing).
Last time 2.6.22-r1 works for 5-6 hours.
Rumen