[Bug 16890] unreliable network connection after upgrade (hoary -> breezy)
bugzilla-daemon at bugzilla.ubuntu.com
bugzilla-daemon at bugzilla.ubuntu.com
Sat Oct 22 04:35:53 UTC 2005
Please do not reply to this email. You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=16890
Ubuntu | linux
ajohn2 at gmx.ch changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
------- Additional Comments From ajohn2 at gmx.ch 2005-10-22 05:35 UTC -------
I did have exactly the same problem after a fresh install of breezy on my Acer Travelmate
291LMi. By accident I did notice, that while ping www.google.com failed, ping to my router
did work. So I watched the configuration of my router and saw, that its firewall
restricted the number of nat connections to 256. Since my net usually got stuck by loading
pages with many images, but not by downloading e.g. an ubuntu iso image, I set this number
to the maximum (2048 on my router). Since then the problem is gone, so I guess the problem
was konqueror opening too many connections at once.
My question to the geeks here: Is there a possibility to restrict the number of
connections konqueror opens? (To me it seems, that this behaviour slows down the
retreaval, since pages with many images, e.g. gmx.net, pop up faster on Windows. Maybe not
only my firewall dislikes too many connections...)
(In reply to comment #0)
> after an hoary->breezy upgrade to 2.6.12-9-686), packages are dropped on a
> regular basis, sometimes, the system seems to recover (seeing only about 10-20
> ping's fail), but usually, the network doesn't come up automatically. can be
> restored by:
>
> # ifdown eth0
> Oct 3 11:58:36 localhost dhcpd: receive_packet failed on eth0: Network is down
> # ifup eth0
> Oct 3 11:58:40 localhost kernel: [4435443.952000] eth0: link up, 100Mbps,
> full-duplex, lpa 0xC5E1
>
> It then works again for some minutes. Rebooting to the hoary kernel shows up a
> stable system again.
>
> syslog entries, where the recovery succeeds:
>
> Oct 3 11:58:18 localhost kernel: [4435421.834000] NETDEV WATCHDOG: eth2:
> transmit timed out
> Oct 3 11:58:18 localhost kernel: [4435421.834000] eth2: Transmit timeout,
> status 01 0000 0000 media 18.
> Oct 3 11:58:18 localhost kernel: [4435421.834000] eth2: Tx queue start entry 13
> dirty entry 9.
> Oct 3 11:58:18 localhost kernel: [4435421.834000] eth2: Tx descriptor 0 is
> 00002000.
> Oct 3 11:58:18 localhost kernel: [4435421.834000] eth2: Tx descriptor 1 is
> 00002000. (queue head)
> Oct 3 11:58:18 localhost kernel: [4435421.834000] eth2: Tx descriptor 2 is
> 00002000.
> Oct 3 11:58:18 localhost kernel: [4435421.834000] eth2: Tx descriptor 3 is
> 00002000.
> Oct 3 11:58:18 localhost kernel: [4435421.834000] eth2: link up, 10Mbps,
> half-duplex, lpa 0x0000
>
> Oct 3 11:58:34 localhost kernel: [4435438.472000] NETDEV WATCHDOG: eth0:
> transmit timed out
> Oct 3 11:58:34 localhost kernel: [4435438.472000] eth0: Transmit timeout,
> status 01 0000 0000 media 10.
> Oct 3 11:58:34 localhost kernel: [4435438.472000] eth0: Tx queue start entry
> 115 dirty entry 111.
> Oct 3 11:58:34 localhost kernel: [4435438.472000] eth0: Tx descriptor 0 is
> 00002000.
> Oct 3 11:58:34 localhost kernel: [4435438.472000] eth0: Tx descriptor 1 is
> 00002000.
> Oct 3 11:58:34 localhost kernel: [4435438.472000] eth0: Tx descriptor 2 is
> 00002000.
> Oct 3 11:58:34 localhost kernel: [4435438.472000] eth0: Tx descriptor 3 is
> 00002000. (queue head)
> Oct 3 11:58:34 localhost kernel: [4435438.472000] eth0: link up, 100Mbps,
> full-duplex, lpa 0xC5E1
>
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : CentaurHauls
> cpu family : 6
> model : 9
> model name : VIA Nehemiah
> stepping : 8
> cpu MHz : 534.957
> cache size : 64 KB
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse
> rng rng_en ace ace_en
> bogomips : 1057.84
>
> $ lsmod|grep 8139
> 8139cp 19744 0
> 8139too 25504 0
> mii 5696 2 8139cp,8139too
>
> $ lspci|grep 8139
> 0000:00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
(In reply to comment #3)
> (In reply to comment #2)
> > doko, as we discussed on IRC, can you try removing either 8139too or 8139cp
> > since they both get loaded?
>
> disabled this, so that only 8139too is loaded. Then disabled to start the
> powernowd daemon, which makes the system stable. trying the acpi disabling now
>
--
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
More information about the kernel-bugs
mailing list