Skip to content
This repository

USB/LAN issues with USB hub #60

Closed
blackarchon opened this Issue July 19, 2012 · 14 comments

9 participants

blackarchon ghollingworth William H. Bell Christian Kütbach huaraz Christian S. Perone popcornmix nomis05 Alex Bradbury
blackarchon

RPi usb problems

I'm using the official Raspbian image from the Foundation. This means with the following kernel:

$ uname -a
Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012 armv6l GNU/Linux

Let me start with what works:

  • Plugging my two USB wireless transceivers directly into the Pi (these two devices are from a Logitech K360 keyboard and a Logitech M570 mouse, both have the same IDs of 046d:c52b)
  • using a Logilink 7 port USB hub (2x Genesys Logic chipset, 05e3:0608, which is on the known good USB hub list on http://elinux.org/RPi_VerifiedPeripherals#Working_USB_Hubs) which is plugged on one of the Pi's USB ports. Then plugging in one of the two mentioned wireless transceivers.

What doesn't work:

  • using both of these wireless transceivers on the hub
  • using the hub and plugging one of the transceivers on the hub, the other on the Pi itself In both of these cases the network connection has quite some problems and breaks down:

Jul 19 18:52:09 raspberrypi kernel: [ 2476.241913] usb 1-1.2.2: new full speed USB device number 8 using dwc_otg
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345837] usb 1-1.2.2: New USB device found, idVendor=046d, idProduct=c52f
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345883] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345905] usb 1-1.2.2: Product: USB Receiver
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345921] usb 1-1.2.2: Manufacturer: Logitech
Jul 19 18:52:10 raspberrypi kernel: [ 2476.365082] input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/input/input2
Jul 19 18:52:10 raspberrypi kernel: [ 2476.368645] generic-usb 0003:046D:C52F.0004: input: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-bcm2708_usb-1.2.2/input0
Jul 19 18:52:10 raspberrypi kernel: [ 2476.384890] input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.1/input/input3
Jul 19 18:52:10 raspberrypi kernel: [ 2476.386935] generic-usb 0003:046D:C52F.0005: input,hiddev0: USB HID v1.11 Device [Logitech USB Receiver] on usb-bcm2708_usb-1.2.2/input1
Jul 19 18:52:20 raspberrypi kernel: [ 2486.391748] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
Jul 19 18:52:26 raspberrypi kernel: [ 2492.401868] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 18:52:31 raspberrypi kernel: [ 2497.401969] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 18:52:38 raspberrypi kernel: [ 2504.432119] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 18:52:38 raspberrypi kernel: [ 2504.432156] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
Jul 19 18:52:43 raspberrypi kernel: [ 2509.502198] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 18:52:48 raspberrypi kernel: [ 2514.662035] usb 1-1.2.2: USB disconnect, device number 8

Another tested wireless transceiver from a Logitech M185 (as shown) with 046d:c52f shows the same behaviour.
If both of these transceivers are already plugged in when the Pi boots, the LAN chip isn't working at all ("RTNETLINK answers: Unknown error 4008" when running "dhclient eth0")!

As soon as I unplug one of the two USB wireless transceivers, everything gets back to normal:

Jul 19 19:08:44 raspberrypi kernel: [ 3470.294650] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 19:08:49 raspberrypi kernel: [ 3475.294761] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:08:54 raspberrypi kernel: [ 3480.294904] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
Jul 19 19:08:59 raspberrypi kernel: [ 3485.295015] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:04 raspberrypi kernel: [ 3490.295129] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 19:09:09 raspberrypi kernel: [ 3495.295251] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:14 raspberrypi kernel: [ 3500.295384] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
Jul 19 19:09:19 raspberrypi kernel: [ 3505.295515] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:33 raspberrypi kernel: [ 3519.395813] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000008
Jul 19 19:09:33 raspberrypi kernel: [ 3519.395896] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:39 raspberrypi kernel: [ 3525.405978] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:44 raspberrypi kernel: [ 3531.146107] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:51 raspberrypi kernel: [ 3537.416253] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:10:01 raspberrypi kernel: [ 3547.309062] usb 1-1.2.3.1: USB disconnect, device number 10
Jul 19 19:10:01 raspberrypi kernel: [ 3547.315758] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Jul 19 19:10:01 raspberrypi kernel: [ 3547.350002] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

