USB issue on a TB4 controller?

USB issue on a TB4 controller?

[Christian Schaubschläger]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

Hi Mika,

attached you find two dmesg logs (with tunderbolt.dyndbg=+p), one from power off state were everything is ok (dmesg_ok.txt.xz).
The second one (dmesg_nok.txt.xz) is after a reboot when the network interface is in faulty state.

Hardware is:
Dell Inc. Latitude 7440/0XDRJY, BIOS 1.3.1 04/25/2023
CPU0: 13th Gen Intel(R) Core(TM) i5-1345U (family: 0x6, model: 0xba, stepping: 0x3)
thunderbolt 0-1: Dell WD19TB Thunderbolt Dock

Best regards,
Christian

Am 23.05.23 um 10:55 schrieb Mika Westerberg:
> Hi,
>
> On Tue, May 23, 2023 at 10:22:28AM +0200, Christian Schaubschläger wrote:
>> Hi Mika,
>>
>> it seems that I have an issue here which seems similar to the one on the HP earlier this year.
>>
>> This time the hardware is a Dell Latitude 7440 with a rather new Intel i5-1345U (13th Gen.) and TB4. I have three Docks, one older Dell WD19TB, a newer Dell WD22TB4, and a ThinkPad Universal USB-C Dock.
>> With the TB4 dock everything works fine (meaning all hardware is functioning in the UEFI firmware as well as in Windows after booting Linux first).
>>
>> With the older TB dock, as well as with the USB-C dock the network interface on the dock is dead after Linux. But in contrast to the HP case from earlier this year, this time the network interface remains dead when I boot Linux again. After replugging the dock it becomes alive again.
>>
>> This can easilsy be reproduced by booting Ubuntu 22.04 from an USB device. Using a newer kernel with the UNSET_INBOUND_SBTX fix does not solve the issue.
>>
>> I'm not sure if this is a USB or Thunderbolt issue, could be an issue with the network device, too (all three docks have the same Realtek 8153). But I don't see this problem with these docks on other Laptops I have access to, so probably it's not the network device...
>>
>> Can I provide some logs, etc. to dive deeper into this?
> Sure, I suggest also start a new email thread or file a kernel.org
> bugzilla ticket.
>
> Can you add "thunderbolt.dyndbg=+p" in the kernel command line and
> reproduce the issue and share the full dmesg?

