7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Michel Dänzer]

The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to a ThinkPad P14s Gen 5 AMD stopped working in 7.1.

 ip addr show enx482ae347e7c3

says the interface doesn't exist. The only thing about it in dmesg is:

 r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0

In previous kernels, dmesg had more lines about it:

 r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
 r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
 r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
 r8152 8-1.1:1.0 enx482ae347e7c3: carrier on


I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes the issue.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Mathias Nyman]

On 7/1/26 19:02, Michel Dänzer wrote:
> 
> The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
> 
>   ip addr show enx482ae347e7c3
> 
> says the interface doesn't exist. The only thing about it in dmesg is:
> 
>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> 
> In previous kernels, dmesg had more lines about it:
> 
>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> 
> 
> I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes the issue.
> 
> 

Thanks for reporting this.

That patch limits USB3 roothub change bitmap from 4 bytes to 2 bytes, which
should be enough for the max 15 children USB3 hubs support.
Odd that this change impacts the usb ethernet device of that dock.

It's not an important change, and should be reverted to get things working.
It also reveals there might be a off-by-one or similar bug in hub or xhci code.
would be nice to get that fixed.

Does the roothub have 15 USB3 ports?

If possible, could you share a dmesg with usbcore dynamic debug enabled

mount -t debugfs none /sys/kernel/debug
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
<connect dock>
dmesg

Thanks
Mathias

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Michal Pecio]

On Thu, 2 Jul 2026 00:09:42 +0300, Mathias Nyman wrote:
> On 7/1/26 19:02, Michel Dänzer wrote:
> > 
> > The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to
> > a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
> > 
> >   ip addr show enx482ae347e7c3
> > 
> > says the interface doesn't exist. The only thing about it in dmesg
> > is:
> > 
> >   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> > 
> > In previous kernels, dmesg had more lines about it:
> > 
> >   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> >   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> >   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
> >   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> > 
> > 
> > I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root
> > hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes
> > the issue.

Incredibly bizarre, I wonder if it's some userspace madness.

Does this alternative patch (on top of the revert) break it too?
https://lore.kernel.org/linux-usb/20260504111353.55ba2530.michal.pecio@gmail.com/

> That patch limits USB3 roothub change bitmap from 4 bytes to 2 bytes,
> which should be enough for the max 15 children USB3 hubs support.
> Odd that this change impacts the usb ethernet device of that dock.

Very odd: as you said before, hub driver wouldn't support more than
15 ports anyway, the problem occurs on port 1, and is not any obvious
hub issue like connection event never noticed by the kernel.

I thought that maybe writing the status change URB overflows its
transfer buffer, but usb_hcd_poll_rh_status() seems to be handling
such cases correctly. And xhci_hub_status_data() isn't even aware
of URB length, so it can't be sensitive to this change.

> If possible, could you share a dmesg with usbcore dynamic debug
> enabled
> 
> mount -t debugfs none /sys/kernel/debug
> echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
> <connect dock>
> dmesg

If not possible, please at least post ordinary dmesg. Even if there is
nothing more about "enx482ae347e7c3", there might be about "8-1.1:1.0".
The snippet above is a small part of typical r8152 connection log.

Regards,
Michal

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Michel Dänzer]

On 7/2/26 10:51, Michal Pecio wrote:
> On Thu, 2 Jul 2026 00:09:42 +0300, Mathias Nyman wrote:
>> On 7/1/26 19:02, Michel Dänzer wrote:
>>>
>>> The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to
>>> a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
>>>
>>>   ip addr show enx482ae347e7c3
>>>
>>> says the interface doesn't exist. The only thing about it in dmesg
>>> is:
>>>
>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
>>>
>>> In previous kernels, dmesg had more lines about it:
>>>
>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
>>>
>>>
>>> I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root
>>> hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes
>>> the issue.
> 
> Incredibly bizarre, I wonder if it's some userspace madness.

That reminded me that I'm using (an older upstream version of) usbguard. Unfortunately its GUI notifications when it blocks a USB device aren't working reliably currently.

Manually firing up its settings app revealed that it was indeed blocking the USB3 hub. Overriding it to be allowed fixed the issue with the bisected commit.

Looks like a false alert after all, sorry for the noise, and thanks for the help.


> If not possible, please at least post ordinary dmesg. Even if there is
> nothing more about "enx482ae347e7c3", there might be about "8-1.1:1.0".
> The snippet above is a small part of typical r8152 connection log.