I'm using a RPi from RS Online with their 1.2 A power supply. Please let me know if you need any further information.

William H. Bell

Hi,

I see similar errors "smsc95xx 1-1.1:1.0: eth0:" when connecting to two different USB hubs. In my case, I started with two different Raspberry PI setups:

(1) Raspberry PI, HDMI to DVI cable, DVI montor, cabled logitech keyboard and mouse connected directly to the PI, micro usb phone charger 2A, 5V. This worked without error, downloading from the internet etc.. There were no errors in /var/log/messages

(2) Raspberry PI, HDMI to DVI cable (second cable), DVI montor (different monitor), cabled logitech keyboard and mouse (slightly different model) connected directly to the PI, micro usb phone charger 0.7A, 5V. This worked without error, downloading from the internet etc.. There were no errors in /var/log/messages

Using the first setup, I swapped the cabling such that the keyboard and mouse were connected via a Trust 7 port powered hub (2A, 5V, HU-5870V), where the power was still going to the PI using the same micro-USB phone charger as before. In this case the eth0 went down as smsc95xx errors started to appear. Attempts to use ifconfig caused the Pi to hang. The kernel was visibly struggling to handle the errors. Removing the hub and switching back to connecting the keyboard and mouse directly to the Pi removed the errors. The experiment was completely repeatable. While the eth0 went down, the keyboard and mouse worked through the USB-hub as expected.

Using the second setup I did a similar thing, but with a slightly different brand of hub and keyboard and model model. The same effects were seen.

As a side comment the noise of imaging via the HDMI connector can be heard clearly when a set of Trust USB powered speakers (Trust Universe 2.0 Speaker Set) is plugged into the Pi's audio out and the USB-hub which is connected to the Pi. The noise seems to come across from the USB connection between the Pi and the USB-hub. Removing the USB connection from the Pi to the USB-hub removed the noise which was being transmitted to the speakers. It looks like the Pi needs to be grounded or the USB power should be isolated from the mini-hub. I do not know if the noise is related to the smsc95xx errors.

Regards,

Will

Christian Kütbach

This looks like issue29 #29

I think there may be a connection between this two issues.

William H. Bell

Hi ckuetbach,

There are some similar posts in #29, but many other errors also. The problem I reported above looks like it might be caused by electrical problems or drivers, since the same keyboard and mouse work successfully when connected directly to the PI. In the Raspbian forum there is some more information,
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=11971

It might be the USB drivers, but I would like to rule out the electrical noise problems first.

Regards,

Will

huaraz
huaraz commented July 29, 2012

Hi,

I used the initial OS : Linux raspberrypi 3.1.9+ #90 Wed Apr 18 18:23:05 BST 2012 armv6l GNU/Linux
where the Ethernet worked fine, but when I upgraded to the lates Raspbian : Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012 armv6l GNU/Linux
my ethernet fails and finally the pi hangs. I see the following during boot with an ethernet cable connected:

[ 12.090143] smsc95xx v1.0.4
[ 12.363479] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 12.867523] ### snd_bcm2835_alsa_probe c05d07a0 ############### PROBING FOR bcm2835 ALSA device (0):(1) ###############
[ 12.883880] Creating card...
[ 12.889381] Creating device/chip ..
[ 12.896040] Adding controls ..
[ 12.901544] Registering card ....
[ 12.913401] bcm2835 ALSA CARD CREATED!
[ 12.920452] ### BCM2835 ALSA driver init OK ###
[ 17.173108] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000130
[ 17.184816] smsc95xx 1-1.1:1.0: eth0: Failed to read COE_CR: -110
[ 17.193324] smsc95xx 1-1.1:1.0: eth0: set_features() failed (-110); wanted 0x60004008, left 0x60004808
[ 17.213314] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:44:55:31
[ 17.251836] usb 1-1: USB disconnect, device number 4
[ 17.273231] usb 1-1.1: USB disconnect, device number 5
[ 17.280933] smsc95xx 1-1.1:1.0: eth0: unregister 'smsc95xx' usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet
[ 17.753334] usb 1-1: new high speed USB device number 6 using dwc_otg
[ 18.163771] usb 1-1: New USB device found, idVendor=0424, idProduct=9512
[ 18.203259] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 18.239978] hub 1-1:1.0: USB hub found
[ 18.263974] hub 1-1:1.0: 3 ports detected
[ 18.583532] usb 1-1.1: new high speed USB device number 7 using dwc_otg
[ 18.713650] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 18.743251] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 18.775979] smsc95xx v1.0.4
[ 18.864558] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:44:55:31

