https://bugzilla.kernel.org/show_bug.cgi?id=220069 --- Comment #9 from Michał Pecio (michal.pecio@xxxxxxxxx) --- (In reply to Claudio Wunder from comment #6) > Here's the full dmesg log via `journalctl -o short-precise -k -b -3`: > https://gist.github.com/ovflowd/0b0aa5c748683eca33909dc3ed7c66f7 (I shared > on GitHub Gist due to the large size, if you rather have me hosting it on a > FOSS alternative, let me know, I can upload it to gitlab.gnome.org) Thanks. That's not a really huge file, you can upload such files here as attachments to this bug. > pci 0000:6b:00.0: [1022:43f7] type 00 class 0x0c0330 PCIe Legacy Endpoint This means it's the "600 series chipset", which is reportedly a Promontory family chipset, made for AMD by ASMedia. And IME ASMedia controllers are pretty buggy. > xhci_hcd 0000:6b:00.0: Event TRB for slot 18 ep 0 with no TDs queued > usb 8-3: Device not responding to setup address. > xhci_hcd 0000:6b:00.0: ERROR unknown event type 4 That's sort of stuff which may show up when they get completely FUBAR'd and about to stop working at all. So I don't really share the optimism that it's a simple SW bug which causes the abort to fail, it's probably a deeper screwup. The debugfs dump will tell... I think you said you have more of those logs, is the above always appearing a few seconds before "hc died"? It seems related to the 8-3 device, a VIA USB 3.0 hub. IME such problems tend to be happening under particular workloads, so still no idea how a minor kernel update could cause it to appear. Were there no hardware changes, like USB devices added or moved to other ports? How long are you using this machine with all of those devices, which kernel versions were working OK for so long that they certainly cannot possibly have this problem? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
