Hi, I was redirected to here by the ubuntu-bug/Apport tool. I have had wired ethernet troubles with a USB-C docking adapter (DELL DA 200, internally Realtek GBE 8153 USB adapter) connected with the Thunderbolt jack on my Latitude 7300. Slowly, I manage to get it to work (basically by using a newer mainline Ubuntu kernel, switching off Bluetooth and suspend/resume + reconnect cables + restarting NetworkManager). I recognised "PTE Write access is not set" as one of the top messages showing up on the boot screen when booting with a recent kernel 5.4.14-050414-generic (from dmesg). [ 0.155135] APIC: Switch to symmetric I/O mode setup [ 0.155137] DMAR: Host address width 39 [ 0.155138] DMAR: DRHD base: 0x000000fed90000 flags: 0x0 [ 0.155142] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 19e2ff0505e [ 0.155143] DMAR: DRHD base: 0x000000fed91000 flags: 0x1 [ 0.155145] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c40660462 ecap f050da [ 0.155146] DMAR: RMRR base: 0x00000078563000 end: 0x00000078582fff [ 0.155147] DMAR: RMRR base: 0x0000007d000000 end: 0x0000007f7fffff [ 0.155147] DMAR: RMRR base: 0x00000078907000 end: 0x00000078986fff [ 0.155148] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 [ 0.155149] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 [ 0.155149] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. [ 0.155753] DMAR: DRHD: handling fault status reg 2 [ 0.155758] DMAR: [DMA Write] Request device [39:00.0] PASID ffffffff fault addr 7a891000 [fault reason 05] PTE Write access is not set [ 0.157591] DMAR-IR: Enabled IRQ remapping in x2apic mode [ 0.157592] x2apic enabled [ 0.157616] Switched APIC routing to cluster x2apic. [ 0.163699] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 The corresponding device is (from lspci): 39:00.0 USB controller: Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] (rev 02) Following some issue reports (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1573021, although many referring to a graphics device 00:02.0 or a PCI bridge 02:00:0), I switched off IOMMU via grub: intel_iommu=off, but as that actually would be for video acceleration (or something like that) it (of course) doesn't seem to show any effect. Still getting the same message and the same behavior: Trying to reconnect the dock adapter requires to switch off Bluetooth, suspend/resume and handling with cables and restarting NetworkManager to have the device identified, the r8152 module loaded, getting rid of the NO-CARRIER flag shown by ip link, and finally get a stable ethernet connection (notably without reboot). Even after booting, I have to repeat this procedure. It is worth saying that under 5.3.0-26 (Ubuntu 19.10 default), I got the following messages via journalctl -f: dhclient: DHCPDISCOVER on myif to 255.255.255.255 port 67 interval 17 (xid=0xfeee5e2c) dhclient: send_packet: No such device or address dhclient: dhclient.c:2569: Failed to send 300 byte long packet over myif interface. kernel: r8152 4-1.1:1.0 myif: Tx status -71 and kernel: r8152 4-1.1:1.0 xxx: Tx status -71 systemd-resolved: Failed to send hostname reply: Invalid argument kernel: r8152 4-1.1:1.0 xxx: Tx status -71 Why I am reporting this here? Because I suppose it has some to do with the unstable ethernet functionality that keeps my machine from being properly usable. I didn't find anything similar here (may that one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1697053). Also https://bugzilla.kernel.org/show_bug.cgi?id=82761 and https://bugzilla.kernel.org/show_bug.cgi?id=115931 don't seem to capture my case. More background: Overall, I am on Ubuntu 19.10, Dell Latitude 7300, i7 8th gen, all firmware (chipset, TB3, BIOS) has been updated. I have switched off Intel AMT, set Thunderbolt 3 to USB-C only mode (as the DA 200 adapter only uses USB-C). I use UEFI Secure Boot. The overall behaviour did not change much from kernel 5.3.0 packaged with Ubuntu 19.10, however, the trick described above has only been tested with 5.4.14. The ethernet adapter works seemingly totally fine with Windows 10 (which I have in a dual boot setting). I assume this is some kind of bug and hope for some help with that. Thanks.
I can confirm the same dmesg output for the default U19.10 kernel 5.3.0-26-generic. I have also tested the trick with that kernel. The same results.
Can you please attach full dmesg?
Created attachment 287121 [details] dmesg output Sure, attached the output using the DA200 as a docking adapter using Kernel 5.4.15. (I have in the meantime bought another (no-name) docking adapter internally using the same Realtek 8153 chip. Guess what, that works out of the box flawlessly until now, with HDMI/USB/RJ45 connected. As the RJ45 jack of the DA200 works only with Windows 10, the W10 driver seems to perform a more fault-tolerant handling of the Realtek/USB-C combination than the Linux driver.)