Created attachment 1773608 [details] full kernel logs; booted with the dock , then disconnected and reconnected 1. Please describe the problem: On a Lenovo P1 Gen3 laptop with a Lenovo Workstation Dock v2, when plugging the dock out and then back in without a reboot, USB problems happen. The problems can manifest as: - USB devices attached to the dock randomly not working - USB sound devices, including the dock's built-in sound device, sounding broken-up - Sometimes, the laptop's battery will not charge, reportung that the power supply is connected but not powerful enough An external monitor attached to the dock normally stays working fine. These problems can resolve after some time or they can stay until a "hard" reboot (shutdown and power up again). While the manifestation of the problems can be diverse, the following type of messages, repeating a lot, are always visible in dmesg: [ 79.846810] xhci_hcd 0000:09:00.0: Looking for event-dma 0000000108b6b750 trb-start 0000000108b6b760 trb-end 0000000108b6b760 seg-start 0000000108b6b000 seg-end 0000000108b6bff0 [ 79.862053] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 11 comp_code 1 [ 79.862070] xhci_hcd 0000:09:00.0: Looking for event-dma 0000000108b6b840 trb-start 0000000108b6b850 trb-end 0000000108b6b850 seg-start 0000000108b6b000 seg-end 0000000108b6bff0 [ 79.898106] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 11 comp_code 1 [ 79.898123] xhci_hcd 0000:09:00.0: Looking for event-dma 0000000108b6ba80 trb-start 0000000108b6ba90 trb-end 0000000108b6ba90 seg-start 0000000108b6b000 seg-end 0000000108b6bff0 [ 79.927062] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 11 comp_code 1 2. What is the Version-Release number of the kernel: 5.11.14; also seen with 5.11.11 and 5.11.13 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : In kernels before 5.11.11 problems with this dock were bigger, to the point that the dock was not fully usable. The fix to BZ 1879442 enabled the use of the dock and then this problem could be isolated. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: - Boot the laptop with the dock attached - Disconnect and reconnect the dock - Wait for the monitor and USB devices to reactivate, observe side effects (if they happen) - Check dmesg 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: n/a as yet 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Attached
I have found an online description, from 2019, of this same problem with a Dell Thunderbolt dock: https://www.dell.com/community/XPS/7590-WD19TB-Linux-USB-problems/td-p/7722945 So this is not a Lenovo-exclusive issue.
Just FTR, I have experienced similar issue yesterday with T490s and ThinkPad Thunderbolt 3 Dock. I am (un)plugging my LP from dock quite often and this happened to me for the first time AFAIR. The only difference was that I had my laptop in sleep shortly prior the event.
Confirming that the "USB devices not working suddenly" (keyboard and mouse freeze) problem happened again right now, with the dock firmware already updated to the newest version. (Previously fwupdmgr could not update this dock but now it can). The same kind of messages seen in dmesg too.
Issues as in description except no power issues observed. T590 with thunderbolt doc, I believe gen 2. Latest firmware from `fwupdmgr`. When I turn off/on audio from pulse, issue can disappear. Some errors that I see with dmesg: > [142970.776125] usb 5-2.1.1.4: 1:0: usb_set_interface failed (-32) > [142970.781055] usb 5-2.1.1.4: 1:1: cannot set freq 44100 to ep 0x81 > [142970.789119] usb 5-2.1.1.4: 1:1: cannot set freq 44100 to ep 0x81 > [142970.793372] usb 5-2.1.1.4: 1:0: usb_set_interface failed (-32) > [142970.796994] usb 5-2.1.1.4: 1:1: cannot set freq 44100 to ep 0x81 > [142970.803341] usb 5-2.1.1.4: 1:1: cannot get freq at ep 0x81 > [142970.806811] usb 5-2.1.1.4: 2:1: cannot get freq at ep 0x1 > [142970.903607] input: Lenovo ThinkPad Thunderbolt 3 Dock USB Audio as /devices/pci0000:00/0000:00:1c.4/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:02.0/0000:07:00.0/usb5/5-2/5-2.1/5-2.1.1/5-2.1.1.4/5-2.1.1.4:1.3/0003:17EF:3083.000F/input/input45 [142970.919398] usb 5-2.1.1.4: 1:1: cannot get freq at ep 0x81 Something else, might be from the printer. > [142974.480841] usb usb4-port1: Cannot enable. Maybe the USB cable is bad? > [142975.549128] usblp 5-2.4:1.1: usblp0: USB Bidirectional printer dev 4 if 1 alt 0 proto 2 vid 0x04B8 pid 0x087D No idea where is this coming from: > [146866.340797] xhci_hcd 0000:07:00.0: WARN Event TRB for slot 9 ep 1 with no TDs queued?
Created attachment 1774701 [details] journalctl output when error occurs
Created attachment 1774702 [details] full kernel logs; booted without the dock, connected and took screenshot
I have the same issue. After a hot plug, the keyboard and mouse freeze (or lags) at random times. My external screen keeps working fine. Taking a screenshot often triggers the freeze. I have installed the latest firmware on the laptop as well as the Thunderbolt device. Attachment https://bugzilla.redhat.com/attachment.cgi?id=1774702 contains the journalctl log. [dieter@localhost ~]$ uname -r 5.11.14-200.fc33.x86_64 [dieter@localhost ~]$ cat /etc/fedora-release Fedora release 33 (Thirty Three)
@Mark: Do you think you could bring this to the attention of the right people in Lenovo?
Absolutely - can you confirm the FW version for the dock and the dock USB hub components on the dock (should be displayed with fwupdmgr get-device). Mine is on 62.00 for the dock 51.63 for the USB hubs As a note - FW is up on LVFS now so if it needs updating you should get prompted Just to double check - "Thunderbolt 3 workstation Gen 2" dock right? I've got both of these so I'll see if I can reproduce. I have a bunch of USB devices in mine (keyboard, mouse, headset) and haven't seen a problem with my P1G2 - but I don't disconnect/reconnect very often.... Mark
Mine is here: https://github.com/fwupd/firmware-lenovo-thinkpad/files/6351147/all_devs.txt For me issues also occur on sleep/wake cycles. Also lately laptop wakes up by itself after 2-3 seconds when connected to the doc so I need to disconnect dock and put it to sleep.
Created attachment 1775423 [details] List of devices and firmware version
I have a ThinkPad P1 Gen 3 and a ThinkPad Thunderbolt 3 Workstation Dock Gen 2. I uploaded the output of fwupdmgr get-devices. I have the same versions.
Created attachment 1775440 [details] fwupdmgr get-devices
(In reply to Mark Pearson from comment #9) > Absolutely Thx a lot. > can you confirm the FW version for the dock and the dock USB > hub components on the dock (should be displayed with fwupdmgr get-device). > Mine is on 62.00 for the dock 51.63 for the USB hubs Attached above. > As a note - FW is up on LVFS now so if it needs updating you should get > prompted I have updated the FW yesterday, will see if that changes anything.
Created attachment 1775472 [details] Output of fwupdmgr get-devices This is my output of fwupdmgr get-devices The laptop is the ThinkPad P1Gen3, and the dock is the Workstation Dock Gen2. I did update the firmware in the dock. After the update the issue became somewhat more rare but still does happen. Once it even happened without a hotplug, but normally happens after a hotplug (right after one or in several minutes). I would suggest repeated hotplugs with a 10 minute interval to try and reproduce it.
I've not been able to reproduce this issue myself yet - but I've had another customer report similar. For them they're only seeing the issue with USB3 devices, not with USB2 - does that match what you see? Any guidance on (roughly) how many hotplugs it takes? Just to make sure I'm trying hard enough :) Mark
In my case, unplugging the dock, plugging it back in, waiting 20 seconds for everything to connect and then take a screenshot always results in a freeze of my external keyboard and mouse. Do you mean whether or not my keyboard / mouse support USB3? Dieter
Dieter, for me it often takes 2-3 days of work. I just close lid and open it in the morning. I don't shutdown, only when I do updates at most weekly unless I care about something specific.
Just did a test run of disconnects/reconnects. Kernel 5.11.16-200.fc33.x86_64 . I did not udate any firware since attaching the output of fwupdmgr get-devices to this bug, attachment 1775472 [details]. My configuration: USB2 keyboard and mouse, both connected to USB3 hum in monitor. The USB hub cable from the monitor is connected to the dock, alongside the HDMI cable from the same monitor (the video keeps working in all cases). First disconnect/reconnect: USB immediately failed and did not restart over a couple of minutes. From dmesg: [168592.679918] retire_capture_urb: 357 callbacks suppressed [168593.014810] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 [168593.014827] xhci_hcd 0000:09:00.0: Looking for event-dma 00000003a4c05240 trb-start 00000003a4c05250 trb-end 00000003a4c05250 seg-start 00000003a4c05000 seg-end 00000003a4c05ff0 [168593.200813] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 [168593.200829] xhci_hcd 0000:09:00.0: Looking for event-dma 00000003a4c05de0 trb-start 00000003a4c05df0 trb-end 00000003a4c05df0 seg-start 00000003a4c05000 seg-end 00000003a4c05ff0 [168593.472264] xhci_hcd 0000:09:00.0: WARN Event TRB for slot 9 ep 2 with no TDs queued? [168593.489544] xhci_hcd 0000:09:00.0: WARN Event TRB for slot 9 ep 1 with no TDs queued? That last line repeats many times. However this was the only time the issue reproduced. All other times things worked perfectly (I did want for some time after the reconnect). However, some log issues still existed, examples from different times: [169114.015337] retire_capture_urb: 1922 callbacks suppressed [169115.192904] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000730137fe port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed [169115.202025] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000730137fe port 2: DPCD read on addr 0x4b0 for 1 bytes NAKed [169115.211152] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000730137fe port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed [169116.585303] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 [169116.585319] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004bf5d4ed0 trb-start 00000004bf5d4ee0 trb-end 00000004bf5d4ee0 seg-start 00000004bf5d4000 seg-end 00000004bf5d4ff0 [169117.936321] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 [169117.936336] xhci_hcd 0000:09:00.0: Looking for event-dma 00000004bf5d43a0 trb-start 00000004bf5d43b0 trb-end 00000004bf5d43b0 seg-start 00000004bf5d4000 seg-end 00000004bf5d4ff0 (another plug in-out:) [170680.194072] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 000000005c309f61 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed (in this case this was the only error line but it repeated several times) I also noticed that there is some flashing of USB power (the LED of the mouse flashes) after the connection. This seems to coincide with those log messages?
Just as an update - the other customer is seeing it every time with different USB3 devices (SSD drives). I'll be discussing with the docking team if it's related to the docks USB3 hub or not, but it seems very reproducible. Dieter - if it's possible to confirm whether your devices are USB2 or 3 when they go missing that would be helpful (lsusb -v for the device and check for bcdUSB worked for me). Just so I know if this is two separate issues or not. Mark
Mark - I ran lsusb -v. My external webcam, headset and mouse are version 2.00. My keyboard is 1.10.
I don't think I have any USB3 device connected to my dock. But also, it did not happen to me since last time. This is my `lsusb` output: ~~~ $ lsusb -t -v /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub |__ Port 2: Dev 59, If 0, Class=Hub, Driver=hub/4p, 5000M ID 17ef:307f Lenovo |__ Port 1: Dev 60, If 0, Class=Hub, Driver=hub/4p, 5000M ID 17ef:307f Lenovo |__ Port 2: Dev 61, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M ID 17ef:3082 Lenovo /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub |__ Port 2: Dev 84, If 0, Class=Hub, Driver=hub/5p, 480M ID 17ef:3080 Lenovo |__ Port 1: Dev 85, If 0, Class=Hub, Driver=hub/4p, 480M ID 17ef:3080 Lenovo |__ Port 1: Dev 88, If 0, Class=Hub, Driver=hub/2p, 480M ID 17ef:3081 Lenovo |__ Port 2: Dev 91, If 2, Class=Audio, Driver=snd-usb-audio, 12M ID 17ef:3083 Lenovo |__ Port 2: Dev 91, If 0, Class=Audio, Driver=snd-usb-audio, 12M ID 17ef:3083 Lenovo |__ Port 2: Dev 91, If 3, Class=Human Interface Device, Driver=usbhid, 12M ID 17ef:3083 Lenovo |__ Port 2: Dev 91, If 1, Class=Audio, Driver=snd-usb-audio, 12M ID 17ef:3083 Lenovo |__ Port 4: Dev 92, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M ID 046d:c069 Logitech, Inc. M-U0007 [Corded Mouse M500] |__ Port 4: Dev 93, If 0, Class=Hub, Driver=hub/4p, 480M ID 0424:2504 Microchip Technology, Inc. (formerly SMSC) |__ Port 2: Dev 86, If 3, Class=Human Interface Device, Driver=usbhid, 12M ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device |__ Port 2: Dev 86, If 1, Class=Audio, Driver=snd-usb-audio, 12M ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device |__ Port 2: Dev 86, If 2, Class=Audio, Driver=snd-usb-audio, 12M ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device |__ Port 2: Dev 86, If 0, Class=Audio, Driver=snd-usb-audio, 12M ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device |__ Port 5: Dev 89, If 0, Class=, Driver=, 480M ID 2109:8887 VIA Labs, Inc. |__ Port 3: Dev 87, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0 |__ Port 3: Dev 87, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0 |__ Port 3: Dev 3, If 2, Class=Chip/SmartCard, Driver=, 12M ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID |__ Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID |__ Port 3: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID |__ Port 8: Dev 4, If 3, Class=Video, Driver=uvcvideo, 480M ID 13d3:56bc IMC Networks |__ Port 8: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M ID 13d3:56bc IMC Networks |__ Port 8: Dev 4, If 2, Class=Video, Driver=uvcvideo, 480M ID 13d3:56bc IMC Networks |__ Port 8: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M ID 13d3:56bc IMC Networks |__ Port 10: Dev 6, If 0, Class=Wireless, Driver=btusb, 12M ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP) |__ Port 10: Dev 6, If 1, Class=Wireless, Driver=btusb, 12M ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP) ~~~
For your information, I still have the issue after upgrading to Fedora 34.
Hello, I have the same issue with following: Lenovo P1 Gen2, Thunderbolt Dock Gen2, Fedora 34 My keyboard, mouse, trackball and external sound devices stop working after redocking. The only solution is reboot. Also note that undocking / plug back in WORKED with Linux Mint (LMDE4) either on the same hardware booted from USB installation media and also on Lenovo T470 with LMDE4 installed on it. If you need more specific information, please ask me. Cheers -michael-
The issue did not happen for a few days. And then, today, it struck as I woke the machine from sleep, still connected to the dock. The wake-up caused the image to be wrongly positioned between screens (a separate bug that I need to test more before filing, likely X server), so I plugged the dock out and back in. Then the screen worked normally but the USB devices (keyboard and mouse) did not working at all. Plugging out and back in did not help so I rebooted, but saved the dmesg output before rebooting and will attach it now.
Created attachment 1784636 [details] dmesg output. After a wakeup and plugging the dock out-in, USB devices did not work; more plugging out-in did not resolve it
The same issue happens to me: Last kernel without issues was 5.9.16-200.fc33.x86_64 After using any newer kernel available for fedora, I see USB issues
(In reply to Martin Bašti from comment #27) > The same issue happens to me: > > Last kernel without issues was 5.9.16-200.fc33.x86_64 > After using any newer kernel available for fedora, I see USB issues Oh, that is interesting I was under the impression that these issues also happened with older kernels. If this is a regression in 5.10 (and newer) then that should make fixing this a whole lot easier. Taking a quick look at the new xhci commits in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/usb/host?h=v5.10 vs: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/usb/host?h=v5.9 Then there are not that many, so assuming that this is a problem with the xhci driver (and not elsewhere) we should be able to figure out which commit is causing the problem relatively easily. I believe that I can reproduce this myself, so I'll try to get to the bottom of this. Note I likely won't have time to investigate this until next week.
Note to self, most likely commit to be causing this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=edc649a8234118f80869ca860a0048821a4898e6 Other possible candidates: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18a367e8947d72dd91b6fc401e88a2952c6363f7
I could not test back in 5.9 times as I could not get the dock to work in any stable way at all before 5.11. Do you need me to do a test with 5.9.16-200.fc33 to see if I can make it work now and if the issue reproduces?
(In reply to Misha Ramendik from comment #30) > I could not test back in 5.9 times as I could not get the dock to work in > any stable way at all before 5.11. Do you need me to do a test with > 5.9.16-200.fc33 to see if I can make it work now and if the issue reproduces? As I mentioned I should be able to reproduce this myself, still if you want to try an extra datapoint is always welcome.
Just catching up with this bug - as a note I could reproduce this at ease with 5.13-rc4, which I happened to be using for development, but I can't see the issue with 5.12.9 (kernel.org) or 5.12.8 (Fedora). All tested with the P1G3 on the TBT3 WS G2 dock. I've not had a chance to try other versions yet to narrow it down more (or try the 5.11 kernels mentioned above). Mark
hmm, I've upgraded to 5.12.9-300.fc34.x86_64 one hour ago, and I don't see any suspicious messages in dmesg nor crashing or keyboard issues which I had with 5.11.*. Maybe 5.12.9 fixed it for me :) I'll continue with using this kernel version and let you know after more hours of active work with it
Nope I was too optimistic :| with 5.12.9-300.fc34.x86_64 is the last things in logs before I had to reboot because I couldn't work on laptop anymore Jun 10 10:40:31 localhost.localdomain kernel: usb 5-2.3: reset full-speed USB device number 4 using xhci_hcd Jun 10 10:40:31 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a112d0 trb-start 0000000117a112e0 trb-end 0000000117a112e0 seg-start 0000000117a11000 seg-end 0000000117a11ff0 Jun 10 10:40:31 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:31 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a110a0 trb-start 0000000117a110b0 trb-end 0000000117a110b0 seg-start 0000000117a11000 seg-end 0000000117a11ff0 Jun 10 10:40:31 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 36 Jun 10 10:40:30 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a15610 trb-start 0000000117a15620 trb-end 0000000117a15620 seg-start 0000000117a15000 seg-end 0000000117a15ff0 Jun 10 10:40:30 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 36 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a119e0 trb-start 0000000117a119f0 trb-end 0000000117a119f0 seg-start 0000000117a11000 seg-end 0000000117a11ff0 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a11750 trb-start 0000000117a11760 trb-end 0000000117a11760 seg-start 0000000117a11000 seg-end 0000000117a11ff0 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a112b0 trb-start 0000000117a112c0 trb-end 0000000117a112c0 seg-start 0000000117a11000 seg-end 0000000117a11ff0 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a156b0 trb-start 0000000117a156c0 trb-end 0000000117a156c0 seg-start 0000000117a15000 seg-end 0000000117a15ff0 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a15690 trb-start 0000000117a156a0 trb-end 0000000117a156a0 seg-start 0000000117a15000 seg-end 0000000117a15ff0 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a152a0 trb-start 0000000117a152b0 trb-end 0000000117a152b0 seg-start 0000000117a15000 seg-end 0000000117a15ff0 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a15060 trb-start 0000000117a15070 trb-end 0000000117a15070 seg-start 0000000117a15000 seg-end 0000000117a15ff0 Jun 10 10:40:29 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 36 Jun 10 10:40:28 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a11120 trb-start 0000000117a11130 trb-end 0000000117a11130 seg-start 0000000117a11000 seg-end 0000000117a11ff0 Jun 10 10:40:28 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Jun 10 10:40:28 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: Looking for event-dma 0000000117a11630 trb-start 0000000117a11640 trb-end 0000000117a11640 seg-start 0000000117a11000 seg-end 0000000117a11ff0 Jun 10 10:40:28 localhost.localdomain kernel: xhci_hcd 0000:07:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1
If you are seeing this bug, I could use some help with trying to get this fixed. First of all you need to have a way to reliable reproduce this, I believe that unplugging + replugging and then playing music over the audio-output from the dock should reliable reproduce this. According to some of the comments above downgrading to a 5.9 kernel may fix this. So once you can reliable reproduce this, please check if the problem indeed goes away with older kernels, you can find older Fedora kernel builds here: https://koji.fedoraproject.org/koji/packageinfo?packageID=8 And in case you need them here are some instructions on installing a kernel directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt The first step here would be to find out which major kernel broke things, so try to install the 5.x.0 build for each x first, and then if say 5.10.0 is the first broken kernel, see if the latest 5.9.y with y as high as possible is also broken. If we get lucky and the highest 5.x.y is also broken then try to figure out which is the first 5.x.y which breaks. With that info we might be able to figure out which change exactly broke things.
I can report the same problem connecting to my external gpu with thunderbolt. My machine is a Lenovo T480, My OS is fc33 and the dock is an HP OMEN. The problem showed up in kernel 5.13.4 and persists through 5.13.9. It goes away when I revert to 5.12.15. The specific symptom is that when I boot up connected to the dock with a 5.13 kernel none of the devices plugged in the dock (mouse, keyboard, monitors) work and I get a "nvidia driver not available reverting to nouveau" message. Laptop keyboard and touchpad are active.
Created attachment 1814028 [details] boot with 5.12.15 kernel
Created attachment 1814029 [details] boot with 5.13.9 kernel
There was a July commit 8e3341257e3b5774ec8cd3ef1ba0c0d3fada322b which reversed previous commit 6f3badead6a078cf3c71f381f9d84ac922984a00 causing thunderbolt connection problems roughly when my problem started. Can anyone report the first and last kernels for which this bug was active?
(In reply to olinart from comment #39) > There was a July commit 8e3341257e3b5774ec8cd3ef1ba0c0d3fada322b which > reversed previous commit 6f3badead6a078cf3c71f381f9d84ac922984a00 causing > thunderbolt connection problems roughly when my problem started. Can anyone > report the first and last kernels for which this bug was active? Thank you for your suggestion, but I don't think that this is a thunderbolt authorization issue, if it were then the XHCI controller in the dock would not be visible at all, rather then giving the errors reported here. FWIW the revert has made it into the 5.13.10 kernel, which is available in updates-testing now. To install this kernel run: "sudo dnf update --enablerepo=updates-testing 'kernel*'", but I don't expect this to make a difference. If you want to help debug this, please see comment 35.
I have just updated from 5.12.13 to 5.13.9 and things got a lot worse. In 5.12.13 the issue happened occasionally. In 5.13.9 ithappens every time you hotplug and most of the times you wake up from a hibernate. Moreover. after a hotplug and the USB devices not working, a "warm" reboot, whether back into 5.13.9 or into 5.12.13, locks up the system. A power-off is required to resume normal operation. The full dmesg output for the session where the issue occurred is attached. I can, if needed, reproduce the lockup and try to recover the journald log (it failed right now but it seems journald.conf was somehow reset on this system).
This is probably different issue, but last time I have plugged my dock back to LP, the system completely died. These are first and the last records of my journal: ~~~ -- Journal begins at Fri 2021-02-19 07:33:06 CET, ends at Wed 2021-08-18 12:33:57 CEST. -- srp 12 20:07:14 localhost.localdomain kernel: Linux version 5.12.13-300.fc34.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3), GNU ld version 2.35.1-41.fc34) #1 > srp 12 20:07:14 localhost.localdomain kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.13-300.fc34.x86_64 root=UUID=05155632-36f2-4551-9440-2130f7732ea8 ro rootflags=subvol=root rhgb quiet ... snip ... srp 16 20:17:10 localhost.localdomain systemd[1493]: Finished Cleanup of User's Temporary Files and Directories. srp 16 20:20:30 localhost.localdomain kernel: ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-95) srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: [8086:15c0] type 01 class 0x060400 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: enabling Extended Tags srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: supports D1 D2 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: [8086:15c0] type 01 class 0x060400 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: enabling Extended Tags srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: supports D1 D2 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: [8086:15c0] type 01 class 0x060400 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: enabling Extended Tags srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: supports D1 D2 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: PME# supported from D0 D1 D2 D3hot D3cold srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: [8086:15c0] type 01 class 0x060400 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: enabling Extended Tags srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: supports D1 D2 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: PME# supported from D0 D1 D2 D3hot D3cold srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: PCI bridge to [bus 02-39] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: bridge window [mem 0xd4000000-0xea0fffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: bridge window [mem 0xb0000000-0xd1ffffff 64bit pref] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:03:00.0: [8086:15bf] type 00 class 0x088000 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:03:00.0: reg 0x10: [mem 0xea000000-0xea03ffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:03:00.0: reg 0x14: [mem 0xea040000-0xea040fff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:03:00.0: enabling Extended Tags srp 16 20:20:30 localhost.localdomain kernel: pci 0000:03:00.0: supports D1 D2 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: PCI bridge to [bus 03] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: bridge window [mem 0xea000000-0xea0fffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: PCI bridge to [bus 04-38] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: bridge window [mem 0xd4000000-0xe9efffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: bridge window [mem 0xb0000000-0xd1ffffff 64bit pref] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: PCI bridge to [bus 39] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: bridge window [mem 0xe9f00000-0xe9ffffff] srp 16 20:20:30 localhost.localdomain kernel: pci_bus 0000:02: Allocating resources srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: bridge window [io 0x1000-0x0fff] to [bus 04-38] add_size 1000 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: bridge window [io 0x1000-0x0fff] to [bus 02-39] add_size 2000 srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: BAR 13: assigned [io 0x2000-0x3fff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: BAR 13: assigned [io 0x2000-0x2fff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: PCI bridge to [bus 03] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:00.0: bridge window [mem 0xea000000-0xea0fffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: PCI bridge to [bus 04-38] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: bridge window [io 0x2000-0x2fff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: bridge window [mem 0xd4000000-0xe9efffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:01.0: bridge window [mem 0xb0000000-0xd1ffffff 64bit pref] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: PCI bridge to [bus 39] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:02:02.0: bridge window [mem 0xe9f00000-0xe9ffffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: PCI bridge to [bus 02-39] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: bridge window [io 0x2000-0x3fff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: bridge window [mem 0xd4000000-0xea0fffff] srp 16 20:20:30 localhost.localdomain kernel: pci 0000:01:00.0: bridge window [mem 0xb0000000-0xd1ffffff 64bit pref] srp 16 20:20:30 localhost.localdomain kernel: pcieport 0000:01:00.0: enabling device (0006 -> 0007) srp 16 20:20:30 localhost.localdomain kernel: pcieport 0000:02:01.0: enabling device (0006 -> 0007) srp 16 20:20:30 localhost.localdomain boltd[798]: probing: adding /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0 to roots srp 16 20:20:30 localhost.localdomain boltd[798]: probing: started [1000] srp 16 20:20:31 localhost.localdomain boltd[798]: probing: adding /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0 to roots srp 16 20:20:33 localhost.localdomain boltd[798]: probing: timeout, done: [2100776] (2000000) srp 16 20:20:35 localhost.localdomain boltd[798]: probing: started [1000] srp 16 20:20:35 localhost.localdomain kernel: pci_bus 0000:02: Allocating resources srp 16 20:20:36 localhost.localdomain kernel: thunderbolt 0-1: new device found, vendor=0x108 device=0x1720 srp 16 20:20:36 localhost.localdomain kernel: thunderbolt 0-1: Lenovo ThinkPad Thunderbolt 3 Dock ~~~ And that was it. However, I don't have reliable way to reproduce this I am afraid :/
(In reply to Hans deGoade, comment 40) Kernel 5.13.10 has come available from the updates repo, and I tried running it with the hardware mentioned above. I boot up with the OMEN dock attached. I get the reverting to nouveau message. Keyboard and mouse connected to the dock via usb work. Both monitors attached to the dock fail. Comparing the Xorg.0.logs I see that the gpu is not recognized by 5.13.10. 5.13.10 ... [ 27.236] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 27.238] (II) xfree86: Adding drm device (/dev/dri/card0) [ 27.244] (--) PCI:*(0@0:2:0) 8086:5917:17aa:225d rev 7, Mem @ 0xe7000000/16777216, 0xc0000000/268435456, I/O @ 0x0000e000/64, BIOS @ 0x????????/65536 [ 27.244] (--) PCI: (9@0:0:0) 10de:1c81:1458:3747 rev 161, Mem @ 0xd0000000/16777216, 0x90000000/268435456, 0xa0000000/33554432, I/O @ 0x00003000/128, BIOS @ 0x????????/524288 [ 27.244] (II) LoadModule: "glx" [ 27.245] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 27.254] (II) Module glx: vendor="X.Org Foundation" [ 27.254] compiled for 1.20.11, module version = 1.0.0 [ 27.254] ABI class: X.Org Server Extension, version 10.0 [ 27.254] (==) Matched modesetting as autoconfigured driver 0 [ 27.254] (==) Matched fbdev as autoconfigured driver 1 [ 27.254] (==) Matched vesa as autoconfigured driver 2 [ 27.254] (==) Assigned the driver to the xf86ConfigLayout [ 27.254] (II) LoadModule: "modesetting" [ 27.255] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 27.255] (II) Module modesetting: vendor="X.Org Foundation" [ 27.255] compiled for 1.20.11, module version = 1.20.11 [ 27.255] Module class: X.Org Video Driver [ 27.255] ABI class: X.Org Video Driver, version 24.1 ... 5.12.15 [ 28.092] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 28.096] (II) xfree86: Adding drm device (/dev/dri/card0) [ 28.096] (II) xfree86: Adding drm device (/dev/dri/card1) [ 28.152] (--) PCI:*(0@0:2:0) 8086:5917:17aa:225d rev 7, Mem @ 0xe7000000/16777216, 0xc0000000/268435456, I/O @ 0x0000e000/64, BIOS @ 0x????????/131072 [ 28.152] (--) PCI: (9@0:0:0) 10de:1c81:1458:3747 rev 161, Mem @ 0xd0000000/16777216, 0x90000000/268435456, 0xa0000000/33554432, I/O @ 0x00003000/128, BIOS @ 0x????????/524288 [ 28.152] (II) LoadModule: "glx" [ 28.155] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 28.163] (II) Module glx: vendor="X.Org Foundation" [ 28.164] compiled for 1.20.11, module version = 1.0.0 [ 28.164] ABI class: X.Org Server Extension, version 10.0 [ 28.164] (II) Applying OutputClass "nvidia" to /dev/dri/card1 [ 28.164] loading driver: nvidia [ 28.164] (II) Applying OutputClass "nvidia" to /dev/dri/card1 [ 28.164] loading driver: nvidia [ 28.273] (==) Matched nvidia as autoconfigured driver 0 So this eliminates the commit 8e3341257e3b5774ec8cd3ef1ba0c0d3fada322b as a possible fix as Hans predicted, and puts my problem starting between 5.13.01 and 5.13.04. I can try narrowing this down with your instructions in comment 35. Was not 5.13.4 the first 15.13 released on updates?
@hdegoede I'm please to report that my issue with the external gpu not being recognized seems fixed in kernel 5.13.12. Thanks to the developers for their work!
Not sure why I was needinfo-ed on this, clearing need-info.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I updated to Fedora 35 with kernel 5.14.18-300.fc35.x86_64 and I still have moments when the keyboard and mouse stop working (a while) after plugging in the docking station. I have not found a consistent way to reproduce this though. I updated the version of this bug ticket.
Good news, I've been tracking this issue since I can reliably reproduce it myself and at least my reproducer is fixed with the following 2 kernel patches: https://lore.kernel.org/linux-usb/20211115221630.871204-1-mathias.nyman@linux.intel.com/ https://lore.kernel.org/linux-usb/20211122105003.1089218-1-mathias.nyman@linux.intel.com/ I expect these 2 patches (or a squashed version of them) to get merged soon; and after that these patches should get backported to the stable kernel release series soon.
@hdegoede Thank you for the information!
The 2 fixes for this have been added to the 5.15 stable series queue: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=queue/5.15 So they should show up in 5.15.6 when it is released.
5.15.6 is now available in updates-testing and at least for me this resolves the USB issues I was seeing after hotplugging the dock, please give it a test and let us know if this version fixes things: sudo dnf update --enablerepo=updates-testing 'kernel*'
I've installed 5.15.6 from updates-testing and issue still present. But it's fixed in 5.16.0-rc3.
(In reply to Alex Pozharov from comment #55) > I've installed 5.15.6 from updates-testing and issue still present. > But it's fixed in 5.16.0-rc3. Ah, interesting I have indeed been testing with 5.16 based kernels. So I guess there is some other fix hiding somewhere in 5.16 which fixes this. Too bad that 5.16.6 does not fix things, that means we will need to wait a bit longer before this will be fixed for most Fedora users.
Maybe the audio patches? https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for-next&id=d5f871f89e21bb71827ea57bd484eedea85839a0
Things seem to be a bit worse with 5.15.6 for me - I had two instances of losing the USB devices *randomly* without a plug-out-in nor a system sleep. Logs have: Dec 09 16:32:53 ramendik-2021 kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Dec 09 16:32:53 ramendik-2021 kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000000ffe725b0 trb-start 00000000ffe725c0 trb-end 00000000ffe725c0 seg-start 00000000ffe72000 seg-end 00000000ffe72ff0 Dec 09 16:33:20 ramendik-2021 kernel: usb 5-2.1.1.2: 2:1: cannot get freq at ep 0x1 Dec 09 16:33:23 ramendik-2021 kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Dec 09 16:33:23 ramendik-2021 kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000000ffe72100 trb-start 00000000ffe72110 trb-end 00000000ffe72110 seg-start 00000000ffe72000 seg-end 00000000ffe72ff0 Dec 09 16:33:23 ramendik-2021 kernel: xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Dec 09 16:33:23 ramendik-2021 kernel: xhci_hcd 0000:09:00.0: Looking for event-dma 00000000ffe72410 trb-start 00000000ffe72420 trb-end 00000000ffe72420 seg-start 00000000ffe72000 seg-end 00000000ffe72ff0
Issue still there with 5.15.7 from updates-testing.
I can confirm it's still present in 5.15.6, but I'm running 5.16.0-0.rc4.29.vanilla.1.fc35.x86_64 for a few days and haven't seen the issue so far.
Right, I don't think we are going to find time to figure out what exactly in 5.16 fixes this before the upcoming holidays and soon after the holidays 5.16 will be released. So I believe that it is probably best to just wait for 5.16 to hit the Fedora repos at approx. the end of January
I have this problem on a Thinkpad P1, 5.15.10-200.fc35.x86_64. For me these BIOS settings seem to be a workaround: Config > Thunderbolt > BIOS assist: OFF Security: No Security Pre-Boot: Enable May be useful to folks till the 5.16 fix is available.
(In reply to Alan Conway from comment #62) > I have this problem on a Thinkpad P1, 5.15.10-200.fc35.x86_64. > For me these BIOS settings seem to be a workaround: > > Config > Thunderbolt > > BIOS assist: OFF > Security: No Security > Pre-Boot: Enable > > > May be useful to folks till the 5.16 fix is available. FYI: those BIOS settings seem to fix the problem of not reconnecting USB devices on the thunderbolt, however dmesg is still full of these: [ 1028.927684] xhci_hcd 0000:09:00.0: Looking for event-dma 0000000100b62670 trb-start 0000000100b62680 trb-end 0000000100b62680 seg-start 0000000100b62000 seg-end 0000000100b62ff0 [ 1028.973686] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 [ 1028.973697] xhci_hcd 0000:09:00.0: Looking for event-dma 0000000100b62950 trb-start 0000000100b62960 trb-end 0000000100b62960 seg-start 0000000100b62000 seg-end 0000000100b62ff0 [ 1028.978608] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 [ 1028.978620] xhci_hcd 0000:09:00.0: Looking for event-dma 0000000100b629a0 trb-start 0000000100b629b0 trb-end 0000000100b629b0 seg-start 0000000100b62000 seg-end 0000000100b62ff0 [ 1028.991618] xhci_hcd 0000:09:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 No idea if/how they are related.
In my case, the USB ID was the `Lenovo ThinkPad Thunderbolt 3 Dock USB Audio` one and I 'fixed' it by disabling the USB suspend on that specific device as well as all the audio usb related stuff on the tlp.conf settings: ``` grep -v -E '^#|^$' /etc/tlp.conf SOUND_POWER_SAVE_ON_AC=0 SOUND_POWER_SAVE_ON_BAT=0 SOUND_POWER_SAVE_CONTROLLER=N USB_AUTOSUSPEND=1 USB_DENYLIST="17ef:3083" USB_EXCLUDE_AUDIO=1 USB_EXCLUDE_BTUSB=1 USB_EXCLUDE_PHONE=1 USB_EXCLUDE_WWAN=1 ```
(In reply to Eduardo Minguez from comment #64) > In my case, the USB ID was the `Lenovo ThinkPad Thunderbolt 3 Dock USB > Audio` one and I 'fixed' it by disabling the USB suspend on that specific > device as well as all the audio usb related stuff on the tlp.conf settings: > > ``` > grep -v -E '^#|^$' /etc/tlp.conf > SOUND_POWER_SAVE_ON_AC=0 > SOUND_POWER_SAVE_ON_BAT=0 > SOUND_POWER_SAVE_CONTROLLER=N > USB_AUTOSUSPEND=1 > USB_DENYLIST="17ef:3083" > USB_EXCLUDE_AUDIO=1 > USB_EXCLUDE_BTUSB=1 > USB_EXCLUDE_PHONE=1 > USB_EXCLUDE_WWAN=1 > ``` Nevermind, the error came back after a while.
It now seems fixed after installing the `5.16.0-0.rc7.20211231git4f3d93c6eaff.52.vanilla.1.fc35.x86_64` vanilla kernel (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories)
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.