TB16 dock ethernet corrupts data with hw checksum silently failing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Dell Sputnik |
Fix Released
|
High
|
Unassigned | ||
linux (Fedora) |
Confirmed
|
Undecided
|
|||
linux (Ubuntu) |
Fix Released
|
High
|
Kai-Heng Feng | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Artful |
Fix Released
|
High
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Kai-Heng Feng |
Bug Description
It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because
rx-checksumming: on
tx-checksumming: on
and both set to on by default.
Running sudo ethtool -K <TB16 eth device> tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior.
This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux-
Thank you
In Red Hat Bugzilla #1460789, Christian (christian-redhat-bugs) wrote : | #17 |
In Red Hat Bugzilla #1460789, Christian (christian-redhat-bugs) wrote : | #18 |
There is an upstream patch for the ASM1042A host controller[1] that has been reported to help with the issue (see corresponding launchpad issue[2]).
[1] http://
[2] https:/
In Red Hat Bugzilla #1460789, Christian (christian-redhat-bugs) wrote : | #19 |
I added the v5 of the patch[1] to a kernel, scratch build:
https:/
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #20 |
v5 has landed in the maintainer's tree (to target to 4.13-rcX) along with CC to stable.
https:/
In Red Hat Bugzilla #1460789, Martin (martin-redhat-bugs) wrote : | #21 |
After an initial hiccup with the LAN cable in the dock (and plugging it into a different socket), the performance is now much better (not sure if I can say it's perfect, yet) using the patched kernel.
Thanks!
In Red Hat Bugzilla #1460789, Christian (christian-redhat-bugs) wrote : | #22 |
For future reference, the mentioned patch git merged upstream, as commit 9da5a1092b13468
It also made it into stable, 4.12.4 I believe, as 5cc9b698a494827
So I think this should be fixed (or at least better) in F26, because we currently ship 4.12.5-
In Red Hat Bugzilla #1460789, Jiri (jiri-redhat-bugs) wrote : | #23 |
(In reply to Christian Kellner from comment #5)
> For future reference, the mentioned patch git merged upstream, as commit
> 9da5a1092b13468
> It also made it into stable, 4.12.4 I believe, as
> 5cc9b698a494827
>
> So I think this should be fixed (or at least better) in F26, because we
> currently ship 4.12.5-
The network works, but sadly it corrupts packets. Martin says because of it he has difficulties to download things, connect to services...
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #24 |
@Jiri,
Are you sure that's a result of this patch? This is the first report i've heard of that.
In Red Hat Bugzilla #1460789, Christian (christian-redhat-bugs) wrote : | #25 |
@Mario, I think what Jiri means is that without the patch it doesn't work well at all but even with the patch the situation is not perfect. Let me cc Benjamin, maybe we can add a test in our Fedora Hardware test suit for that. We still have the TB16 dock in Munich right now, maybe we can be of help.
In Red Hat Bugzilla #1460789, Jiri (jiri-redhat-bugs) wrote : | #26 |
I'll let Martin speak for himself because it was him who complained about it to me.
I've been using kernel 4.12.8 which should have the patch included since the morning and haven't experienced any noticeable problems with the network.
In Red Hat Bugzilla #1460789, Martin (martin-redhat-bugs) wrote : | #27 |
Yes, for me, the Ethernet on the Docks is pretty broken. For example, when downloading a whole Koji build with about 13 packages, each time the download got broken at about 4th or 5th package, with (I think) a SSL handshake error. Also when downloading a Fedora ISO 4 times in a row, each of them got corrupted (md5 check just didn't pass).
Also, the USB performance of the dock is terrible, I'm not sure if this is related to the issue the patch in question is supposed to solve but after updating the laptop firmware to 1.2.1.0, my mouse and keyboard get disconnected very often. On the other hand, dock audio works just fine and one would assume all of these devices are on the same USB hub.
I'm currently working around this by plugging a USB-C adapter with ethernet into the Thunderbolt port on the docking station.
In Red Hat Bugzilla #1460789, Benjamin (benjamin-redhat-bugs) wrote : | #28 |
Martin, could you maybe try disabling RC checksum offloading and see if that helps? Then the corrupted packages should be discarded by the kernel (even if they are only corrupted during the transfer over USB). i.e. try again after running:
ethtool --offload $DEVICE rx off
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #29 |
@Martin
Just to make sure - this is a TB16 not TB15 right? This is sounding suspiciously like a hardware problem to me.
In Red Hat Bugzilla #1460789, Jiri (jiri-redhat-bugs) wrote : | #30 |
(In reply to Mario Limonciello from comment #12)
> @Martin
>
> Just to make sure - this is a TB16 not TB15 right? This is sounding
> suspiciously like a hardware problem to me.
It's TB16.
You mean the ethernet or USB problem? I think we've started mixing two (most likely) unrelated problems. I have not been able to reproduce the ethernet problem for the whole day. Martin also has Windows 10 installed on his XPS 13, so he could try it there and if the problem still occurs it's very likely a hardware problem.
The USB one doesn't seem like a hardware problem because I'm affected by that, too, after the last firmware update. Devices connected to the USB ports don't work at all or just for a short period of time after they're plugged in.
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #31 |
Well i'm not sure if they're related, but since the Ethernet device is a USB device on the hub, I would suspect them to be.
Can you please clarify which XPS machine you guys are affected? There are at least 4 different XPS models that support TB16.
Please comment your last working and last failed BIOS versions too.
In Red Hat Bugzilla #1460789, Jiri (jiri-redhat-bugs) wrote : | #32 |
We both have XPS 13 9360. I had problems with Ethernet from the very beginning until I used a patched kernel. But after updating the firmware to 1.3.7 USB devices stopped working*. Now we're on 2.1.0 and they still don't work, no matter if we use the kernel patch or not. I have to have a USB hub connected directly to the laptop. The last working firmware for me was 1.3.5.
* It really depends on the type of the device. The mouse and keyboard don't work at all or just for a very short time after plugging in. I also have a USB sound card. It seems to work, the system identifies the sound card as an audio output, it plays sound, but there are audible corruptions (cracks etc) which don't occur when the sound card is connected directly to the laptop. What I'm experiencing with sound may be similar to what Martin is experiencing with the Ethernet.
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #33 |
Ah OK thanks. I just poked around the Dell forums a little bit and you guys aren't the first ones reporting this on 9360 after upgrade.
http://
I'll poke some of the Dell support guys to look at this, it sounds like it might have slipped through the cracks.
I also checked internally on what went into 1.3.6/1.3.7.
At least 1.3.6 had some tweaks for adressing noise which would be most suspicious to me as a possible impact.
For now, can you two downgrade to 1.3.5? Fwupd probably won't let you, but you can place the .EXE file on a FAT32 partition and do it from F12 menu at POST I expect.
In Red Hat Bugzilla #1460789, Jiri (jiri-redhat-bugs) wrote : | #34 |
We'll try to downgrade for the time being. BTW I also reported the issue to @DellCaresPRO like Barton George instructed me on Twitter. They said 10 days ago they had people looking into it, but there hasn't been any update since then, so I have no idea if someone is really looking into it and if they've made any progress, and who is "they".
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #35 |
I won't be able to shortcut the process by pinging people, but I understand this is being investigated, it will just take some time.
In Red Hat Bugzilla #1460789, Martin (martin-redhat-bugs) wrote : | #36 |
(In reply to Benjamin Berg from comment #11)
> Martin, could you maybe try disabling RC checksum offloading and see if that
> helps? Then the corrupted packages should be discarded by the kernel (even
> if they are only corrupted during the transfer over USB). i.e. try again
> after running:
>
> ethtool --offload $DEVICE rx off
With this, it seems to work alright, thanks! Kernel 4.13.0-
(In reply to Mario Limonciello from comment #16)
> For now, can you two downgrade to 1.3.5? Fwupd probably won't let you, but
> you can place the .EXE file on a FAT32 partition and do it from F12 menu at
> POST I expect.
I'm able to function this way so I'll probably not go for that - unless it'll be necessary to verify it actually happened between the mentioned versions.
I'd rather track if there's a new release and then upgrade when it's out and see if it fixes the USB problem.
In Red Hat Bugzilla #1460789, Martin (martin-redhat-bugs) wrote : | #37 |
Every now and then (especially when downloading large files), the ethernet simply stops working with the following log in dmesg.
Unloading the r8152 module results in gnome-shell dying. After reloading it, ethernet still doesn't work. Disconnecting the Dock in this state kills everything from GDM down to my user session.
[159642.248648] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[159642.248666] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
[159642.248680] pcieport 0000:00:1c.0: device [8086:9d10] error status/
[159642.248690] pcieport 0000:00:1c.0: [12] Replay Timer Timeout
[159661.087306] xhci_hcd 0000:0a:00.0: port 1 resume PLC timeout
[159667.687492] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[159667.687514] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004694bc010 trb-start 00000003a0cfefe0 trb-end 00000003a0cfefe0 seg-start 00000003a0cfe000 seg-end 00000003a0cfeff0
[159667.687610] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[159667.687627] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004694bc020 trb-start 00000003a0cfefe0 trb-end 00000003a0cfefe0 seg-start 00000003a0cfe000 seg-end 00000003a0cfeff0
[159667.687722] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[159667.687735] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004694bc030 trb-start 00000003a0cfefe0 trb-end 00000003a0cfefe0 seg-start 00000003a0cfe000 seg-end 00000003a0cfeff0
[159667.687829] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[159667.687838] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004694bc040 trb-start 00000003a0cfefe0 trb-end 00000003a0cfefe0 seg-start 00000003a0cfe000 seg-end 00000003a0cfeff0
[159667.687971] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[159667.687988] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004694bc050 trb-start 00000003a0cfefe0 trb-end 00000003a0cfefe0 seg-start 00000003a0cfe000 seg-end 00000003a0cfeff0
[159667.723135] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[159667.723158] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004694bc060 trb-start 00000003a0cfefe0 trb-end 00000003a0cfefe0 seg-start 00000003a0cfe000 seg-end 00000003a0cfeff0
[159667.723202] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[159667.723219] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004694bc070 trb-start 00000003a0cfefe0 trb-end 00000003a0cfefe0 ...
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #38 |
As I understand the particular problem linked with the issue in BIOS 1.3.6/1.37 adjusts a voltage regulator (to fix something else; this was an unanticipated/
In Red Hat Bugzilla #1460789, Martin (martin-redhat-bugs) wrote : | #39 |
It got really annoying lately. How do I downgrade to 1.3.5, please? I can't find it on the Dell website and fwupd doesn't provide anything too.
In Red Hat Bugzilla #1460789, Martin (martin-redhat-bugs) wrote : | #40 |
Running kernel-
BIOS 2.2.1 finally hit the Dell website. I can confirm that with this, the USB overall experience is now much much better (except the occasional mouse stutter but that may as well be on the OS side). There seems to be no problem at all with the dock Ethernet adapter.
38 comments hidden Loading more comments | view all 104 comments |
Mario Limonciello (superm1) wrote : | #1 |
Does this same behavior happen in 4.14-rc7? There's a few interesting commits that have happened since 4.10 (eg https:/
Dave Chiluk (chiluk) wrote : | #2 |
I should have been more specific I'm on 4.13.0-16-generic which already contains that change. Good to see you are still around watching this project.
Dave Chiluk (chiluk) wrote : | #3 |
For completeness the ethernet device is.
Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp.
...
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x8153
bcdDevice 30.11
iManufacturer 1 Realtek
iProduct 2 USB 10/100/1000 LAN
...
summary: |
- TB16 dock ethernet is broken by default + TB16 dock ethernet corrupts data with hw checksum silently failing |
description: | updated |
Dave Chiluk (chiluk) wrote : | #4 |
Going the opposite direction it looks like 4.10.0-38-generic may be working fine. b20cb60 may actually be a regression for rtl8153.
Dave Chiluk (chiluk) wrote : | #5 |
I spoke too soon. It looks like both 4.10-0-38 and 4.13.0-16-generic have issue.
Mario Limonciello (superm1) wrote : | #6 |
Going the opposite direction you may or may not have https:/
That's supposed to be fixing the problems with Ethernet.
If you can trivially reproduce this, could you maybe bisect?
Dave Chiluk (chiluk) wrote : Re: [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing | #7 |
That one applies pretty exclusively to asmedia devices. I don't see how
that would affect a realtek device. Either way, I'll try to carve out some
time to check the mainline kernel and bisect if possible. It's pretty
straightforward to reproduce. All I've been doing is downloading the an
ubuntu iso, and checking the md5sum of it. If I have hardware offloading
on it will not pass the md5sum.
Is it possible that there is an updated firmware for the tb16 dock that I
may need? Otherwise you might want to contact the chip vendor to get them
working on this.
On Thu, Nov 2, 2017 at 5:03 PM, Mario Limonciello <email address hidden>
wrote:
> Going the opposite direction you may or may not have
> https:/
> cfb72ad016
> #diff-8e88b7e83
>
> That's supposed to be fixing the problems with Ethernet.
>
> If you can trivially reproduce this, could you maybe bisect?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> TB16 dock ethernet corrupts data with hw checksum silently failing
>
> Status in Dell Sputnik:
> New
>
> Bug description:
> It looks like TCP rx and tx checksum offloading is broken on the TB16
> dock's ethernet adapter. For example downloading a large file such as the
> Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum.
> This is because
> rx-checksumming: on
> tx-checksumming: on
> and both set to on by default.
>
> Running sudo ethtool -K <TB16 eth device> tx off rx off, allows the
> download to complete correctly. This is very bad since this can cause
> very bad untrustworthy behavior.
>
> This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux-
> generic-
>
> Thank you
>
> To manage notifications about this bug go to:
> https:/
>
Mario Limonciello (superm1) wrote : | #8 |
The asmedia host controller is what the realtek device is hooked up to.
That patch for asmedia host controller was developed specifically because
of problems with Ethernet not working at >100mbps and causing errors in the
syslog. So yeah that patch does help in that regard :(
It's possible that with the bisect you'll find that you'll come down to
that commit and the problem goes away traded for the poor performance
problem. If so that's not ideal, but I guess let's cross that bridge when
we come to it.
On Thu, Nov 2, 2017, 23:00 Dave Chiluk <email address hidden> wrote:
> That one applies pretty exclusively to asmedia devices. I don't see how
> that would affect a realtek device. Either way, I'll try to carve out some
> time to check the mainline kernel and bisect if possible. It's pretty
> straightforward to reproduce. All I've been doing is downloading the an
> ubuntu iso, and checking the md5sum of it. If I have hardware offloading
> on it will not pass the md5sum.
>
> Is it possible that there is an updated firmware for the tb16 dock that I
> may need? Otherwise you might want to contact the chip vendor to get them
> working on this.
>
> On Thu, Nov 2, 2017 at 5:03 PM, Mario Limonciello <email address hidden>
> wrote:
>
> > Going the opposite direction you may or may not have
> > https:/
> > cfb72ad016
> > #diff-8e88b7e83
> >
> > That's supposed to be fixing the problems with Ethernet.
> >
> > If you can trivially reproduce this, could you maybe bisect?
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https:/
> >
> > Title:
> > TB16 dock ethernet corrupts data with hw checksum silently failing
> >
> > Status in Dell Sputnik:
> > New
> >
> > Bug description:
> > It looks like TCP rx and tx checksum offloading is broken on the TB16
> > dock's ethernet adapter. For example downloading a large file such as the
> > Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum.
> > This is because
> > rx-checksumming: on
> > tx-checksumming: on
> > and both set to on by default.
> >
> > Running sudo ethtool -K <TB16 eth device> tx off rx off, allows the
> > download to complete correctly. This is very bad since this can cause
> > very bad untrustworthy behavior.
> >
> > This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux-
> > generic-
> >
> > Thank you
> >
> > To manage notifications about this bug go to:
> > https:/
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> TB16 dock ethernet corrupts data with hw checksum silently failing
>
> To manage notifications about this bug go to:
> https:/
>
Dave Chiluk (chiluk) wrote : | #9 |
I just upgraded to 17.10, and tested out 4.14.0-
Changed in dell-sputnik: | |
assignee: | nobody → Kai-Heng Feng (kaihengfeng) |
status: | New → Triaged |
importance: | Undecided → High |
Changed in linux (Ubuntu): | |
assignee: | nobody → Kai-Heng Feng (kaihengfeng) |
Changed in dell-sputnik: | |
assignee: | Kai-Heng Feng (kaihengfeng) → nobody |
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs. | #10 |
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 1729674
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.
Changed in linux (Ubuntu): | |
status: | New → Incomplete |
Kai-Heng Feng (kaihengfeng) wrote : | #11 |
I can reproduce the issue on a TB15 (which should be the same?).
Changed in linux (Ubuntu): | |
status: | Incomplete → In Progress |
Kai-Heng Feng (kaihengfeng) wrote : | #12 |
Tried two other r8152 devices,
- r8152 <-> USB-C <-> Host system. No checksum issue.
- r8152 <-> Genesys Logic Hub <-> USB-C <-> Host system. No checksum issue.
So it's more likely to be a ASMedia issue.
Kai-Heng Feng (kaihengfeng) wrote : | #13 |
This issue only happens under 1Gbps speed with checksum offloading.
Turn off checksum offloading or change the speed to 100Mbps can workaround the issue.
Mario Limonciello (superm1) wrote : | #14 |
@Dave:
I was glancing at r8152 driver and notice that it has some special handling for ipv6. Is this issue reproducing only in ipv6 for you?
https:/
Dave Chiluk (chiluk) wrote : Re: [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing | #15 |
I am not using ipv6.
On Tue, Nov 14, 2017 at 9:10 AM, Mario Limonciello <email address hidden>
wrote:
> @Dave:
>
> I was glancing at r8152 driver and notice that it has some special
> handling for ipv6. Is this issue reproducing only in ipv6 for you?
> https:/
> 12126e404c
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> TB16 dock ethernet corrupts data with hw checksum silently failing
>
> Status in Dell Sputnik:
> Triaged
> Status in linux package in Ubuntu:
> In Progress
>
> Bug description:
> It looks like TCP rx and tx checksum offloading is broken on the TB16
> dock's ethernet adapter. For example downloading a large file such as the
> Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum.
> This is because
> rx-checksumming: on
> tx-checksumming: on
> and both set to on by default.
>
> Running sudo ethtool -K <TB16 eth device> tx off rx off, allows the
> download to complete correctly. This is very bad since this can cause
> very bad untrustworthy behavior.
>
> This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux-
> generic-
>
> Thank you
>
> To manage notifications about this bug go to:
> https:/
>
Dave Chiluk (chiluk) wrote : | #16 |
I also just went through the process of reproducing this while watching the kern.log. Absolutely 0 messages came out. If you find some verbose debugging you want me to turn on let me know.
Changed in linux (Fedora): | |
importance: | Unknown → Undecided |
status: | Unknown → Confirmed |
Changed in linux (Ubuntu Artful): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu): | |
importance: | Undecided → High |
Changed in linux (Ubuntu Artful): | |
importance: | Undecided → High |
48 comments hidden Loading more comments | view all 104 comments |
Dave Chiluk (chiluk) wrote : | #65 |
@kmously I see that you marked this fix as Fix Committed in Artful, but I do not see it in the master-next branch of artful. I'm moving this back to In progress in artful as this does not appear to have been pushed to master-next for artful yet. Feel free to push it back to Fix Committed when you accept or merge the patch into master-next.
Changed in linux (Ubuntu Artful): | |
status: | Fix Committed → In Progress |
Dave Chiluk (chiluk) wrote : | #66 |
Looks like this has been released with 4.15.0-9.10 which is available in bionic.
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Released |
milestone: | none → ubuntu-18.04 |
Georgi Boiko (pandasauce) wrote : | #67 |
This also affects 16.04 (Xenial) but that isn't reflected in the ticket.
Luciano (luciano) wrote : | #68 |
Hi. I'm a user of another distro (gentoo), and found this bug while googling for a problem I'm having. I'm using a realtek-based USB3 to RJ45 gigabit adapter. This plugs directly into my laptop (not any sort of hub as with the DELL hubs above), which is a Toshiba Radius P20W-C-103, skylake based, with the following controller:
```
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
```
I am experiencing this on 4.9.79-r1, and also 4.14.22.
When I plug the device in, unless I disable power management on USB hubs 3 and 4, I get errors saying 'root hub lost power or was reset'. However, if I disable PM using powertop, I get the device to work seemingly well. But, as soon as I start heavy transfers (in my case distributed compile), the network device stops responding
The error messages that I'm receiving are very similar to what is posted above. This is the device coming up:
```
Feb 26 20:17:09 nizuc kernel: usb usb3: root hub lost power or was reset
Feb 26 20:17:09 nizuc kernel: usb usb4: root hub lost power or was reset
Feb 26 20:17:41 nizuc kernel: usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
Feb 26 20:17:41 nizuc kernel: usb 4-1: New USB device found, idVendor=0bda, idProduct=8153
Feb 26 20:17:41 nizuc kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
Feb 26 20:17:41 nizuc kernel: usb 4-1: Product: USB 10/100/1000 LAN
Feb 26 20:17:41 nizuc kernel: usb 4-1: Manufacturer: Realtek
Feb 26 20:17:41 nizuc kernel: usb 4-1: SerialNumber: 000001
Feb 26 20:17:41 nizuc kernel: usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd
Feb 26 20:17:41 nizuc NetworkManager[
Feb 26 20:17:41 nizuc kernel: r8152 4-1:1.0 eth0: v1.09.9
Feb 26 20:17:42 nizuc mtp-probe[3673]: checking bus 4, device 2: "/sys/devices/
Feb 26 20:17:42 nizuc mtp-probe[3673]: bus: 4, device: 2 was not an MTP device
Feb 26 20:17:42 nizuc upowerd[2168]: unhandled action 'bind' on /sys/devices/
Feb 26 20:17:42 nizuc systemd-
Feb 26 20:17:42 nizuc kernel: r8152 4-1:1.0 enp1s0u1: renamed from eth0
Feb 26 20:17:42 nizuc NetworkManager[
Feb 26 20:17:42 nizuc kernel: IPv6: ADDRCONF(
Feb 26 20:17:42 nizuc NetworkManager[
Feb 26 20:17:42 nizuc upowerd[2168]: unhandled action 'bind' on /sys/devices/
Feb 26 20:17:42 nizuc kernel: IPv6: ADDRCONF(
Feb 26 20:17:46 nizuc kernel: r8152 4-1:1.0 enp1s0u1: carrier on
Feb 26 20:17:46 nizuc kernel: IPv6: ADDRCONF(
Feb 26 20:17:46 nizuc NetworkManager[
Kai-Heng Feng (kaihengfeng) wrote : | #69 |
Weird, somehow it doesn't get pulled in for Xenail/Artful, I'll poke around to make the them in next kernel release.
@Luciano
Please file a separate bug via `ubuntu-bug linux`, thanks!
It's specific to ASMedia xHC on the Dell TB16.
Changed in linux (Ubuntu Xenial): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Artful): | |
status: | In Progress → Fix Committed |
Stefan Bader (smb) wrote : | #70 |
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.
See https:/
tags: | added: verification-needed-xenial |
tags: | added: verification-needed-artful |
Stefan Bader (smb) wrote : | #71 |
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.
See https:/
Georgi Boiko (pandasauce) wrote : | #72 |
At 6 iterations of ubuntu-
tags: |
added: verification-done-xenial removed: verification-needed-xenial |
tags: |
added: verification-done-artful removed: verification-needed-artful |
Dave Chiluk (chiluk) wrote : | #73 |
Ran same tests against 4.13.0-38 on artful.
Just curious, this only seems to be applied to hwe and hwe-edge kernels for xenial. Is that a change in policy?
Even though I haven't attempted it, it appears as if this should be pretty straightforward apply on the 4.4 kernel stream.
3 comments hidden Loading more comments | view all 104 comments |
In Red Hat Bugzilla #1460789, Jarod (jarod-redhat-bugs) wrote : | #77 |
Looks like this is more of a firmware issue with these docks and/or a driver issue with the 8152, so I'm throwing this back onto the queue where it was.
2 comments hidden Loading more comments | view all 104 comments |
Kai-Heng Feng (kaihengfeng) wrote : | #74 |
Launchpad Janitor (janitor) wrote : | #75 |
This bug was fixed in the package linux - 4.13.0-38.43
---------------
linux (4.13.0-38.43) artful; urgency=medium
* linux: 4.13.0-38.43 -proposed tracker (LP: #1755762)
* Servers going OOM after updating kernel from 4.10 to 4.13 (LP: #1748408)
- i40e: Fix memory leak related filter programming status
- i40e: Add programming descriptors to cleaned_count
* [SRU] Lenovo E41 Mic mute hotkey is not responding (LP: #1753347)
- platform/x86: ideapad-laptop: Increase timeout to wait for EC answer
* fails to dump with latest kpti fixes (LP: #1750021)
- kdump: write correct address of mem_section into vmcoreinfo
* headset mic can't be detected on two Dell machines (LP: #1748807)
- ALSA: hda/realtek - Support headset mode for ALC215/
- ALSA: hda - Fix headset mic detection problem for two Dell machines
- ALSA: hda - Fix a wrong FIXUP for alc289 on Dell machines
* CIFS SMB2/SMB3 does not work for domain based DFS (LP: #1747572)
- CIFS: make IPC a regular tcon
- CIFS: use tcon_ipc instead of use_ipc parameter of SMB2_ioctl
- CIFS: dump IPC tcon in debug proc file
* i2c-thunderx: erroneous error message "unhandled state: 0" (LP: #1754076)
- i2c: octeon: Prevent error message on bus error
* hisi_sas: Add disk LED support (LP: #1752695)
- scsi: hisi_sas: directly attached disk LED feature for v2 hw
* EDAC, sb_edac: Backport 1 patch to Ubuntu 17.10 (Fix missing DIMM sysfs
entries with KNL SNC2/SNC4 mode) (LP: #1743856)
- EDAC, sb_edac: Fix missing DIMM sysfs entries with KNL SNC2/SNC4 mode
* [regression] Colour banding and artefacts appear system-wide on an Asus
Zenbook UX303LA with Intel HD 4400 graphics (LP: #1749420)
- drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
* DVB Card with SAA7146 chipset not working (LP: #1742316)
- vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
* [Asus UX360UA] battery status in unity-panel is not changing when battery is
being charged (LP: #1661876) // AC adapter status not detected on Asus
ZenBook UX410UAK (LP: #1745032)
- ACPI / battery: Add quirk for Asus UX360UA and UX410UAK
* ASUS UX305LA - Battery state not detected correctly (LP: #1482390)
- ACPI / battery: Add quirk for Asus GL502VSK and UX305LA
* support thunderx2 vendor pmu events (LP: #1747523)
- perf pmu: Extract function to get JSON alias map
- perf pmu: Pass pmu as a parameter to get_cpuid_str()
- perf tools arm64: Add support for get_cpuid_str function.
- perf pmu: Add helper function is_pmu_core to detect PMU CORE devices
- perf vendor events arm64: Add ThunderX2 implementation defined pmu core
events
- perf pmu: Add check for valid cpuid in perf_pmu_
* lpfc.ko module doesn't work (LP: #1746970)
- scsi: lpfc: Fix loop mode target discovery
* Ubuntu 17.10 crashes on vmalloc.c (LP: #1739498)
- powerpc/
- powerpc/mm/slb: Move comment next to the code it's referring to
- powerpc/mm/hash64: Make vmalloc 56T on hash
* ethtool -p fails to light NIC LED on HiSilicon D05 systems (LP: #1748567)
- net...
Changed in linux (Ubuntu Artful): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #76 |
This bug was fixed in the package linux - 4.4.0-119.143
---------------
linux (4.4.0-119.143) xenial; urgency=medium
* linux: 4.4.0-119.143 -proposed tracker (LP: #1760327)
* Dell XPS 13 9360 bluetooth scan can not detect any device (LP: #1759821)
- Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
linux (4.4.0-118.142) xenial; urgency=medium
* linux: 4.4.0-118.142 -proposed tracker (LP: #1759607)
* Kernel panic with AWS 4.4.0-1053 / 4.4.0-1015 (Trusty) (LP: #1758869)
- x86/microcode/AMD: Do not load when running on a hypervisor
* CVE-2018-8043
- net: phy: mdio-bcm-unimac: fix potential NULL dereference in
unimac_
linux (4.4.0-117.141) xenial; urgency=medium
* linux: 4.4.0-117.141 -proposed tracker (LP: #1755208)
* Xenial update to 4.4.114 stable release (LP: #1754592)
- x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
- usbip: prevent vhci_hcd driver from leaking a socket pointer address
- usbip: Fix implicit fallthrough warning
- usbip: Fix potential format overflow in userspace tools
- x86/microcode/
- x86/retpoline: Fill RSB on context switch for affected CPUs
- sched/deadline: Use the revised wakeup rule for suspending constrained dl
tasks
- can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
- can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
- PM / sleep: declare __tracedata symbols as char[] rather than char
- time: Avoid undefined behaviour in ktime_add_safe()
- timers: Plug locking race vs. timer migration
- Prevent timer value 0 for MWAITX
- drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
- drivers: base: cacheinfo: fix boot error message when acpi is enabled
- PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
- PCI: layerscape: Fix MSG TLP drop setting
- mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
- fs/select: add vmalloc fallback for select(2)
- hwpoison, memcg: forcibly uncharge LRU pages
- cma: fix calculation of aligned offset
- mm, page_alloc: fix potential false positive in __zone_watermark_ok
- ipc: msg, make msgrcv work with LONG_MIN
- x86/ioapic: Fix incorrect pointers in ioapic_
- ACPI / processor: Avoid reserving IO regions too early
- ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
- ACPICA: Namespace: fix operand cache leak
- netfilter: x_tables: speed up jump target validation
- netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed
in 64bit kernel
- netfilter: nf_dup_ipv6: set again FLOWI_FLAG_KNOWN_NH at flowi6_flags
- netfilter: nf_ct_expect: remove the redundant slash when policy name is
empty
- netfilter: nfnetlink_queue: reject verdict request from different portid
- netfilter: restart search if moved to other chain
- netfilter: nf_conntrack_sip: extend request line validation
- netfilter: use fwmark_reflect in nf_send_reset
- ext2: Don't clear SGID when inheriting ACLs
- reiserfs: fix race in prealloc discard
- re...
Changed in linux (Ubuntu Xenial): | |
status: | Fix Committed → Fix Released |
1 comments hidden Loading more comments | view all 104 comments |
In Red Hat Bugzilla #1460789, Marianne-z (marianne-z) wrote : | #78 |
I think I have the same issue with my laptop and dock (Dell TB16).
Laptop is new and installed in Fedora 28. All firmware are up-to-date.
Ethernet works fine unless I want to transfert a large amount of data. Session (sftp, rsync or scp) cut abruptly after a few seconds. Nothing relevant appears in system logs.
If I offload the RC checksums (as suggested above) using : ethtool --offload enp11s0u1u2 rx off
Everything works fine.
Tell me if you need more logs or informations
In Red Hat Bugzilla #1460789, Mario (mario-redhat-bugs) wrote : | #79 |
FYI this commit ended up landing related to this. I would recommend to backport it.
https:/
In Red Hat Bugzilla #1460789, Jeremy (jeremy-redhat-bugs) wrote : | #80 |
Hi Mario, thanks for the pointer. Fedora stable releases are currently on 4.16.15 so that fix should be in place. I've got a TB16 at home so I can also try to reproduce this on Fedora 28 this evening.
marianne, adding the dmesg logs would be helpful. Thanks!
Kathryn Morgan (katamo) wrote : | #81 |
Confirmed the following command resolved issue disconnect in transferring 25GB+ files over TB16 ethernet device via both SCP & SFTP
`$ ethtool --offload enp14s0u1u2 rx off`
Models Tested:
- 7720
- 5520
Kernels Tested:
- 4.14.xx
Observed Symptom
Error Encountered when using scp or sftp:
- sh_dispatch_
- lost connection
Unable to test >4.14 at this time
Mario Limonciello (superm1) wrote : | #82 |
@Kat,
Can you please confirm the particular Ubuntu kernel that you are still encountering the need to run this command? As I understood this patch (that effectively does what that command does) is backported into all the latest Ubuntu kernels, so if it's still happening that is important information.
Dave Chiluk (chiluk) wrote : | #83 |
@katamo
4.14.xx is not a supported Ubuntu kernel. I'm not sure where you pulled that kernel from, but it is not supportable.
At this point all Supported Ubuntu kernels and mainline 4.15+ have this fix.
@EVERYONE ELSE
If you think you are hitting this issue and are running the latest supported kernels, you are likely hitting a different issue, and should be opening a new bug. Please stop resurrecting this bug.
6 comments hidden Loading more comments | view all 104 comments |
In Red Hat Bugzilla #1460789, ondrej.kolin (ondrej.kolin-redhat-bugs) wrote : | #90 |
Our bug report from Launchpad:
Hi.
Large amount of data gets corrupted when using the TB16 ethernet port. (rsync synchronization, etc... )
Linux E7490 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
On my Fedora is this still an issue even with announced bugfix (link copied from this discussion #78.
Linux username-
It's fixed by turning the checksum offload off (tested on the Fedora .
sudo ethtool --offload enp11s0u1u2 rx off
https:/
related in bugzilla:
In Red Hat Bugzilla #1460789, ondrej.kolin (ondrej.kolin-redhat-bugs) wrote : | #91 |
https:/
In Red Hat Bugzilla #1460789, tomastrnka (tomastrnka-redhat-bugs) wrote : | #92 |
The issue is not unique to the integrated NIC in the dock (so the current workaround in r8152 is not sufficient). I have a r8152-based TP-LINK UE300 USB3-to-GigE dongle connected to my TB16 dock and I'm getting the same packet corruption when I don't turn off rx checksum offloading.
usb 4-1.1.1: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
usb 4-1.1.1: New USB device found, idVendor=2357, idProduct=0601, bcdDevice=30.00
usb 4-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
usb 4-1.1.1: Product: USB 10/100/1000 LAN
usb 4-1.1.1: Manufacturer: TP-LINK
usb 4-1.1.1: SerialNumber: 000001000000
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 5000M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 4: Dev 6, If 0, Class=Hub, Driver=hub/2p, 5000M
|__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
The dongle is plugged into the internal USB hub in my Dell U2715H screen, which is in turn plugged into the TB16 (latest firmware 1.0.0), connected to my XPS 15 9560 (latest BIOS 1.11.0, Linux 4.18.7-
I've also seen someone mentioning that (some) USB3 ports on the TB16 are in fact Alpine Ridge pass-through. That does not seem to be the case here, all three ports on my TB16 go through the ASMedia host controller:
0e:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
The r8152 workaround triggers just fine for the integrated NIC in the dock:
usb 4-1.2: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd
usb 4-1.2: Dell TB16 Dock, disable RX aggregation
In Red Hat Bugzilla #1460789, mario_limonciello (mariolimonciello-redhat-bugs) wrote : | #93 |
@Tomas,
It sounds like the topology needs to be looked at then for applying this quirk.
Can you connect the dongle to the USB-C port with C-A adapter? That is the AR pass through port.
In Red Hat Bugzilla #1460789, tomastrnka (tomastrnka-redhat-bugs) wrote : | #94 |
Indeed, I found the mention of the pass-through only applying to the USB-C like a minute after I wrote my previous comment. Sorry for the noise.
I don't have a C-A adapter at hand, but I've tried using the Dell DA200 adapter instead (not exactly the same thing as it's an extra hub, but hopefully it helps anyway). So the topology is:
Dongle -> DA200 (hub) -> USB-C port on the TB16 -> AR host controller
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
0f:00.0 USB controller: Intel Corporation DSL6540 USB 3.1 Controller [Alpine Ridge]
This setup works fine without any corruption with all offloads on (default).
In Red Hat Bugzilla #1460789, kai.heng.feng (kai.heng.feng-redhat-bugs) wrote : | #95 |
IIRC, I tested this scenario, and I didn't observe the issue on external r8152 dongle over the ASMedia xHC host.
The v1 patch I sent was using topology to check, but maintainers didn't like it.
I'll see if I can come up a "better" version of it so maintainers will accept it.
In Red Hat Bugzilla #1460789, torel (torel-redhat-bugs) wrote : | #96 |
cc
In Red Hat Bugzilla #1460789, torel (torel-redhat-bugs) wrote : | #97 |
Ref. bug # 1600126
I updated r8152 to v2.11 per https:/
# cd /usr/src/
# patch -p1 <./linux-
# more /usr/src/
PACKAGE_
PACKAGE_
BUILT_MODULE_
DEST_MODULE_
AUTOINSTALL="yes"
# ll /var/lib/
lrwxrwxrwx. 1 root root 21 Mar 1 15:22 /var/lib/
# dracut -f
At least my kbd is still working after 30 minutes. A record on kernels above 4.18.18-300.fc29.
12 comments hidden Loading more comments | view all 104 comments |
Maxwell Ballenger (ballengerm) wrote : | #84 |
Thanks for the work you all have done tracking this down. I am experiencing an issue with identical symptoms. I understand the problem should be fixed with 4.15+, so I may be experiencing a different bug. If anyone could help me determine that conclusively or point me in a direction that might help me fix this one, I'd really appreciate it!
Below I have reproduced the issue in the same way as above, with the same workaround.
Dell Precision 5530
TB16 Dock
Ubuntu 18.04
Kernel: 4.15.0-1034-oem
$ sudo ethtool --offload enx3c2c30b2d39a rx on
$ for i in 1 2 3 4 5 6 7 8 9; do curl -s http://
4672ce371fb3c11
5cfcb270becce99
4672ce371fb3c11
ba8ec5ef56501db
7d5d892efa5899a
c0402e3a6a1179d
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
$ sudo ethtool --offload enx3c2c30b2d39a rx off
$ for i in 1 2 3 4 5 6 7 8 9; do curl -s http://
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
4672ce371fb3c11
$ uname -r
4.15.0-1034-oem
$
Dave Chiluk (chiluk) wrote : Re: [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing | #85 |
You will want to contact Dell support on that one as it appears you are
running a non- Ubuntu kernel version (it's probably Dell provided). You
might simply need to upgrade.
On Thu, Mar 28, 2019, 3:40 PM Maxwell Ballenger <email address hidden>
wrote:
> Thanks for the work you all have done tracking this down. I am
> experiencing an issue with identical symptoms. I understand the problem
> should be fixed with 4.15+, so I may be experiencing a different bug. If
> anyone could help me determine that conclusively or point me in a
> direction that might help me fix this one, I'd really appreciate it!
>
> Below I have reproduced the issue in the same way as above, with the
> same workaround.
>
> Dell Precision 5530
> TB16 Dock
> Ubuntu 18.04
> Kernel: 4.15.0-1034-oem
>
> $ sudo ethtool --offload enx3c2c30b2d39a rx on
> $ for i in 1 2 3 4 5 6 7 8 9; do curl -s
> http://
> -o $i.iso; md5sum $i.iso; done
> 4672ce371fb3c11
> 5cfcb270becce99
> 4672ce371fb3c11
> ba8ec5ef56501db
> 7d5d892efa5899a
> c0402e3a6a1179d
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> $ sudo ethtool --offload enx3c2c30b2d39a rx off
> $ for i in 1 2 3 4 5 6 7 8 9; do curl -s
> http://
> -o $i.iso; md5sum $i.iso; done
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> 4672ce371fb3c11
> $ uname -r
> 4.15.0-1034-oem
> $
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> TB16 dock ethernet corrupts data with hw checksum silently failing
>
> Status in Dell Sputnik:
> Triaged
> Status in linux package in Ubuntu:
> Fix Released
> Status in linux source package in Xenial:
> Fix Released
> Status in linux source package in Artful:
> Fix Released
> Status in linux source package in Bionic:
> Fix Released
> Status in linux package in Fedora:
> Confirmed
>
> Bug description:
> It looks like TCP rx and tx checksum offloading is broken on the TB16
> dock's ethernet adapter. For example downloading a large file such as the
> Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum.
> This is because
> rx-checksumming: on
> tx-checksumming: on
> and both set to on by default.
>
> Running sudo ethtool -K <TB16 eth device> tx off rx off, allows the
> download to complete correctly. This is very bad since this can cause
> very bad untrustworthy behavior.
>
> This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux-
> generic-
>
> Thank you
>
> To manage notificat...
Maxwell Ballenger (ballengerm) wrote : | #86 |
Thanks. It looks like I got this kernel version from the "linux-signed-oem" package: https:/
There is a new version in bionic-proposed, "linux-signed-oem 4.15.0-1035.40", which I tried and that seems to have fixed the problem.
Oddbjørn Kvalsund (oddbjornk) wrote : | #87 |
I seem to be seeing this again with the following kernel:
Linux xps15 5.0.0-17-generic #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
The problem is not so much checksum errors, but mostly that transfers are abruptly aborted. I also see this in my syslog:
Jun 21 14:41:44 xps15 kernel: [12338.169525] ------------[ cut here ]------------
Jun 21 14:41:44 xps15 kernel: [12338.169595] NETDEV WATCHDOG: enxe4b97ae3eb62 (r8152): transmit queue 0 timed out
Jun 21 14:41:44 xps15 kernel: [12338.169630] WARNING: CPU: 6 PID: 0 at net/sched/
Jun 21 14:41:44 xps15 kernel: [12338.169631] Modules linked in: rfcomm pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) ccm cmac bnep msr binfmt_misc arc4 snd_hda_codec_hdmi snd_hda_
Jun 21 14:41:44 xps15 kernel: [12338.169649] snd_seq mac80211 snd_seq_device dell_wmi snd_timer ecdh_generic dell_smbios dcdbas input_leds irqbypass ttm serio_raw dell_wmi_descriptor intel_wmi_
Jun 21 14:41:44 xps15 kernel: [12338.169688] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G W OE 5.0.0-17-generic #18-Ubuntu
Jun 21 14:41:44 xps15 kernel: [12338.169689] Hardware name: Dell Inc. XPS 15 9570/0HWTMH, BIOS 1.10.1 04/26/2019
Jun 21 14:41:44 xps15 kernel: [12338.169689] RIP: 0010:dev_
Jun 21 14:41:44 xps15 kernel: [12338.169690] Code: 00 49 63 4e e0 eb 92 4c 89 ef c6 05 9a 92 f0 00 01 e8 13 38 fc ff 89 d9 4c 89 ee 48 c7 c7 98 5e fa ae 48 89 c2 e8 71 f1 79 ff <0f> 0b eb c0 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
Jun 21 14:41:44 xps15 kernel: [12338.169691] RSP: 0018:ffff8ef45c
Jun 21 14:41:44 xps15 kern...
tags: | added: cscc |
Salvatore Cristofaro (cristofaro) wrote : | #88 |
Same here:
[34617.702285] NETDEV WATCHDOG: eth0 (r8152): transmit queue 0 timed out
[34617.702302] WARNING: CPU: 0 PID: 0 at /build/
[34617.702303] Modules linked in: md4 nls_utf8 cifs ccm fscache snd_usb_audio snd_usbmidi_lib cdc_ether usbnet r8152 mii rfcomm cmac thunderbolt bnep uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common btusb videodev btrtl btbcm cdc_acm btintel media bluetooth ecdh_generic pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) arc4 hid_multitouch hid_generic binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi intel_rapl x86_pkg_
[34617.702330] intel_cstate mac80211 dell_wmi intel_rapl_perf snd_seq_device dell_smbios snd_timer dcdbas joydev input_leds snd wmi_bmof serio_raw cfg80211 intel_wmi_
[34617.702353] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U O 5.0.0-29-generic #31~18.04.1-Ubuntu
[34617.702354] Hardware name: Dell Inc. XPS 13 9370/0W970W, BIOS 1.11.1 07/11/2019
[34617.702356] RIP: 0010:dev_
[34617.702357] Code: 00 49 63 4e e0 eb 92 4c 89 ef c6 05 7b fa ef 00 01 e8 c3 38 fc ff 89 d9 48 89 c2 4c 89 ee 48 c7 c7 90 94 1a a7 e8 3f 53 79 ff <0f> 0b eb c0 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
[34617.702358] RSP: 0018:ffff968e9e
[34617.702359] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
[34617.702360] RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff968e9e416440
[34617.702361] RBP: ffff968e9e403e88 R08: 000000000000061a R09: 0000000000000004
[34617.702361] R10: ffff968e9e403ee0 R11: 0000000000000001 R12: 0000000000000001
[34617.702362] R13: ffff968e98f24000 R14: ffff968e98f244c0 R15: ffff968e94e95080
[34617.702363] FS: 000000000000000
[34617.702364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[34617.702364] CR2: 00007fc79c004000 CR3: 000000049a13c001 CR4: 00000000003...
Dave Chiluk (chiluk) wrote : | #89 |
@oddbjornk @cristofaro
Launchpad is not a forum. Each bug is meant to solve one problem. One of you need to create a new bug for the new problem. You are welcome to reference or link this issue in that new bug though so whoever triages it has a reference.
8 comments hidden Loading more comments | view all 104 comments |
In Red Hat Bugzilla #1460789, timur.kristof (timur.kristof-redhat-bugs) wrote : | #98 |
The same issue still happens to me on kernel 5.5.6-201.
Hardware is a Dell XPS 13 9370 with a Lenovo Thunderbolt 3 dock. My dmesg is full of these messages:
[12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12713.085385] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12718.205360] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12724.349321] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12729.981295] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12735.101256] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12740.221235] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12746.365199] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12751.997171] r8152 6-1:1.0 enp10s0u1: Tx timeout
[12757.117155] r8152 6-1:1.0 enp10s0u1: Tx timeout
In Red Hat Bugzilla #1460789, d.bz-redhat (d.bz-redhat-redhat-bugs) wrote : | #99 |
This seems to help for me (Dell XPS13 2-in-1 7390 , kernel 5.6.15-
https:/
# echo 0bda:8153:k > /sys/module/
In Red Hat Bugzilla #1460789, jeremy.akers (jeremy.akers-redhat-bugs) wrote : | #100 |
Seeing a similar issue on a Dell XPS 9300 (2020) with Linux 5.4:
[ 110.467608] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.467613] xhci_hcd 0000:08:00.0: Looking for event-dma 000000086900cfd0 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.478406] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.478412] xhci_hcd 0000:08:00.0: Looking for event-dma 000000086900cfe0 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.479937] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.479942] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06000 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.482654] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.482660] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06010 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.499173] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.499178] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06020 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.505613] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.505618] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06030 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.505676] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.505678] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06040 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.505764] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.505766] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06050 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.507398] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.507405] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06060 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.509353] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.509359] xhci_hcd 0000:08:00.0: Looking for event-dma 0000000861c06070 trb-start 000000086900cfb0 trb-end 000000086900cfb0 seg-start 000000086900c000 seg-end 000000086900cff0
[ 110.510017] xhci_hcd 0000:08:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13
[ 110.510021] xhci_hcd 00...
In Red Hat Bugzilla #1460789, arcadiy (arcadiy-redhat-bugs) wrote : | #101 |
There is Dell TB19 firmware available that is installable via fwupdmgr on Linux: https:/
In Red Hat Bugzilla #1460789, arcadiy (arcadiy-redhat-bugs) wrote : | #102 |
Install via: sudo fwupdmgr install ~/Downloads/
In Red Hat Bugzilla #1460789, alex.gronholm (alex.gronholm-redhat-bugs) wrote : | #103 |
Thanks for the info (I own a WD19TB dock too) but that hardly helps with the TB16 problem. The WD19 series docks have working USB controllers, unlike TB16.
In Red Hat Bugzilla #1460789, arcadiy (arcadiy-redhat-bugs) wrote : | #104 |
(In reply to Alex Grönholm from comment #47)
> Thanks for the info (I own a WD19TB dock too) but that hardly helps with the
> TB16 problem. The WD19 series docks have working USB controllers, unlike
> TB16.
It was a long night and TB16 looked like WD19 to me :)
That said, I experience exactly the same issues with Dell Precision 5540 + WD19 as in comment42 and comment44.
Changed in dell-sputnik: | |
status: | Triaged → Fix Released |
This is a Dell XPS 13 connected to the network via the TB16 dock. 0.rc3.git0. 2.fc27. x86_64 #1 SMP Tue May 30 19:36:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Kernel is: Linux ag13.local 4.12.0-
Host controller of the dock:
09:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
USB network interface in the dock:
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 5000M
|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
[32930.573816] usb 4-1.2: new SuperSpeed USB device number 3 using xhci_hcd
[32930.591744] usb 4-1.2: New USB device found, idVendor=0bda, idProduct=8153
[32930.591752] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[32930.591757] usb 4-1.2: Product: USB 10/100/1000 LAN
[32930.591761] usb 4-1.2: Manufacturer: Realtek
[32930.591766] usb 4-1.2: SerialNumber: 000001000000
[32930.739428] usb 4-1.2: reset SuperSpeed USB device number 3 using xhci_hcd
I *sometimes* get the following in the log and with that the ethernet port stops working.
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000001c3eec010 trb-start 00000001c3eebfe0 trb-end 00000001c3eebfe0 seg-start 00000001c3eeb000 seg-end 00000001c3eebff0
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000001c3eec020 trb-start 00000001c3eebfe0 trb-end 00000001c3eebfe0 seg-start 00000001c3eeb000 seg-end 00000001c3eebff0
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000001c3eec030 trb-start 00000001c3eebfe0 trb-end 00000001c3eebfe0 seg-start 00000001c3eeb000 seg-end 00000001c3eebff0
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000001c3eec040 trb-start 00000001c3eebfe0 trb-end 00000001c3eebfe0 seg-start 00000001c3eeb000 seg-end 00000001c3eebff0
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000001c3eec050 trb-start 00000001c3eebfe0 trb-end 00000001c3eebfe0 seg-start 00000001c3eeb000 seg-end 00000001c3eebff0
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000001c3eec060 trb-start 00000001c3eebfe0 trb-end 00000001c3eebfe0 seg-start 00000001c3eeb000 seg-end 00000001c3eebff0
Jun 12 19:00:04 ag13.local kernel: xhci_hcd 0000:09...