|
Bugzilla – Full Text Bug Listing |
| Summary: | frequent usb resets starting with 5.11-rc7, 5.11-rc6 was fine | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Dirk Mueller <dmueller> |
| Component: | Kernel | Assignee: | openSUSE Kernel Bugs <kernel-bugs> |
| Status: | RESOLVED WORKSFORME | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | gp, oneukum, tiwai |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
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
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. 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.
(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. 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. I can no longer reproduce ht eproblem with 5.12.0 |
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