Bug 1184088 - frequent usb resets starting with 5.11-rc7, 5.11-rc6 was fine
frequent usb resets starting with 5.11-rc7, 5.11-rc6 was fine
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-03-29 07:30 UTC by Dirk Mueller
Modified: 2021-05-03 14:08 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Mueller 2021-03-29 07:30:39 UTC
Some change between 5.11-rc6 and 5.11-rc7 is causing frequently storms of usb resets, significantly eating cpu power: 

[Sa Mär 27 20:17:47 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd
[Sa Mär 27 20:17:52 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd
[Sa Mär 27 20:17:58 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd
[Sa Mär 27 20:18:03 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd
[Sa Mär 27 20:18:09 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd
[Sa Mär 27 20:18:15 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd
[Sa Mär 27 20:18:20 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd

it stops usually after turning off/on the monitor (the usb hub this is connected to is builtin to my display), but sometimes it just stops by itself, and then at some later point in time resumes again. No idea what exactly triggers it, but I've never seen this with 5.11-rc6 or below. 

lsusb -t -v for this sub tree is:


/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 1: Dev 18, If 0, Class=Hub, Driver=hub/6p, 480M
        ID 0451:8442 Texas Instruments, Inc. 
        |__ Port 6: Dev 25, If 0, Class=, Driver=, 480M
            ID 0451:82ee Texas Instruments, Inc. 
        |__ Port 2: Dev 21, If 3, Class=Human Interface Device, Driver=usbhid, 12M
            ID 047f:c025 Plantronics, Inc. 
        |__ Port 2: Dev 21, If 1, Class=Audio, Driver=snd-usb-audio, 12M
            ID 047f:c025 Plantronics, Inc. 
        |__ Port 2: Dev 21, If 2, Class=Audio, Driver=snd-usb-audio, 12M
            ID 047f:c025 Plantronics, Inc. 
        |__ Port 2: Dev 21, If 0, Class=Audio, Driver=snd-usb-audio, 12M
            ID 047f:c025 Plantronics, Inc. 
        |__ Port 5: Dev 24, If 0, Class=Human Interface Device, Driver=usbhid, 480M
            ID 0451:82ff Texas Instruments, Inc. 
        |__ Port 1: Dev 19, If 0, Class=Hub, Driver=hub/4p, 480M
            ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
            |__ Port 3: Dev 23, If 2, Class=Audio, Driver=snd-usb-audio, 480M
                ID 046d:0825 Logitech, Inc. Webcam C270
            |__ Port 3: Dev 23, If 0, Class=Video, Driver=uvcvideo, 480M
                ID 046d:0825 Logitech, Inc. Webcam C270
            |__ Port 3: Dev 23, If 3, Class=Audio, Driver=snd-usb-audio, 480M
                ID 046d:0825 Logitech, Inc. Webcam C270
            |__ Port 3: Dev 23, If 1, Class=Video, Driver=uvcvideo, 480M
                ID 046d:0825 Logitech, Inc. Webcam C270
Comment 1 Takashi Iwai 2021-03-29 12:04:51 UTC
I guess you meant 5.11.6 and 5.11.7, right?

There are a few XHCI-related fixes between 5.11.6 and 5.11.7:
8d7d6b4c2026c90bcd98e30cd20ac7853741c89a
    usb: xhci: do not perform Soft Retry for some xHCI hosts
631ad31ea151ac5d4808ddfc8f8a4132f391390a
    xhci: Improve detection of device initiated wake signal.
b4bea73a5df516a2befa4feae8b79e177e55c788
    xhci: Fix repeated xhci wake after suspend due to uncleared internal wake state
Comment 2 Dirk Mueller 2021-03-29 15:52:02 UTC
No, I do mean rc6 and rc7. I ran Kernel:HEAD for a while, and stopped after rc7. I was hoping one of the 5.11.x releases fixes it, but at least up and including 5.11.6 the problem still occurs.
Comment 3 Takashi Iwai 2021-03-29 16:05:04 UTC
Ah, then it's an old bug, not the recently introduced one.

Then it's still puzzling, as there are even fewer changes about xhci.

Is it with x86, or other platform?
I'm asking it because the only generic xhci change between rc6 and rc7 is
d4a610635400ccc382792f6be69427078541c678
    xhci: fix bounce buffer usage for non-sg list case
where is very likely irrelevant, and the rest are platform-specific, either for Mediatek, Armada 3720, Renesas, USB gadget and serial quirks, so these look irrelevant, either.  So, none of the changes in drivers/usb/* look suspicious, through a quick glance.
Comment 4 Dirk Mueller 2021-03-29 17:01:04 UTC
(In reply to Takashi Iwai from comment #3)
> Is it with x86, or other platform?

x86, AMD Family 17h - AMD Renoir USB 3.1 (AMD Ryzen 4750G)

> I'm asking it because the only generic xhci change between rc6 and rc7 is
> d4a610635400ccc382792f6be69427078541c678
>     xhci: fix bounce buffer usage for non-sg list case
> where is very likely irrelevant, and the rest are platform-specific, either
> for Mediatek, Armada 3720, Renesas, USB gadget and serial quirks, so these
> look irrelevant, either.  So, none of the changes in drivers/usb/* look
> suspicious, through a quick glance.

Right. so why does it do a "reset" continuously? some time ago (not sure which kernel, some 5.10 or older) it was doing the reset once on boot and then was ignoring that port. If I understand it correctly, the usb device it complains about is: 

http://80.87.195.87/index.php?id=usb:0451-82ee

which has no drivers, so it shouldn't do anything, at least not repeatedly? is there any way to figure out why it keeps trying? Maybe I can make it stop doing that somehow.
Comment 5 Takashi Iwai 2021-03-30 12:23:36 UTC
Well, if you know the regression range in that narrow changes, the best bet would be to build the kernel manually and perform git-bisect.  Anything else would be a wild guess and take longer time in the end.

With "make localmodconfig", the build time should be significantly lower.
Comment 6 Dirk Mueller 2021-05-03 14:08:17 UTC
I can no longer reproduce ht eproblem with 5.12.0