FWIW, the only other message about 8-1.1:1.0 is

 r8152 8-1.1:1.0 (unnamed net_device) (uninitialized): Invalid header when reading pass-thru MAC addr

which is a red herring, since I'm not using the MAC address pass-through functionality.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Greg Kroah-Hartman]

On Thu, Jul 02, 2026 at 02:20:05PM +0200, Michel Dänzer wrote:
> On 7/2/26 10:51, Michal Pecio wrote:
> > On Thu, 2 Jul 2026 00:09:42 +0300, Mathias Nyman wrote:
> >> On 7/1/26 19:02, Michel Dänzer wrote:
> >>>
> >>> The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to
> >>> a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
> >>>
> >>>   ip addr show enx482ae347e7c3
> >>>
> >>> says the interface doesn't exist. The only thing about it in dmesg
> >>> is:
> >>>
> >>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> >>>
> >>> In previous kernels, dmesg had more lines about it:
> >>>
> >>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> >>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> >>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
> >>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> >>>
> >>>
> >>> I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root
> >>> hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes
> >>> the issue.
> > 
> > Incredibly bizarre, I wonder if it's some userspace madness.
> 
> That reminded me that I'm using (an older upstream version of) usbguard. Unfortunately its GUI notifications when it blocks a USB device aren't working reliably currently.
> 
> Manually firing up its settings app revealed that it was indeed blocking the USB3 hub. Overriding it to be allowed fixed the issue with the bisected commit.
> 
> Looks like a false alert after all, sorry for the noise, and thanks for the help.

Thanks for letting us know, and this isn't the first time that usbguard
has caused a problem recently.  Did we change something that broke it's
functionality?

thanks,

greg k-h

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Michel Dänzer]

On 7/2/26 14:22, Greg Kroah-Hartman wrote:
> On Thu, Jul 02, 2026 at 02:20:05PM +0200, Michel Dänzer wrote:
>> On 7/2/26 10:51, Michal Pecio wrote:
>>> On Thu, 2 Jul 2026 00:09:42 +0300, Mathias Nyman wrote:
>>>> On 7/1/26 19:02, Michel Dänzer wrote:
>>>>>
>>>>> The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to
>>>>> a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
>>>>>
>>>>>   ip addr show enx482ae347e7c3
>>>>>
>>>>> says the interface doesn't exist. The only thing about it in dmesg
>>>>> is:
>>>>>
>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
>>>>>
>>>>> In previous kernels, dmesg had more lines about it:
>>>>>
>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
>>>>>
>>>>>
>>>>> I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root
>>>>> hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes
>>>>> the issue.
>>>
>>> Incredibly bizarre, I wonder if it's some userspace madness.
>>
>> That reminded me that I'm using (an older upstream version of) usbguard. Unfortunately its GUI notifications when it blocks a USB device aren't working reliably currently.
>>
>> Manually firing up its settings app revealed that it was indeed blocking the USB3 hub. Overriding it to be allowed fixed the issue with the bisected commit.
>>
>> Looks like a false alert after all, sorry for the noise, and thanks for the help.
> 
> Thanks for letting us know, and this isn't the first time that usbguard
> has caused a problem recently.  Did we change something that broke it's
> functionality?

My assumption is that this change results in usbguard considering the USB3 hub a different device, so the persistent settings to allow it no longer applied.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Greg Kroah-Hartman]

On Thu, Jul 02, 2026 at 02:25:04PM +0200, Michel Dänzer wrote:
> On 7/2/26 14:22, Greg Kroah-Hartman wrote:
> > On Thu, Jul 02, 2026 at 02:20:05PM +0200, Michel Dänzer wrote:
> >> On 7/2/26 10:51, Michal Pecio wrote:
> >>> On Thu, 2 Jul 2026 00:09:42 +0300, Mathias Nyman wrote:
> >>>> On 7/1/26 19:02, Michel Dänzer wrote:
> >>>>>
> >>>>> The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to
> >>>>> a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
> >>>>>
> >>>>>   ip addr show enx482ae347e7c3
> >>>>>
> >>>>> says the interface doesn't exist. The only thing about it in dmesg
> >>>>> is:
> >>>>>
> >>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> >>>>>
> >>>>> In previous kernels, dmesg had more lines about it:
> >>>>>
> >>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> >>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> >>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
> >>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> >>>>>
> >>>>>
> >>>>> I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root
> >>>>> hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes
> >>>>> the issue.
> >>>
> >>> Incredibly bizarre, I wonder if it's some userspace madness.
> >>
> >> That reminded me that I'm using (an older upstream version of) usbguard. Unfortunately its GUI notifications when it blocks a USB device aren't working reliably currently.
> >>
> >> Manually firing up its settings app revealed that it was indeed blocking the USB3 hub. Overriding it to be allowed fixed the issue with the bisected commit.
> >>
> >> Looks like a false alert after all, sorry for the noise, and thanks for the help.
> > 
> > Thanks for letting us know, and this isn't the first time that usbguard
> > has caused a problem recently.  Did we change something that broke it's
> > functionality?
> 
> My assumption is that this change results in usbguard considering the
> USB3 hub a different device, so the persistent settings to allow it no
> longer applied.

