Skip to contentSkip to conversation

New: Something has been broken in the network stack this week

Bugme-new Andrew Morton 2 participants 2 messages Dec 16, 2009 – Dec 17, 2009 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author
#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Said to be a post-2.6.32 regression.

Quoted 73 lines · On Sat, 12 Dec 2009 13:06:04 GMT [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=14791

Summary: Something has been broken in the network stack this
week
Product: Networking
Version: 2.5
Kernel Version: after 2.6.32
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: Yes

Created an attachment (id=24161)
--> (http://bugzilla.kernel.org/attachment.cgi?id=24161)
dmesg and lspci outputs

Apparently something has been broken in the network stack this week

Hi. This is my first bug/issue report, so understand any mistake or n00b thing I make here. And sorry for the bad english ;)

It looks like that from the 2.6.32 release, to the git commit 2.6.32-05254-g3067e02 (i've compiled it in Dec 10 11:39:26 (Brazilian TZ) 2009), something weird happened ;)

I've used the USB_NET_CDCETHER for 2 years now, and it always worked. But when I rebooted to my new kernel 2.6.32-05254-g3067e02, from the 2.6.32, it just dont get connected.

[   16.683465] ADDRCONF(NETDEV_UP): eth1: link is not ready
[   94.854539] ADDRCONF(NETDEV_UP): eth1: link is not ready

There's no symptom of anything wrong. And even restarting the modem and then reconnecting the USB cable, it does'nt work.

Then I reboot to the 2.6.32 one, and it takes just one dhclient command and 1 second to be online again.

---- output of: sh scripts/ver_linux

Linux speedyb0y 2.6.32speedyb0y-05254-g3067e02 #3 PREEMPT Thu Dec 10 11:39:26 BRST 2009 i686 GNU/Linux

Gnu C                  4.4.2
Gnu make               3.81
binutils               2.20
util-linux             2.16.2
mount                  support
module-init-tools      3.11
e2fsprogs              1.41.9
reiserfsprogs          3.6.21
PPP                    2.4.4
Linux C Library        2.10.2
Dynamic linker (ldd)   2.10.2
Procps                 3.2.8
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               8.1
Modules Loaded         nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs

binfmt_misc cdc_ether usbnet

---- output of: cat /proc/version

Linux version 2.6.32speedyb0y-05254-g3067e02 (speedyb0y@speedyb0y) (gcc version 4.4.2 (Debian 4.4.2-3) ) #3 PREEMPT Thu Dec 10 11:39:26 BRST 2009

#2 lore raw

[email protected] wrote (via Bugzilla):

Quoted 13 lines
Quoted 13 lines

Apparently something has been broken in the network stack this week

Hi. This is my first bug/issue report, so understand any mistake or n00b thing I make here. And sorry for the bad english ;)

It looks like that from the 2.6.32 release, to the git commit 2.6.32-05254-g3067e02 (i've compiled it in Dec 10 11:39:26 (Brazilian TZ) 2009), something weird happened ;)

I've used the USB_NET_CDCETHER for 2 years now, and it always worked. But when I rebooted to my new kernel 2.6.32-05254-g3067e02, from the 2.6.32, it just dont get connected.

Quoted 8 lines
Quoted 8 lines
[   16.683465] ADDRCONF(NETDEV_UP): eth1: link is not ready
[   94.854539] ADDRCONF(NETDEV_UP): eth1: link is not ready

There's no symptom of anything wrong. And even restarting the modem and then reconnecting the USB cable, it does'nt work.

Then I reboot to the 2.6.32 one, and it takes just one dhclient command and 1 second to be online again.

This may well be due to this change, which sets the initial assumed link state to be down, not up:

commit 37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71

Author: Ben Hutchings <[email protected]>
Date:   Wed Nov 4 15:29:52 2009 +0000

usbnet: Set link down initially for drivers that update link state

Some usbnet drivers update link state while others do not due to hardware limitations. Add a flag to distinguish those that do, and set the link down initially for their devices.

This is intended to fix this bug: http://bugs.debian.org/444043

Signed-off-by Ben Hutchings <[email protected]>
Signed-off-by David S. Miller <[email protected]>

Perhaps cdc_ether should poll the hardware to get the initial link state?

Ben.

Signature · 3 lines
Ben Hutchings
Hoare's Law of Large Problems:
        Inside every large problem is a small problem struggling to get out.