[-- Attachment #2: dmesg_nok.txt.xz --]
[-- Type: application/x-xz, Size: 16920 bytes --]

[-- Attachment #3: dmesg_ok.txt.xz --]
[-- Type: application/x-xz, Size: 17016 bytes --]

Re: USB issue on a TB4 controller?

[Mika Westerberg]

Hi,

On Tue, May 23, 2023 at 01:15:30PM +0200, Christian Schaubschläger wrote:
> Hi Mika,
> 
> attached you find two dmesg logs (with tunderbolt.dyndbg=+p), one from power off state were everything is ok (dmesg_ok.txt.xz).
> The second one (dmesg_nok.txt.xz) is after a reboot when the network interface is in faulty state.
> 
> Hardware is:
> Dell Inc. Latitude 7440/0XDRJY, BIOS 1.3.1 04/25/2023
> CPU0: 13th Gen Intel(R) Core(TM) i5-1345U (family: 0x6, model: 0xba, stepping: 0x3)
> thunderbolt 0-1: Dell WD19TB Thunderbolt Dock

Sorry for the delay. I've been busy with some other issues.

I guess we are talking about this xHCI:

[   15.449690] xhci_hcd 0000:04:00.0: xHCI Host Controller
[   15.450477] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 3
[   15.452337] xhci_hcd 0000:04:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x00
00000200009810
[   15.453734] xhci_hcd 0000:04:00.0: xHCI Host Controller
[   15.454437] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 4
[   15.455092] xhci_hcd 0000:04:00.0: Host supports USB 3.1 Enhanced SuperSpeed

In both cases the the SuperSpeed HUB is found:

[    5.589178] usb 4-2.3: new SuperSpeed USB device number 3 using xhci_hcd
[    5.622113] input: HDA Intel PCH Headphone Mic as /devices/pci0000:00/0000:00:1f.3/soun
d/card0/input27
[    5.635536] hub 4-2.3:1.0: USB hub found
[    5.637176] hub 4-2.3:1.0: 4 ports detected

However, the connected NIC is only found in dmesg_ok.txt.xz:

[    5.904363] usb 4-2.4: new SuperSpeed USB device number 4 using xhci_hcd
...
[    6.192613] r8152-cfgselector 4-2.4: reset SuperSpeed USB device number 4 using xhci_hcd
[    6.217838] r8152 4-2.4:1.0 (unnamed net_device) (uninitialized): Using pass-thru MAC addr ac:91:a1:95:63:bf
[    6.258478] r8152 4-2.4:1.0: load rtl8153b-2 v1 10/23/19 successfully
[    6.318568] r8152 4-2.4:1.0 eth0: v1.12.13

To me it looks like the PCIe tunnel to the xHCI (0000:04:00.0) on the
dock works fine, otherwise it would not show up at all. I'm not an xHCI
expert so adding Mathias in case he has ideas how to debug this further.

I think it makes sense to enable xHCI debugging and traces and provide
them to Mathias. The following commands should do so:

 # echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
 # echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
 # echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
 # echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

Trace buffer is /sys/kernel/debug/tracing/trace.

Re: USB issue on a TB4 controller?

[Mathias Nyman]

On 26.5.2023 15.36, Mika Westerberg wrote:
> Hi,
> 
> On Tue, May 23, 2023 at 01:15:30PM +0200, Christian Schaubschläger wrote:
>> Hi Mika,
>>
>> attached you find two dmesg logs (with tunderbolt.dyndbg=+p), one from power off state were everything is ok (dmesg_ok.txt.xz).
>> The second one (dmesg_nok.txt.xz) is after a reboot when the network interface is in faulty state.
>>
>> Hardware is:
>> Dell Inc. Latitude 7440/0XDRJY, BIOS 1.3.1 04/25/2023
>> CPU0: 13th Gen Intel(R) Core(TM) i5-1345U (family: 0x6, model: 0xba, stepping: 0x3)
>> thunderbolt 0-1: Dell WD19TB Thunderbolt Dock
> 
> Sorry for the delay. I've been busy with some other issues.
> 
> I guess we are talking about this xHCI:
> 
> [   15.449690] xhci_hcd 0000:04:00.0: xHCI Host Controller
> [   15.450477] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 3
> [   15.452337] xhci_hcd 0000:04:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x00
> 00000200009810
> [   15.453734] xhci_hcd 0000:04:00.0: xHCI Host Controller
> [   15.454437] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 4
> [   15.455092] xhci_hcd 0000:04:00.0: Host supports USB 3.1 Enhanced SuperSpeed
> 
> In both cases the the SuperSpeed HUB is found:
> 
> [    5.589178] usb 4-2.3: new SuperSpeed USB device number 3 using xhci_hcd
> [    5.622113] input: HDA Intel PCH Headphone Mic as /devices/pci0000:00/0000:00:1f.3/soun
> d/card0/input27
> [    5.635536] hub 4-2.3:1.0: USB hub found
> [    5.637176] hub 4-2.3:1.0: 4 ports detected
> 
> However, the connected NIC is only found in dmesg_ok.txt.xz:
> 
> [    5.904363] usb 4-2.4: new SuperSpeed USB device number 4 using xhci_hcd
> ...
> [    6.192613] r8152-cfgselector 4-2.4: reset SuperSpeed USB device number 4 using xhci_hcd
> [    6.217838] r8152 4-2.4:1.0 (unnamed net_device) (uninitialized): Using pass-thru MAC addr ac:91:a1:95:63:bf
> [    6.258478] r8152 4-2.4:1.0: load rtl8153b-2 v1 10/23/19 successfully
> [    6.318568] r8152 4-2.4:1.0 eth0: v1.12.13
> 
> To me it looks like the PCIe tunnel to the xHCI (0000:04:00.0) on the
> dock works fine, otherwise it would not show up at all. I'm not an xHCI
> expert so adding Mathias in case he has ideas how to debug this further.
> 
> I think it makes sense to enable xHCI debugging and traces and provide
> them to Mathias. The following commands should do so:
> 
>   # echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
>   # echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
>   # echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
>   # echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
> 
> Trace buffer is /sys/kernel/debug/tracing/trace.

Also worth testing if rebinding/resetting the 4 port USB 3.1 hub built into the dock with
the NIC connected to it helps.

# echo "4-2:1.0" > /sys/bus/usb/drivers/hub/unbind
# echo "4-2:1.0" > /sys/bus/usb/drivers/hub/bind

Thanks
-Mathias

Re: USB issue on a TB4 controller?

[Christian Schaubschläger]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Hi,

>>   # echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
>>   # echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
>>
>> Trace buffer is /sys/kernel/debug/tracing/trace.

Can I enable this on the command line? Because I guess I need traces from startup when the dock is connected already.

>> Also worth testing if rebinding/resetting the 4 port USB 3.1 hub built into the dock with
>> the NIC connected to it helps.
>>
>> # echo "4-2:1.0" > /sys/bus/usb/drivers/hub/unbind
>> # echo "4-2:1.0" > /sys/bus/usb/drivers/hub/bind

This does not help, unfortunately.

I've attached dmesg logs with xhci-hcd and usbcore debug output, one log from a faulty run, and one from an ok run.
I can provide traces once I know how to enable xhci tracing on the kernel command line.

Thanks and best regards,
Christian


[-- Attachment #2: dmesg_xhci_nok.txt.xz --]
[-- Type: application/x-xz, Size: 37864 bytes --]

[-- Attachment #3: dmesg_xhci_ok.txt.xz --]
[-- Type: application/x-xz, Size: 39400 bytes --]

Re: USB issue on a TB4 controller?

[Mika Westerberg]

On Tue, May 30, 2023 at 12:13:19PM +0200, Christian Schaubschläger wrote:
> Hi,
> 
> >>   # echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
> >>   # echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
> >>
> >> Trace buffer is /sys/kernel/debug/tracing/trace.
> 
> Can I enable this on the command line? Because I guess I need traces from startup when the dock is connected already.

I think you can add "trace_event=xhci-hcd" in the kernel command line to
get it enabled boot time. See:

https://docs.kernel.org/trace/events.html#boot-option

Re: USB issue on a TB4 controller?

[Christian Schaubschläger]

>> Can I enable this on the command line? Because I guess I need traces from startup when the dock is connected already.
> I think you can add "trace_event=xhci-hcd" in the kernel command line to
> get it enabled boot time. See:
>
> https://docs.kernel.org/trace/events.html#boot-option

Hm,

[    0.029711] Kernel command line: bzImage.efi thunderbolt.dyndbg=+p trace_event=xhci-hcd root=PARTUUID=1761F245-C668-41F5-90E4-5BBF2224097A rootwait  nomodeset ima_appraise=off
[    0.063715] Failed to enable trace event: xhci-hcd

have to figure that out first...

Regards,
Christian

Re: USB issue on a TB4 controller?

[Mika Westerberg]

On Tue, May 30, 2023 at 02:11:21PM +0200, Christian Schaubschläger wrote:
> 
> >> Can I enable this on the command line? Because I guess I need traces from startup when the dock is connected already.
> > I think you can add "trace_event=xhci-hcd" in the kernel command line to
> > get it enabled boot time. See:
> >
> > https://docs.kernel.org/trace/events.html#boot-option
> 
> Hm,
> 
> [    0.029711] Kernel command line: bzImage.efi thunderbolt.dyndbg=+p trace_event=xhci-hcd root=PARTUUID=1761F245-C668-41F5-90E4-5BBF2224097A rootwait  nomodeset ima_appraise=off
> [    0.063715] Failed to enable trace event: xhci-hcd

Could be that it expects the driver to be built-in in that case.

Re: USB issue on a TB4 controller?

[Mathias Nyman]

[-- Attachment #1: Type: text/plain, Size: 4375 bytes --]

On 30.5.2023 15.40, Christian Schaubschläger wrote:
> Sorry, wrong email format :-/
> 
> Christian
> 
> 
> Am 30.05.23 um 14:38 schrieb Christian Schaubschläger:
>> Hi,
>>
>>>> [    0.029711] Kernel command line: bzImage.efi thunderbolt.dyndbg=+p trace_event=xhci-hcd root=PARTUUID=1761F245-C668-41F5-90E4-5BBF2224097A rootwait  nomodeset ima_appraise=off
>>>> [    0.063715] Failed to enable trace event: xhci-hcd
>>> Could be that it expects the driver to be built-in in that case.
>>
>> Ah, that helps a lot, thanks! ;-)
>>
>> Traces attached: one after a boot in OK state, one after a reboot in failed state, and one after reconnecting the dock's USB cable when it was in failed state before. After reconnecting the cable it works again.
>>
>> Thanks and best regards,
>> Christian
>>

Thanks

Looks like the hub (4-2) in the dock doesn't detect any activity on port4
where the NIC is.

Ok case:

[    2.627736] hub 4-2:1.0: 4 ports detected
[    2.628729] hub 4-2:1.0: power on to power good time: 0ms
[    2.630171] hub 4-2:1.0: enabling power on all ports
...
[    2.737142] usb 4-2-port3: status 0203 change 0010
[    2.737639] usb 4-2-port4: status 0203 change 0010
..
[    2.840430] hub 4-2:1.0: state 7 ports 4 chg 0018 evt 0000

Not ok:

[    2.622108] hub 4-2:1.0: 4 ports detected
[    2.622759] hub 4-2:1.0: power on to power good time: 0ms
[    2.623554] hub 4-2:1.0: enabling power on all ports
..
[    2.729001] usb 4-2-port3: status 0203 change 0010
...
[    2.832393] hub 4-2:1.0: state 7 ports 4 chg 0008 evt 0000


Maybe something goes wrong during link training between hub 4-2 and
the NIC at 4-2.4.

If the link immediately goes to a error state without causing a
connect change event for its port, then I guess  it's possible that hub
driver won't react to this port at all.
  
Attached is a patch that adds more debugging, adds a minimum
"power on to power good" delay, (as hub reports 0ms), and checks port link
states during hub initialization.

Does it help? Could you take logs with that patch applied.

Only dmesg with xhci and usbcore dynamic debug are needed.
xhci traces won't help as issue seems to be between the hub inthe dock and the NIC


diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 97a0f8faea6e..9cb238938afa 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1134,9 +1134,9 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
                 if (status)
                         goto abort;
  
-               if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
-                       dev_dbg(&port_dev->dev, "status %04x change %04x\n",
-                                       portstatus, portchange);
+/*             if (udev || (portstatus & USB_PORT_STAT_CONNECTION)) */
+               dev_dbg(&port_dev->dev, "status %04x change %04x\n",
+                       portstatus, portchange);
  
                 /*
                  * After anything other than HUB_RESUME (i.e., initialization
@@ -1162,10 +1162,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
                 }
  
                 /* Make sure a warm-reset request is handled by port_event */
-               if (type == HUB_RESUME &&
-                   hub_port_warm_reset_required(hub, port1, portstatus))
+               if ((type == HUB_RESUME || type == HUB_INIT2) &&
+                   hub_port_warm_reset_required(hub, port1, portstatus)) {
+                       dev_dbg(&port_dev->dev, "HUBDBG needs warm reset\n");
                         set_bit(port1, hub->event_bits);
-
+               }
                 /*
                  * Add debounce if USB3 link is in polling/link training state.
                  * Link will automatically transition to Enabled state after
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index e23833562e4f..ad510dfe49e8 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -157,7 +157,7 @@ static inline unsigned hub_power_on_good_delay(struct usb_hub *hub)
         unsigned delay = hub->descriptor->bPwrOn2PwrGood * 2;
  
         if (!hub->hdev->parent) /* root hub */
-               return delay;
+               return max(delay, 100U);
         else /* Wait at least 100 msec for power to become stable */
                 return max(delay, 100U);
  }


Thanks
Mathias

[-- Attachment #2: 0001-usb-hub-add-debugging-and-DS-port-link-state-checks-.patch --]
[-- Type: text/x-patch, Size: 2763 bytes --]

From 4f7cba98718ff1a6078f05c85a30c1036183f811 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman@linux.intel.com>
Date: Wed, 31 May 2023 12:24:27 +0300
Subject: [PATCH] usb: hub: add debugging and DS port link state checks during
 initialization

Force a 100ms minimum power on to power good delay for hubs to
let link trainig settle.
Show portstatus and change values for all ports during hub initialization
when debugging, not just for ports with a connect change.

Check link state for USB 3.x ports durinig hub initialization in case
any ports is stuck in SS.Inactive or compliance, and needs a warm reset
to recover. Setting the event bit for those port should be enough as port
event handler will warm reset ports in SS.Inactive or compliance state.

NOT FOR UPSTEAM, debug purpose only.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
 drivers/usb/core/hub.c | 13 +++++++------
 drivers/usb/core/hub.h |  2 +-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 97a0f8faea6e..9cb238938afa 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1134,9 +1134,9 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
 		if (status)
 			goto abort;
 
-		if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
-			dev_dbg(&port_dev->dev, "status %04x change %04x\n",
-					portstatus, portchange);
+/*		if (udev || (portstatus & USB_PORT_STAT_CONNECTION)) */
+		dev_dbg(&port_dev->dev, "status %04x change %04x\n",
+			portstatus, portchange);
 
 		/*
 		 * After anything other than HUB_RESUME (i.e., initialization
@@ -1162,10 +1162,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
 		}
 
 		/* Make sure a warm-reset request is handled by port_event */
-		if (type == HUB_RESUME &&
-		    hub_port_warm_reset_required(hub, port1, portstatus))
+		if ((type == HUB_RESUME || type == HUB_INIT2) &&
+		    hub_port_warm_reset_required(hub, port1, portstatus)) {
+			dev_dbg(&port_dev->dev, "HUBDBG needs warm reset\n");
 			set_bit(port1, hub->event_bits);
-
+		}
 		/*
 		 * Add debounce if USB3 link is in polling/link training state.
 		 * Link will automatically transition to Enabled state after
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index e23833562e4f..ad510dfe49e8 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -157,7 +157,7 @@ static inline unsigned hub_power_on_good_delay(struct usb_hub *hub)
 	unsigned delay = hub->descriptor->bPwrOn2PwrGood * 2;
 
 	if (!hub->hdev->parent)	/* root hub */
-		return delay;
+		return max(delay, 100U);
 	else /* Wait at least 100 msec for power to become stable */
 		return max(delay, 100U);
 }
-- 
2.25.1

Re: USB issue on a TB4 controller?

[Christian Schaubschläger]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Hi,

> Attached is a patch that adds more debugging, adds a minimum
> "power on to power good" delay, (as hub reports 0ms), and checks port link
> states during hub initialization.
>
> Does it help? Could you take logs with that patch applied.
>
> Only dmesg with xhci and usbcore dynamic debug are needed.
> xhci traces won't help as issue seems to be between the hub inthe dock and the NIC

patch applied, see logs in the attachment. The behaviour is unchanged.

Thanks,
Christian

[-- Attachment #2: dmesg_xhci_extended_nok.log.xz --]
[-- Type: application/x-xz, Size: 20428 bytes --]

[-- Attachment #3: dmesg_xhci_extended_ok.log.xz --]
[-- Type: application/x-xz, Size: 20988 bytes --]

[-- Attachment #4: dmesg_xhci_extended_ok_after_replug.log.xz --]
[-- Type: application/x-xz, Size: 24820 bytes --]

Re: USB issue on a TB4 controller?

[Mathias Nyman]

On 31.5.2023 14.56, Christian Schaubschläger wrote:
> Hi,
> 
>> Attached is a patch that adds more debugging, adds a minimum
>> "power on to power good" delay, (as hub reports 0ms), and checks port link
>> states during hub initialization.
>>
>> Does it help? Could you take logs with that patch applied.
>>
>> Only dmesg with xhci and usbcore dynamic debug are needed.
>> xhci traces won't help as issue seems to be between the hub inthe dock and the NIC
> 
> patch applied, see logs in the attachment. The behaviour is unchanged.
> 
> Thanks,
> Christian

Thanks,

In the failed case the hub in the dock doesn't show any activity
on port4 where the NIC is connected. No changes, link isn't in any
error state. It looks just like any empty port.

I don't have any idea what's going on.

I guess it's not possible to connect a protocol analyzer between the
hub in the dock and the NIC?

ok success case:

[    1.712754] usb 6-2-port1: status 02a0 change 0000
[    1.713070] usb 6-2-port2: status 02a0 change 0000
[    1.713567] usb 6-2-port3: status 0203 change 0010  <- another hub
[    1.714184] usb 6-2-port4: status 0203 change 0010  <- NIC

nok failed case:

[    1.716756] usb 6-2-port1: status 02a0 change 0000
[    1.717036] usb 6-2-port2: status 02a0 change 0000
[    1.717395] usb 6-2-port3: status 0203 change 0010  <- another hub
[    1.717976] usb 6-2-port4: status 02a0 change 0000

Thanks
Mathias

Re: USB issue on a TB4 controller?

[Christian Schaubschläger]

Hi,
> Thanks,
>
> In the failed case the hub in the dock doesn't show any activity
> on port4 where the NIC is connected. No changes, link isn't in any
> error state. It looks just like any empty port.
>
> I don't have any idea what's going on.
>
> I guess it's not possible to connect a protocol analyzer between the
> hub in the dock and the NIC?

No, I'm afraid I don't have a protocol analyzer...
Any other logs, etc. I could provide?

Thanks and best regards,
Christian

Re: USB issue on a TB4 controller?

[Christian Schaubschläger]

Hi Mathias,

today I got access to another Dell Latitude model, which shows the exact same issue as the Latitude from before. This time it's a slightly older model with a 12th gen Intel CPU:

  [    0.000000] DMI: Dell Inc. Latitude 5430/0260KT, BIOS 1.12.0 03/20/2023
  [    0.092576] smpboot: CPU0: 12th Gen Intel(R) Core(TM) i5-1245U (family: 0x6, model: 0x9a, stepping: 0x4)

The issue is very easy to reproduce: just boot a recent Ubuntu 23.04 from an USB device, reboot, and the network interface on the dock is gone. Only re-plugging the dock's USB cable (or shutting down and restarting the system) helps to recover the net interface on the dock. I have three docks here (Dell WD19TB, Dell WD22TB4, Lenovo USB-C), all three show the same behaviour. Running the most recent linux kernel does not help.

If I can provide any useful logs I'd be happy to help, just let me know.

Thanks and best regards,
Christian


Am 01.06.23 um 15:54 schrieb Mathias Nyman:
> On 31.5.2023 14.56, Christian Schaubschläger wrote:
>> Hi,
>>
>>> Attached is a patch that adds more debugging, adds a minimum
>>> "power on to power good" delay, (as hub reports 0ms), and checks port link
>>> states during hub initialization.
>>>
>>> Does it help? Could you take logs with that patch applied.
>>>
>>> Only dmesg with xhci and usbcore dynamic debug are needed.
>>> xhci traces won't help as issue seems to be between the hub inthe dock and the NIC
>> patch applied, see logs in the attachment. The behaviour is unchanged.
>>
>> Thanks,
>> Christian
> Thanks,
>
> In the failed case the hub in the dock doesn't show any activity
> on port4 where the NIC is connected. No changes, link isn't in any
> error state. It looks just like any empty port.
>
> I don't have any idea what's going on.
>
> I guess it's not possible to connect a protocol analyzer between the
> hub in the dock and the NIC?
>
> ok success case:
>
> [    1.712754] usb 6-2-port1: status 02a0 change 0000
> [    1.713070] usb 6-2-port2: status 02a0 change 0000
> [    1.713567] usb 6-2-port3: status 0203 change 0010  <- another hub
> [    1.714184] usb 6-2-port4: status 0203 change 0010  <- NIC
>
> nok failed case:
>
> [    1.716756] usb 6-2-port1: status 02a0 change 0000
> [    1.717036] usb 6-2-port2: status 02a0 change 0000
> [    1.717395] usb 6-2-port3: status 0203 change 0010  <- another hub
> [    1.717976] usb 6-2-port4: status 02a0 change 0000
>
> Thanks
> Mathias

Re: USB issue on a TB4 controller?

[Mathias Nyman]

Hi

On 4.7.2023 16.38, Christian Schaubschläger wrote:
> Hi Mathias,
> 
> today I got access to another Dell Latitude model, which shows the exact same issue as the Latitude from before. This time it's a slightly older model with a 12th gen Intel CPU:
> 
>    [    0.000000] DMI: Dell Inc. Latitude 5430/0260KT, BIOS 1.12.0 03/20/2023
>    [    0.092576] smpboot: CPU0: 12th Gen Intel(R) Core(TM) i5-1245U (family: 0x6, model: 0x9a, stepping: 0x4)
> 
> The issue is very easy to reproduce: just boot a recent Ubuntu 23.04 from an USB device, reboot, and the network interface on the dock is gone. Only re-plugging the dock's USB cable (or shutting down and restarting the system) helps to recover the net interface on the dock. I have three docks here (Dell WD19TB, Dell WD22TB4, Lenovo USB-C), all three show the same behaviour. Running the most recent linux kernel does not help.
> 
> If I can provide any useful logs I'd be happy to help, just let me know.
> 

I have to check if we have similar machines and docks laying around.
I'm away until August so there will be some delay on my side

Thanks
Mathias


> Thanks and best regards,
> Christian
> 
> 
> Am 01.06.23 um 15:54 schrieb Mathias Nyman:
>> On 31.5.2023 14.56, Christian Schaubschläger wrote:
>>> Hi,
>>>
>>>> Attached is a patch that adds more debugging, adds a minimum
>>>> "power on to power good" delay, (as hub reports 0ms), and checks port link
>>>> states during hub initialization.
>>>>
>>>> Does it help? Could you take logs with that patch applied.
>>>>
>>>> Only dmesg with xhci and usbcore dynamic debug are needed.
>>>> xhci traces won't help as issue seems to be between the hub inthe dock and the NIC
>>> patch applied, see logs in the attachment. The behaviour is unchanged.
>>>
>>> Thanks,
>>> Christian
>> Thanks,
>>
>> In the failed case the hub in the dock doesn't show any activity
>> on port4 where the NIC is connected. No changes, link isn't in any
>> error state. It looks just like any empty port.
>>
>> I don't have any idea what's going on.
>>
>> I guess it's not possible to connect a protocol analyzer between the
>> hub in the dock and the NIC?
>>
>> ok success case:
>>
>> [    1.712754] usb 6-2-port1: status 02a0 change 0000
>> [    1.713070] usb 6-2-port2: status 02a0 change 0000
>> [    1.713567] usb 6-2-port3: status 0203 change 0010  <- another hub
>> [    1.714184] usb 6-2-port4: status 0203 change 0010  <- NIC
>>
>> nok failed case:
>>
>> [    1.716756] usb 6-2-port1: status 02a0 change 0000
>> [    1.717036] usb 6-2-port2: status 02a0 change 0000
>> [    1.717395] usb 6-2-port3: status 0203 change 0010  <- another hub
>> [    1.717976] usb 6-2-port4: status 02a0 change 0000
>>
>> Thanks
>> Mathias
> 

Re: USB issue on a TB4 controller?

[Christian Schaubschläger]

Hello,

> I have to check if we have similar machines and docks laying around.
> I'm away until August so there will be some delay on my side

I just want to ask, if you could find any machines / docks for testing this. Today I could reproduce the issue with a 6.5.0-rc6 kernel, also with the lastest Ubuntu-22.04.03 which comes with a 6.2 kernel. As I said before, if you need any logs or tests, I'd be happy to help debugging this.

Thanks and best regards,
Christian

Re: USB issue on a TB4 controller?

[Christian Schaubschläger]

Hello,

I wanted to ask again if I could provide any useful support on this matter.

Thanks and best regards,
Christian


Am 16.08.23 um 09:13 schrieb Christian Schaubschläger:
> Hello,
>
>> I have to check if we have similar machines and docks laying around.
>> I'm away until August so there will be some delay on my side
> I just want to ask, if you could find any machines / docks for testing this. Today I could reproduce the issue with a 6.5.0-rc6 kernel, also with the lastest Ubuntu-22.04.03 which comes with a 6.2 kernel. As I said before, if you need any logs or tests, I'd be happy to help debugging this.
>
> Thanks and best regards,
> Christian
>