"different" in what way, because it is a different speed?  Why would
usbguard be prohibiting hubs?

thanks,

greg k-h

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Michel Dänzer]

On 7/2/26 14:38, Greg Kroah-Hartman wrote:
> On Thu, Jul 02, 2026 at 02:25:04PM +0200, Michel Dänzer wrote:
>> On 7/2/26 14:22, Greg Kroah-Hartman wrote:
>>> On Thu, Jul 02, 2026 at 02:20:05PM +0200, Michel Dänzer wrote:
>>>> On 7/2/26 10:51, Michal Pecio wrote:
>>>>> On Thu, 2 Jul 2026 00:09:42 +0300, Mathias Nyman wrote:
>>>>>> On 7/1/26 19:02, Michel Dänzer wrote:
>>>>>>>
>>>>>>> The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to
>>>>>>> a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
>>>>>>>
>>>>>>>   ip addr show enx482ae347e7c3
>>>>>>>
>>>>>>> says the interface doesn't exist. The only thing about it in dmesg
>>>>>>> is:
>>>>>>>
>>>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
>>>>>>>
>>>>>>> In previous kernels, dmesg had more lines about it:
>>>>>>>
>>>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
>>>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
>>>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
>>>>>>>   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
>>>>>>>
>>>>>>>
>>>>>>> I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root
>>>>>>> hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes
>>>>>>> the issue.
>>>>>
>>>>> Incredibly bizarre, I wonder if it's some userspace madness.
>>>>
>>>> That reminded me that I'm using (an older upstream version of) usbguard. Unfortunately its GUI notifications when it blocks a USB device aren't working reliably currently.
>>>>
>>>> Manually firing up its settings app revealed that it was indeed blocking the USB3 hub. Overriding it to be allowed fixed the issue with the bisected commit.
>>>>
>>>> Looks like a false alert after all, sorry for the noise, and thanks for the help.
>>>
>>> Thanks for letting us know, and this isn't the first time that usbguard
>>> has caused a problem recently.  Did we change something that broke it's
>>> functionality?
>>
>> My assumption is that this change results in usbguard considering the
>> USB3 hub a different device, so the persistent settings to allow it no
>> longer applied.
> 
> "different" in what way, because it is a different speed?  Why would
> usbguard be prohibiting hubs?

What I mean is that usbguard considers the hub two different devices with or without the bisected kernel commit. No idea what exactly makes the difference though.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Michal Pecio]

On Thu, 2 Jul 2026 14:22:25 +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 02, 2026 at 02:20:05PM +0200, Michel Dänzer wrote:
> > That reminded me that I'm using (an older upstream version of)
> > usbguard. Unfortunately its GUI notifications when it blocks a USB
> > device aren't working reliably currently.
> > 
> > Manually firing up its settings app revealed that it was indeed
> > blocking the USB3 hub. Overriding it to be allowed fixed the issue
> > with the bisected commit.
> > 
> > Looks like a false alert after all, sorry for the noise, and thanks
> > for the help.  
> 
> Thanks for letting us know, and this isn't the first time that
> usbguard has caused a problem recently.  Did we change something that
> broke it's functionality?

A few weeks ago we corrected a small inconsistency in USB 3.0 root hub
descriptors to avoid some warnings. That's the bisected patch.

Apparently, usbguard can be configured to reject all devices except for
a list of descriptor hashes. Not sure if there are other whitelisting
options besides hashes? Using this method for root hubs seems to bring
no security benefit (you trust the kernel, right?), only trouble.

Now, these systems require user action to authorize the new descriptor.
Otherwise, usbguard runs amok and disables USB 3.0 root hubs with all
children, AFAIU.

Or is there more to it and the issue is somehow magically specific to
Lenovo USB docks? Both affected users complained about such docks, but
maybe they are simply the only USB devices used by usbguard users :)

Regards,
Michal