Bug 1146782 - Go To Meeting kills ethernet network connection intermittendly (r8152 4-1.2:1.0 eth2: Tx status -71)
Go To Meeting kills ethernet network connection intermittendly (r8152 4-1.2:1...
Status: RESOLVED NORESPONSE
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.1
x86-64 SUSE Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-22 08:45 UTC by Ralf Unger
Modified: 2021-12-31 13:06 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
tiwai: needinfo? (runger)


Attachments
Log file from "journal -b" command (6.12 MB, text/x-log)
2019-08-22 08:45 UTC, Ralf Unger
Details
My setup (1.78 MB, image/jpeg)
2019-09-16 08:01 UTC, Ralf Unger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Unger 2019-08-22 08:45:27 UTC
Created attachment 815166 [details]
Log file from "journal -b" command

When using the web application Go To Meeting (https://www.gotomeeting.com/de-de) and my network is connected through a docking station via USB-C adapter, after long persistent video/audio connection, the network is killed.

Output of "journal -b" is attached. The incident happened on Aug 21 at around 9:13 CEST.

Output of "lusb":
Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 004 Device 002: ID 0424:5537 Standard Microsystems Corp. 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 005: ID 413c:301a Dell Computer Corp. 
Bus 003 Device 004: ID 0bda:4014 Realtek Semiconductor Corp. 
Bus 003 Device 003: ID 047f:c056 Plantronics, Inc. 
Bus 003 Device 002: ID 0424:2137 Standard Microsystems Corp. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0c45:6713 Microdia 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Comment 1 Michal Kubeček 2019-08-26 07:58:45 UTC
This is probably the important part:

Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71

These errors go on after this. There is also a lot of NetworkManager timeout
messages but those seem to appear even befor the real problem starts so they
may not be relevant.

-71 would be -EPROTO but I don't know if it's the right way to interpret
urb->status (which is where write_bulk_callback() takes the error code from).
Comment 2 Denis Kirjanov 2019-08-29 12:05:43 UTC
I'd suggest to try the driver from the Realtek website:
https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software
Comment 3 Takashi Iwai 2019-09-05 09:42:29 UTC
Could you describe the exact hardware, the system setup and the way to reproduce?

If it's company-standard laptop, we have a test unit, so we can try to reproduce the issue locally.
Comment 4 Nicolas Patricio Saenz Julienne 2019-09-05 09:53:35 UTC
For the record, here are the faulty logs:

Aug 22 08:44:05 d41.suse.de kernel: perf: interrupt took too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:04 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:05 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
Aug 22 09:13:10 d41.suse.de kernel: net_ratelimit: 71 callbacks suppressed


Ralf, please provide more information on the HW you're using. I assume once you disconnect/reconnect the USB C dock the issue goes away right?
Comment 5 Oliver Neukum 2019-09-09 09:20:05 UTC
(In reply to Michal Kubeček from comment #1)
> This is probably the important part:

We would like to know what happens right before that.
Unfortunately the last entry before that is 9 seconds older:

Aug 21 09:59:42 d41.suse.de NetworkManager[1313]: <debug> [1566374382.3403] ndisc-lndp[0x55a1bd7c08c0,"eth2"]: processing libndp events
Aug 21 09:59:51 d41.suse.de kernel: r8152 4-1.2:1.0 eth2: Tx status -71
 
> -71 would be -EPROTO but I don't know if it's the right way to interpret
> urb->status (which is where write_bulk_callback() takes the error code from).

It is and it indicates a low level issue. That said, we shouldn't time out.
It would really be good if we could replicate this.
Comment 6 Ralf Unger 2019-09-16 08:01:22 UTC
Created attachment 818295 [details]
My setup
Comment 7 Ralf Unger 2019-09-16 08:08:36 UTC
Sorry for the delay, I was on holidays. I have attached a picture that shows my setup. Ethernet cable is plugged into docker; USB-C connection to my laptop. My hardware is:
* Laptop: DELL Precision 5510 (SUSE standard)
* Docker: DELL K17A

There isn't much of a procedure to reproduce. It's just having the above setup. Then start GoTo Meeting, and after a while notice that the network connection is killed.

I will try to see if reconnecting the USB-C connection will make the problem go away, and let you know.
Comment 8 Ralf Unger 2019-09-16 08:46:13 UTC
I can now also confirm that when I disconnect and reconnect the USB-C, the issue is gone.
Comment 9 Denis Kirjanov 2019-09-16 10:05:25 UTC
Hi Ralf, 

could you please check the difference in the kernel log between these two actions?

Thanks!
Comment 10 Denis Kirjanov 2019-09-16 10:06:39 UTC
And does it happen with the driver from Realtek website?
Comment 11 Ralf Unger 2019-09-17 12:56:00 UTC
@Denis, I need to ask what potential problems or risks could occur, if I update the driver. We are talking here about my work laptop (productive system). Thanks.
Comment 12 Denis Kirjanov 2019-09-17 18:06:15 UTC
Ralf,

I can say that I havent had any problems with that. 
you always have an opportunity to blacklist a driver during kernel boot
Comment 13 Oliver Neukum 2019-09-25 09:09:41 UTC
Nicolas is working on a similar issue.
Please try running your system with usbcore.autosuspend=-1 on the kernel command line.
Comment 14 Miroslav Beneš 2020-03-20 09:39:54 UTC
Ralf, have you tried what Oliver proposed in comment 13?

Nicolas, anything new with the similar issue? Maybe we should add a reference here if there is a bug for that one.
Comment 15 Miroslav Beneš 2020-08-28 13:10:35 UTC
No response, closing.
Comment 16 Miroslav Beneš 2021-12-31 13:06:12 UTC
Closing.