Markus

Christian S. Perone
perone commented July 31, 2012

Just to give some feedback, I had the same problem and everything started to work fine after I have changed my power supply, my power supply was signaling 5.34V when the problem happened.

huaraz

Yes it looks like a power supply issue. I changed from a Hama to a HNP06 USB power supply and it looks stable now.

Thank you
Markus

Christian Kütbach

What HAMA did you use? I have a HAMA powersupply, too.

huaraz

The HAMA is a 73014050 USB charger.

Input 100-120V ~ 50/60Hz 200mA
Outpt 5.0V 1000mA
Model GPE060B-050100-Z

Regards
Markus

popcornmix
Owner

Can you try with latest firmware and with:
dwc_otg.microframe_schedule=1
in cmdline.txt?

huaraz

Can you try with latest firmware and with:
dwc_otg.microframe_schedule=1
in cmdline.txt?

Wher do I get the new firmware and how do I install it ?

Markus

nomis05

I have the same problem with the smsc95xx failed to write register index error on the official Raspbian release.
I'm using a sitecom 4 Port powered Usb hub and i'm trying to connect a tp link wifi adapter with it. When it's connected from the beginning the pi will hang on boot giving the errors until i disconnect the wifi device.

I'm using OpenElec and XBian on another SD Card. With the SAME SETUP everything is working fine and I have a good wifi connection and no smsc95xx error. Even this raspbian release works:
http://www.linuxsystems.it/2012/06/raspbian-wheezy-armhf-raspberry-pi-minimal-image/

So my conclusion is that it has somethign to do with the official raspbian release!

Alex Bradbury
Owner
asb commented August 30, 2012
nomis05

Ah perfect. Thank you very much. With the untested firmware it works now :) !

ghollingworth ghollingworth closed this September 13, 2012
popcornmix popcornmix referenced this issue from a commit January 08, 2012
hwmon: (lm70) fix checkpatch issues
fixed:
ERROR: spaces required around that '=' (ctx:VxV)
#60: FILE: lm70.c:60:
+	s16 raw=0;
 	       ^

