Dell Sputnik

TB16 dock ethernet corrupts data with hw checksum silently failing

Bug #1729674 reported by Dave Chiluk
62
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Dell Sputnik
Fix Released
High
Unassigned
linux (Fedora)
Confirmed
Undecided
linux (Ubuntu)
Fix Released
High
Kai-Heng Feng
Ubuntu ubuntu-18.04
Xenial
Fix Released
Undecided
Unassigned
Artful
Fix Released
High
Unassigned
Bionic
Fix Released
High
Kai-Heng Feng
Ubuntu ubuntu-18.04

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-hwe-16.04-edge.

Thank you

See original description
Revision history for this message
In , Christian (christian-redhat-bugs) wrote :
Download full text (9.2 KiB)

This is a Dell XPS 13 connected to the network via the TB16 dock.
Kernel is: Linux ag13.local 4.12.0-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

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...

Read more...

Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

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://www.spinics.net/lists/linux-usb/msg157958.html
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1667750

Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

I added the v5 of the patch[1] to a kernel, scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=20206892

[1] http://www.spinics.net/lists/linux-usb/msg158473.html

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

v5 has landed in the maintainer's tree (to target to 4.13-rcX) along with CC to stable.
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=for-usb-linus&id=353a73c757c0b856bb95f5e73cf41b10b685258d

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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!

Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

For future reference, the mentioned patch git merged upstream, as commit 9da5a1092b13468839b1a864b126cacfb72ad016
It also made it into stable, 4.12.4 I believe, as 5cc9b698a494827b15f74ef70a31d7911d00e52a

So I think this should be fixed (or at least better) in F26, because we currently ship 4.12.5-300.fc26.x86_64

Revision history for this message
In , Jiri (jiri-redhat-bugs) wrote :