ERROR: do not use assignment in if condition
#168: FILE: lm70.c:168:
+	if ((status = device_create_file(&spi->dev, &dev_attr_temp1_input))

Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
56c24af
popcornmix popcornmix referenced this issue from a commit August 24, 2012
mmc: omap: fix broken PIO mode
After commit 26b8852 ("mmc:
omap_hsmmc: remove private DMA API implementation"), the Nokia N800
here stopped booting:

[    2.086181] Waiting for root device /dev/mmcblk0p1...
[    2.324066] Unhandled fault: imprecise external abort (0x406) at 0x00000000
[    2.331451] Internal error: : 406 [#1] ARM
[    2.335784] Modules linked in:
[    2.339050] CPU: 0    Not tainted  (3.6.0-rc3 #60)
[    2.344146] PC is at default_idle+0x28/0x30
[    2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0

...

This turned out to be due to memory corruption caused by long-broken
PIO code in drivers/mmc/host/omap.c.  (Previously, this driver had
been using DMA; but the above commit caused the MMC driver to fall
back to PIO mode with an unmodified Kconfig.)

The PIO code, added with the rest of the driver in commit
730c9b7 ("[MMC] Add OMAP MMC host
driver"), confused bytes with 16-bit words.  This bug caused memory
located after the PIO transfer buffer to be corrupted with transfers
larger than 32 bytes.  The driver also did not increment the buffer
pointer after the transfer occurred.  This bug resulted in data
corruption during any transfer larger than 64 bytes.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
75b53ae
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi September 27, 2013
x86: Improve the printout of the SMP bootup CPU table
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

Fix padding to a right-hand alignment, cleanup code and bind
reporting width to the max number of supported CPUs on the
system, like this:

 [    0.074509] smpboot: Booting Node   0, Processors:      #1  #2  #3  #4  #5  #6  #7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  #8  #9 #10 #11 #12 #13 #14 #15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: #16 #17 #18 #19 #20 #21 #22 #23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: #24 #25 #26 #27 #28 #29 #30 #31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK
 [    4.961413] Brought up 64 CPUs

and this:

 [    0.072367] smpboot: Booting Node   0, Processors:    #1 #2 #3 #4 #5 #6 #7 OK
 [    0.686329] Brought up 8 CPUs

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Libin <huawei.libin@huawei.com>
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
646e29a
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi September 30, 2013
x86/boot: Further compress CPUs bootup message
Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          #1   #2   #3   #4   #5   #6   #7
[    0.603005] .... node   #1, CPUs:     #8   #9  #10  #11  #12  #13  #14  #15
[    1.200005] .... node   #2, CPUs:    #16  #17  #18  #19  #20  #21  #22  #23
[    1.796005] .... node   #3, CPUs:    #24  #25  #26  #27  #28  #29  #30  #31
[    2.393005] .... node   #4, CPUs:    #32  #33  #34  #35  #36  #37  #38  #39
[    2.996005] .... node   #5, CPUs:    #40  #41  #42  #43  #44  #45  #46  #47
[    3.600005] .... node   #6, CPUs:    #48  #49  #50  #51  #52  #53  #54  #55
[    4.202005] .... node   #7, CPUs:    #56  #57  #58  #59  #60  #61  #62  #63
[    4.811005] .... node   #8, CPUs:    #64  #65  #66  #67  #68  #69  #70  #71
[    5.421006] .... node   #9, CPUs:    #72  #73  #74  #75  #76  #77  #78  #79
[    6.032005] .... node  #10, CPUs:    #80  #81  #82  #83  #84  #85  #86  #87
[    6.648006] .... node  #11, CPUs:    #88  #89  #90  #91  #92  #93  #94  #95
[    7.262005] .... node  #12, CPUs:    #96  #97  #98  #99 #100 #101 #102 #103
[    7.865005] .... node  #13, CPUs:   #104 #105 #106 #107 #108 #109 #110 #111
[    8.466005] .... node  #14, CPUs:   #112 #113 #114 #115 #116 #117 #118 #119
[    9.073006] .... node  #15, CPUs:   #120 #121 #122 #123 #124 #125 #126 #127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi October 15, 2013
iovisor openvswitch: fix vport-netdev unregister
The combination of two commits:
commit 8e4e171
("openvswitch: Simplify datapath locking.")
commit 2537b4d
("openvswitch:: link upper device for port devices")

introduced a bug where upper_dev wasn't unlinked upon
netdev_unregister notification

The following steps:

  modprobe openvswitch
  ovs-dpctl add-dp test
  ip tuntap add dev tap1 mode tap
  ovs-dpctl add-if test tap1
  ip tuntap del dev tap1 mode tap

are causing multiple warnings:

[   62.747557] gre: GRE over IPv4 demultiplexor driver
[   62.749579] openvswitch: Open vSwitch switching datapath
[   62.755087] device test entered promiscuous mode
[   62.765911] device tap1 entered promiscuous mode
[   62.766033] IPv6: ADDRCONF(NETDEV_UP): tap1: link is not ready
[   62.769017] ------------[ cut here ]------------
[   62.769022] WARNING: CPU: 1 PID: 3267 at net/core/dev.c:5501 rollback_registered_many+0x20f/0x240()
[   62.769023] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[   62.769051] CPU: 1 PID: 3267 Comm: ip Not tainted 3.12.0-rc3+ #60
[   62.769052] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[   62.769053]  0000000000000009 ffff8807f25cbd28 ffffffff8175e575 0000000000000006
[   62.769055]  0000000000000000 ffff8807f25cbd68 ffffffff8105314c ffff8807f25cbd58
[   62.769057]  ffff8807f2634000 ffff8807f25cbdc8 ffff8807f25cbd88 ffff8807f25cbdc8
[   62.769059] Call Trace:
[   62.769062]  [<ffffffff8175e575>] dump_stack+0x55/0x76
[   62.769065]  [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[   62.769067]  [<ffffffff8105319a>] warn_slowpath_null+0x1a/0x20
[   62.769069]  [<ffffffff8162a04f>] rollback_registered_many+0x20f/0x240
[   62.769071]  [<ffffffff8162a101>] rollback_registered+0x31/0x40
[   62.769073]  [<ffffffff8162a488>] unregister_netdevice_queue+0x58/0x90
[   62.769075]  [<ffffffff8154f900>] __tun_detach+0x140/0x340
[   62.769077]  [<ffffffff8154fb36>] tun_chr_close+0x36/0x60
[   62.769080]  [<ffffffff811bddaf>] __fput+0xff/0x260
[   62.769082]  [<ffffffff811bdf5e>] ____fput+0xe/0x10
[   62.769084]  [<ffffffff8107b515>] task_work_run+0xb5/0xe0
[   62.769087]  [<ffffffff810029b9>] do_notify_resume+0x59/0x80
[   62.769089]  [<ffffffff813a41fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   62.769091]  [<ffffffff81770f5a>] int_signal+0x12/0x17
[   62.769093] ---[ end trace 838756c62e156ffb ]---
[   62.769481] ------------[ cut here ]------------
[   62.769485] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
[   62.769486] sysfs: can not remove 'master', no directory
[   62.769486] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[   62.769514] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G        W    3.12.0-rc3+ #60
[   62.769515] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[   62.769518] Workqueue: events ovs_dp_notify_wq [openvswitch]
[   62.769519]  0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
[   62.769521]  ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b28
[   62.769523]  0000000000000000 ffffffff81a87a1f ffff8807f2634000 ffff880037038500
[   62.769525] Call Trace:
[   62.769528]  [<ffffffff8175e575>] dump_stack+0x55/0x76
[   62.769529]  [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[   62.769531]  [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
[   62.769533]  [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
[   62.769535]  [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
[   62.769538]  [<ffffffff81631ef7>] __netdev_adjacent_dev_remove+0xf7/0x150
[   62.769540]  [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
[   62.769542]  [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
[   62.769544]  [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
[   62.769548]  [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
[   62.769550]  [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
[   62.769552]  [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
[   62.769555]  [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
[   62.769557]  [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
[   62.769559]  [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
[   62.769562]  [<ffffffff8107659b>] worker_thread+0x11b/0x370
[   62.769564]  [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
[   62.769566]  [<ffffffff8107f44a>] kthread+0xea/0xf0
[   62.769568]  [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[   62.769570]  [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
[   62.769572]  [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[   62.769573] ---[ end trace 838756c62e156ffc ]---
[   62.769574] ------------[ cut here ]------------
[   62.769576] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
[   62.769577] sysfs: can not remove 'upper_test', no directory
[   62.769577] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[   62.769603] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G        W    3.12.0-rc3+ #60
[   62.769604] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[   62.769606] Workqueue: events ovs_dp_notify_wq [openvswitch]
[   62.769607]  0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
[   62.769609]  ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b58
[   62.769611]  0000000000000000 ffff880807ad3bd9 ffff8807f2634000 ffff880037038500
[   62.769613] Call Trace:
[   62.769615]  [<ffffffff8175e575>] dump_stack+0x55/0x76
[   62.769617]  [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[   62.769619]  [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
[   62.769621]  [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
[   62.769622]  [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
[   62.769624]  [<ffffffff81631f22>] __netdev_adjacent_dev_remove+0x122/0x150
[   62.769627]  [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
[   62.769629]  [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
[   62.769631]  [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
[   62.769633]  [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
[   62.769636]  [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
[   62.769638]  [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
[   62.769640]  [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
[   62.769642]  [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
[   62.769644]  [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
[   62.769646]  [<ffffffff8107659b>] worker_thread+0x11b/0x370
[   62.769648]  [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
[   62.769650]  [<ffffffff8107f44a>] kthread+0xea/0xf0
[   62.769652]  [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[   62.769654]  [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
[   62.769656]  [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[   62.769657] ---[ end trace 838756c62e156ffd ]---
[   62.769724] device tap1 left promiscuous mode

This patch also affects moving devices between net namespaces.

OVS used to ignore netns move notifications which caused problems.
Like:
  ovs-dpctl add-if test tap1
  ip link set tap1 netns 3512
and then removing tap1 inside the namespace will cause hang on missing dev_put.

With this patch OVS will detach dev upon receiving netns move event.

Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
b07c265
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.