(In reply to Christian Kellner from comment #5)
> For future reference, the mentioned patch git merged upstream, as commit
> 9da5a1092b13468839b1a864b126cacfb72ad016
> It also made it into stable, 4.12.4 I believe, as
> 5cc9b698a494827b15f74ef70a31d7911d00e52a
>
> So I think this should be fixed (or at least better) in F26, because we
> currently ship 4.12.5-300.fc26.x86_64

The network works, but sadly it corrupts packets. Martin says because of it he has difficulties to download things, connect to services...

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

@Jiri,

Are you sure that's a result of this patch? This is the first report i've heard of that.

Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

@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.

Revision history for this message
In , Jiri (jiri-redhat-bugs) wrote :

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.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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.

Revision history for this message
In , Benjamin (benjamin-redhat-bugs) wrote :

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

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

@Martin

Just to make sure - this is a TB16 not TB15 right? This is sounding suspiciously like a hardware problem to me.

Revision history for this message
In , Jiri (jiri-redhat-bugs) wrote :

(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.

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

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.

Revision history for this message
In , Jiri (jiri-redhat-bugs) wrote :

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.

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

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://en.community.dell.com/support-forums/laptop/f/3518/t/20017063?pi41097=1

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.

Revision history for this message
In , Jiri (jiri-redhat-bugs) wrote :

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".

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

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.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

(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-0.rc5.git1.1.fc27.x86_64 BTW.

(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.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :
Download full text (4.1 KiB)

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/mask=00001000/00002000
[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 ...

Read more...

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

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/undiscovered regression). I would recommend for now to downgrade to 1.3.5 until a fixed BIOS is issued.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Running kernel-4.13.0-1.fc27.x86_64.

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 view all 104 comments
Revision history for this message
Mario Limonciello (superm1) wrote :

Does this same behavior happen in 4.14-rc7? There's a few interesting commits that have happened since 4.10 (eg https://github.com/torvalds/linux/commit/b20cb60e2b865638459e6ec82ad3536d3734e555#diff-d45f6c5dfa1088acc4fb00e7636dbba7)

Revision history for this message
Dave Chiluk (chiluk) wrote :

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.

Revision history for this message
Dave Chiluk (chiluk) wrote :

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
...

Dave Chiluk (chiluk)
summary: - TB16 dock ethernet is broken by default
+ TB16 dock ethernet corrupts data with hw checksum silently failing
description: updated
Revision history for this message
Dave Chiluk (chiluk) wrote :

Going the opposite direction it looks like 4.10.0-38-generic may be working fine. b20cb60 may actually be a regression for rtl8153.

Revision history for this message
Dave Chiluk (chiluk) wrote :

I spoke too soon. It looks like both 4.10-0-38 and 4.13.0-16-generic have issue.

Revision history for this message
Mario Limonciello (superm1) wrote :

Going the opposite direction you may or may not have https://github.com/torvalds/linux/commit/9da5a1092b13468839b1a864b126cacfb72ad016#diff-8e88b7e83565580efd59e852f42341a5

That's supposed to be fixing the problems with Ethernet.

If you can trivially reproduce this, could you maybe bisect?

Revision history for this message
Dave Chiluk (chiluk) wrote : Re: [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing

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://github.com/torvalds/linux/commit/9da5a1092b13468839b1a864b126ca
> cfb72ad016
> #diff-8e88b7e83565580efd59e852f42341a5
>
> 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://bugs.launchpad.net/bugs/1729674
>
> 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-hwe-16.04-edge.
>
> Thank you
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+subscriptions
>

Revision history for this message
Mario Limonciello (superm1) wrote :

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://github.com/torvalds/linux/commit/9da5a1092b13468839b1a864b126ca
> > cfb72ad016
> > #diff-8e88b7e83565580efd59e852f42341a5
> >
> > 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://bugs.launchpad.net/bugs/1729674
> >
> > 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-hwe-16.04-edge.
> >
> > Thank you
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1729674
>
> Title:
> TB16 dock ethernet corrupts data with hw checksum silently failing
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+subscriptions
>

Revision history for this message
Dave Chiluk (chiluk) wrote :

I just upgraded to 17.10, and tested out 4.14.0-041400rc8-generic. The issue still exists in 4.14.0-041400rc8-generic. It's pretty simple to reproduce @superm1, you really should get your device partners alerted about this.

Anthony Wong (anthonywong)
Changed in dell-sputnik:
assignee: nobody → Kai-Heng Feng (kaihengfeng)
status: New → Triaged
importance: Undecided → High
Kai-Heng Feng (kaihengfeng)
Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
Changed in dell-sputnik:
assignee: Kai-Heng Feng (kaihengfeng) → nobody
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

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
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

I can reproduce the issue on a TB15 (which should be the same?).

Changed in linux (Ubuntu):
status: Incomplete → In Progress
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

This issue only happens under 1Gbps speed with checksum offloading.
Turn off checksum offloading or change the speed to 100Mbps can workaround the issue.

Revision history for this message
Mario Limonciello (superm1) 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://github.com/torvalds/linux/commit/6128d1bb30748d0ff56a63898d14f312126e404c

Revision history for this message
Dave Chiluk (chiluk) wrote : Re: [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing

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://github.com/torvalds/linux/commit/6128d1bb30748d0ff56a63898d14f3
> 12126e404c
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1729674
>
> 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-hwe-16.04-edge.
>
> Thank you
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+subscriptions
>

Revision history for this message
Dave Chiluk (chiluk) wrote :

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.

Bug Watch Updater (bug-watch-updater)
Changed in linux (Fedora):
importance: Unknown → Undecided
status: Unknown → Confirmed
Khaled El Mously (kmously)
Changed in linux (Ubuntu Artful):
status: New → Fix Committed
Dave Chiluk (chiluk)
Changed in linux (Ubuntu):
importance: Undecided → High
Changed in linux (Ubuntu Artful):
importance: Undecided → High
48 comments hidden view all 104 comments
Revision history for this message
Dave Chiluk (chiluk) wrote :

@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
Revision history for this message
Dave Chiluk (chiluk) wrote :

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
Revision history for this message
Georgi Boiko (pandasauce) wrote :

This also affects 16.04 (Xenial) but that isn't reflected in the ticket.

Revision history for this message
Luciano (luciano) wrote :
Download full text (10.1 KiB)

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[2049]: <info> [1519676261.9009] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/5)
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/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1"
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/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1
Feb 26 20:17:42 nizuc systemd-udevd[3676]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb 26 20:17:42 nizuc kernel: r8152 4-1:1.0 enp1s0u1: renamed from eth0
Feb 26 20:17:42 nizuc NetworkManager[2049]: <info> [1519676262.2645] device (eth0): interface index 4 renamed iface from 'eth0' to 'enp1s0u1'
Feb 26 20:17:42 nizuc kernel: IPv6: ADDRCONF(NETDEV_UP): enp1s0u1: link is not ready
Feb 26 20:17:42 nizuc NetworkManager[2049]: <info> [1519676262.2829] device (enp1s0u1): state change: unmanaged -> unavailable (reason 'managed', internal state 'external')
Feb 26 20:17:42 nizuc upowerd[2168]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1/4-1:1.0
Feb 26 20:17:42 nizuc kernel: IPv6: ADDRCONF(NETDEV_UP): enp1s0u1: link is not ready
Feb 26 20:17:46 nizuc kernel: r8152 4-1:1.0 enp1s0u1: carrier on
Feb 26 20:17:46 nizuc kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0u1: link becomes ready
Feb 26 20:17:46 nizuc NetworkManager[2049]: <info> ...

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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.

Kleber Sacilotto de Souza (kleber-souza)
Changed in linux (Ubuntu Xenial):
status: New → Fix Committed
Kleber Sacilotto de Souza (kleber-souza)
Changed in linux (Ubuntu Artful):
status: In Progress → Fix Committed
Revision history for this message
Stefan Bader (smb) wrote :

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-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

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://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-xenial
tags: added: verification-needed-artful
Revision history for this message
Stefan Bader (smb) wrote :

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-needed-artful' to 'verification-done-artful'. If the problem still exists, change the tag 'verification-needed-artful' to 'verification-failed-artful'.

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://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Revision history for this message
Georgi Boiko (pandasauce) wrote :

At 6 iterations of ubuntu-17.04-server-amd64.img (4.2 gigs) I no longer see the corruptions on both 4.13.0-38 and 4.15.0-13 from xenial-proposed. Thanks!

tags: added: verification-done-xenial
removed: verification-needed-xenial
Dave Chiluk (chiluk)
tags: added: verification-done-artful
removed: verification-needed-artful
Revision history for this message
Dave Chiluk (chiluk) wrote :

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 view all 104 comments
Revision history for this message
In , Jarod (jarod-redhat-bugs) wrote :

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 view all 104 comments
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

I've already backported it:

http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?h=master-next&id=2cecb2e49bee95d4b9d89f732e999a6908db6abf

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (18.9 KiB)

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/ALC285/ALC289
    - 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__find_map()

  * 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/mm/book3s64: Make KERN_IO_START a variable
    - 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
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (56.9 KiB)

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_mdio_probe()

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/intel: Fix BDW late-loading revision check
    - 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_setup_resources()
    - 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 view all 104 comments
Revision history for this message
In , Marianne-z (marianne-z) wrote :

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

Revision history for this message
In , Mario (mario-redhat-bugs) wrote :

FYI this commit ended up landing related to this. I would recommend to backport it.

https://github.com/torvalds/linux/commit/0b1655143df00ac5349f27b765b2ed13a3ac40ca

Revision history for this message
In , Jeremy (jeremy-redhat-bugs) wrote :

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!

Revision history for this message
Kathryn Morgan (katamo) wrote :

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_run_fatal: Connection to 10.10.10.36 port 22: message authentication code incorrect
  - lost connection

Unable to test >4.14 at this time

Revision history for this message
Mario Limonciello (superm1) wrote :

@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.

Revision history for this message
Dave Chiluk (chiluk) wrote :

@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 view all 104 comments
Revision history for this message
In , ondrej.kolin (ondrej.kolin-redhat-bugs) wrote :

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-localdomain 4.17.9-200.fc28.x86_64 #1 SMP Mon Jul 23 21:41:29 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

It's fixed by turning the checksum offload off (tested on the Fedora .
sudo ethtool --offload enp11s0u1u2 rx off

https://bugs.launchpad.net/dell-sputnik/+bug/1729674

related in bugzilla:

Revision history for this message
In , ondrej.kolin (ondrej.kolin-redhat-bugs) wrote :

https://lkml.org/lkml/2018/8/20/42 There is a patch in upstream. Turn off the checksum offloading.

Revision history for this message
In , tomastrnka (tomastrnka-redhat-bugs) wrote :

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-200.fc28.x86_64 at the moment).

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

Revision history for this message
In , mario_limonciello (mariolimonciello-redhat-bugs) wrote :

@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.

Revision history for this message
In , tomastrnka (tomastrnka-redhat-bugs) wrote :

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).

Revision history for this message
In , kai.heng.feng (kai.heng.feng-redhat-bugs) wrote :

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.

Revision history for this message
In , torel (torel-redhat-bugs) wrote :

cc

Revision history for this message
In , torel (torel-redhat-bugs) wrote :

Ref. bug # 1600126

I updated r8152 to v2.11 per https://aur.archlinux.org/packages/r8152-dkms/ makes things more stable.

# cd /usr/src/r8152-2.11.0
# patch -p1 <./linux-4.20.0-add-guard-fix.patch

# more /usr/src/r8152-2.11.0/dkms.conf
PACKAGE_NAME="r8152"
PACKAGE_VERSION="2.11.0"
BUILT_MODULE_NAME[0]="r8152"
DEST_MODULE_LOCATION[0]="/kernel/drivers/net/usb"
AUTOINSTALL="yes"

# ll /var/lib/dkms/r8152/2.11.0/source
lrwxrwxrwx. 1 root root 21 Mar 1 15:22 /var/lib/dkms/r8152/2.11.0/source -> /usr/src/r8152-2.11.0

# 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 view all 104 comments
Revision history for this message
Maxwell Ballenger (ballengerm) 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://old-releases.ubuntu.com/releases/17.04/ubuntu-17.04-server-amd64.img -o $i.iso; md5sum $i.iso; done
4672ce371fb3c1170a9e71bc4b2810b9 1.iso
5cfcb270becce9962c0dc305dac943b9 2.iso
4672ce371fb3c1170a9e71bc4b2810b9 3.iso
ba8ec5ef56501dbab731dcd0e627a334 4.iso
7d5d892efa5899a99129d90167508434 5.iso
c0402e3a6a1179d77c3132e15af2b81f 6.iso
4672ce371fb3c1170a9e71bc4b2810b9 7.iso
4672ce371fb3c1170a9e71bc4b2810b9 8.iso
4672ce371fb3c1170a9e71bc4b2810b9 9.iso
$ sudo ethtool --offload enx3c2c30b2d39a rx off
$ for i in 1 2 3 4 5 6 7 8 9; do curl -s http://old-releases.ubuntu.com/releases/17.04/ubuntu-17.04-server-amd64.img -o $i.iso; md5sum $i.iso; done
4672ce371fb3c1170a9e71bc4b2810b9 1.iso
4672ce371fb3c1170a9e71bc4b2810b9 2.iso
4672ce371fb3c1170a9e71bc4b2810b9 3.iso
4672ce371fb3c1170a9e71bc4b2810b9 4.iso
4672ce371fb3c1170a9e71bc4b2810b9 5.iso
4672ce371fb3c1170a9e71bc4b2810b9 6.iso
4672ce371fb3c1170a9e71bc4b2810b9 7.iso
4672ce371fb3c1170a9e71bc4b2810b9 8.iso
4672ce371fb3c1170a9e71bc4b2810b9 9.iso
$ uname -r
4.15.0-1034-oem
$

Revision history for this message
Dave Chiluk (chiluk) wrote : Re: [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
Download full text (4.8 KiB)

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://old-releases.ubuntu.com/releases/17.04/ubuntu-17.04-server-amd64.img
> -o $i.iso; md5sum $i.iso; done
> 4672ce371fb3c1170a9e71bc4b2810b9 1.iso
> 5cfcb270becce9962c0dc305dac943b9 2.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 3.iso
> ba8ec5ef56501dbab731dcd0e627a334 4.iso
> 7d5d892efa5899a99129d90167508434 5.iso
> c0402e3a6a1179d77c3132e15af2b81f 6.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 7.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 8.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 9.iso
> $ sudo ethtool --offload enx3c2c30b2d39a rx off
> $ for i in 1 2 3 4 5 6 7 8 9; do curl -s
> http://old-releases.ubuntu.com/releases/17.04/ubuntu-17.04-server-amd64.img
> -o $i.iso; md5sum $i.iso; done
> 4672ce371fb3c1170a9e71bc4b2810b9 1.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 2.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 3.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 4.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 5.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 6.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 7.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 8.iso
> 4672ce371fb3c1170a9e71bc4b2810b9 9.iso
> $ uname -r
> 4.15.0-1034-oem
> $
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1729674
>
> 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-hwe-16.04-edge.
>
> Thank you
>
> To manage notificat...

Read more...

Revision history for this message
Maxwell Ballenger (ballengerm) wrote :

Thanks. It looks like I got this kernel version from the "linux-signed-oem" package: https://launchpad.net/ubuntu/bionic/+source/linux-signed-oem. I am not sure why my system is set up for that kernel package.

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.

Revision history for this message
Oddbjørn Kvalsund (oddbjornk) wrote :
Download full text (7.3 KiB)

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/sch_generic.c:461 dev_watchdog+0x221/0x230
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_codec_realtek snd_hda_codec_generic snd_usb_audio cdc_ether snd_usbmidi_lib usbnet r8152 mii intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel nls_iso8859_1 joydev snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp crct10dif_pclmul snd_soc_acpi_intel_match snd_soc_acpi crc32_pclmul snd_soc_core snd_compress ac97_bus ghash_clmulni_intel snd_pcm_dmaengine i915 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep uvcvideo videobuf2_vmalloc snd_pcm videobuf2_memops videobuf2_v4l2 videobuf2_common kvmgt aesni_intel vfio_mdev mdev btusb snd_seq_midi dell_laptop btrtl videodev vfio_iommu_type1 btbcm snd_seq_midi_event aes_x86_64 btintel crypto_simd ath10k_pci vfio cryptd glue_helper bluetooth ledtrig_audio snd_rawmidi nouveau cdc_acm media ath10k_core intel_cstate kvm ath intel_rapl_perf
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_thunderbolt drm_kms_helper wmi_bmof snd rtsx_pci_ms mxm_wmi cfg80211 soundcore drm memstick i2c_algo_bit fb_sys_fops mei_me syscopyarea processor_thermal_device sysfillrect mei hid_multitouch intel_soc_dts_iosf sysimgblt ucsi_acpi idma64 typec_ucsi virt_dma intel_pch_thermal typec int3403_thermal int340x_thermal_zone dell_smo8800 int3400_thermal intel_hid acpi_thermal_rel mac_hid acpi_pad sparse_keymap sch_fq_codel dell_smm_hwmon coretemp parport_pc ppdev lp parport ip_tables x_tables autofs4 usbhid hid_generic rtsx_pci_sdmmc nvme psmouse i2c_i801 nvme_core rtsx_pci thunderbolt ahci intel_lpss_pci libahci intel_lpss i2c_hid hid pinctrl_cannonlake wmi video pinctrl_intel
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_watchdog+0x221/0x230
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:ffff8ef45c383e68 EFLAGS: 00010286
Jun 21 14:41:44 xps15 kern...

Read more...

Brad Figg (brad-figg)
tags: added: cscc
Revision history for this message
Salvatore Cristofaro (cristofaro) wrote :
Download full text (5.0 KiB)

Same here:

[34617.702285] NETDEV WATCHDOG: eth0 (r8152): transmit queue 0 timed out
[34617.702302] WARNING: CPU: 0 PID: 0 at /build/linux-hwe-9kWQFX/linux-hwe-5.0.0/net/sched/sch_generic.c:461 dev_watchdog+0x221/0x230
[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_temp_thermal intel_powerclamp coretemp kvm_intel snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_hda_codec_realtek snd_soc_core snd_hda_codec_generic snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec crct10dif_pclmul snd_hda_core snd_hwdep crc32_pclmul dell_laptop ledtrig_audio ghash_clmulni_intel snd_pcm snd_seq_midi aesni_intel snd_seq_midi_event snd_rawmidi ath10k_pci ath10k_core aes_x86_64 crypto_simd ath snd_seq cryptd glue_helper
[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_thunderbolt dell_wmi_descriptor soundcore idma64 virt_dma ucsi_acpi intel_xhci_usb_role_switch mei_me intel_lpss_pci processor_thermal_device rtsx_pci_ms typec_ucsi memstick roles intel_pch_thermal intel_soc_dts_iosf mei intel_lpss typec intel_hid int3400_thermal int3403_thermal acpi_thermal_rel int340x_thermal_zone acpi_pad mac_hid sparse_keymap sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 i915 kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit rtsx_pci_sdmmc drm_kms_helper syscopyarea sysfillrect nvme sysimgblt fb_sys_fops psmouse drm nvme_core rtsx_pci i2c_hid wmi hid pinctrl_sunrisepoint video pinctrl_intel
[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_watchdog+0x221/0x230
[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:ffff968e9e403e58 EFLAGS: 00010286
[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: 0000000000000000(0000) GS:ffff968e9e400000(0000) knlGS:0000000000000000
[34617.702364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[34617.702364] CR2: 00007fc79c004000 CR3: 000000049a13c001 CR4: 00000000003...

Read more...

Revision history for this message
Dave Chiluk (chiluk) wrote :

@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 view all 104 comments
Revision history for this message
In , timur.kristof (timur.kristof-redhat-bugs) wrote :

The same issue still happens to me on kernel 5.5.6-201.fc31.x86_64
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

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

This seems to help for me (Dell XPS13 2-in-1 7390 , kernel 5.6.15-300.fc32.x86_64) when switching (exact chain of events undetermined) between Dell DA300 (r8152 : Tx status -71) and Dell WD19TB ThunderBolt docking adapters :

https://askubuntu.com/questions/1081128/usb-3-0-ethernet-adapter-not-working-ubuntu-18-04

# echo 0bda:8153:k > /sys/module/usbcore/parameters/quirks

Revision history for this message
In , jeremy.akers (jeremy.akers-redhat-bugs) wrote :
Download full text (6.0 KiB)

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...

Read more...

Revision history for this message
In , arcadiy (arcadiy-redhat-bugs) wrote :

There is Dell TB19 firmware available that is installable via fwupdmgr on Linux: https://www.dell.com/support/home/en-bm/drivers/driversdetails?driverid=cwcf9&oscode=rhl80&productcode=dell-wd19tb-dock

Revision history for this message
In , arcadiy (arcadiy-redhat-bugs) wrote :

Install via: sudo fwupdmgr install ~/Downloads/WD19FirmwareUpdateLinux_01.00.14.cab

Revision history for this message
In , alex.gronholm (alex.gronholm-redhat-bugs) wrote :

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.

Revision history for this message
In , arcadiy (arcadiy-redhat-bugs) wrote :

(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.

Yuan-Chen Cheng (ycheng-twn)
Changed in dell-sputnik:
status: Triaged → Fix Released
Displaying first 40 and last 40 comments. View all 104 comments or add a comment.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.