Bug 219198
| Summary: | usb on Dell WD19TB Thunderbolt Dock stop working | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Markus Rathgeb (maggu2810) |
| Component: | USB | Assignee: | Default virtual assignee for Drivers/USB (drivers_usb) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | adamw, gregkh, maggu2810, pmenzel+bugzilla.kernel.org |
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
| Attachments: |
kernel log 6.11.0-0.rc4.38.fc41
kernel log 6.11.0-0.rc5.43.fc41 kernel log 6.11.0-0.rc0.20240716gitd67978318827.2.fc41.x86_64 journal from a 6.10.6 boot where the bug doesn't happen journal from a 6.11 rc5 boot where the bug does happen kernel log 6.11.0-rc1 kernel-6.10.0.804f98e224e4+.txt kernel-6.10.0.f90584f4beb8+.txt [unrelated] Linux 6.11-rc5+ messages (output of `dmesg`) 0001-fix-iommu-vt-d-Add-helper-to-flush-caches-for-contex.patch |
||
|
Description
Markus Rathgeb
2024-08-26 08:49:04 UTC
Created attachment 306776 [details]
kernel log 6.11.0-0.rc4.38.fc41
Created attachment 306777 [details]
kernel log 6.11.0-0.rc5.43.fc41
Problem still exists with fedora kernel 6.11.0-0.rc5.43
On rc4 the dock has been connected on boot up and I disconnected it and attached the log while reconnect it againn.
On this log the dock has not been connected on boot up. I had to connect it, unplug it and connect it again (first I received an "failed to initial" and no more).
Created attachment 306779 [details]
kernel log 6.11.0-0.rc0.20240716gitd67978318827.2.fc41.x86_64
On Fedora kernel 6.11.0-0.rc0.20240716gitd67978318827.2.fc41.x86_64 USB is still working.
Do you run "powertop --auto-tune" somewhere? Then it might be related to https://lore.kernel.org/all/be791564-ccca-4dd5-915f-aa32b2482817@molgen.mpg.de/ I'm seeing something similar, and powertop doesn't seem to be involved. I also have a Dell laptop - an XPS 13 9315. It's connected to a CalDigit TS3+ Thunderbolt docking station. Connected to the CalDigit are a 4K monitor (connected by USB-C), Ethernet, a USB webcam, USB headset, and a USB keyboard. The laptop has an internal keyboard and trackpad, of course. And I have a Bluetooth external mouse. When I boot kernel 6.9.12 or 6.10.6, all of these work fine more or less immediately after boot, every time. When I boot kernel 6.11 (tried rc3, rc4 and rc5) this is what happens: * At the point where I have to enter the passphrase to decrypt my storage, the USB keyboard always works. * When I reach the login screen - whether GDM or just a tty, I tested boot to multi-user.target and it's the same - nothing works for quite some time. After about 20 seconds, the laptop's internal keyboard and trackpad, and the Bluetooth mouse, start working. But the USB external keyboard never starts working. (I'm not sure of the status of the webcam and headset, I didn't check). I have powertop and power-profiles-daemon installed, but I tried removing both and doing a test boot of 6.11rc5, and the symptoms were exactly the same, nothing changed. I'll attach the journal from an affected 6.11rc5 boot and from a working 6.10 boot. Something I notice is that early in boot we see: Aug 26 11:47:03 xps13a.happyassassin.net kernel: hid-generic 0003:154A:0002.0002: input,hidraw1: USB HID v1.00 Keyboard [ID Innovations Inc. Input Device] on usb-0000:56:00.0-2/input0 but then later, we see: Aug 26 11:47:44 xps13a.happyassassin.net kernel: xhci_hcd 0000:57:00.0: Abort failed to stop command ring: -110 Aug 26 11:47:44 xps13a.happyassassin.net kernel: xhci_hcd 0000:57:00.0: xHCI host controller not responding, assume dead Aug 26 11:47:44 xps13a.happyassassin.net kernel: xhci_hcd 0000:57:00.0: HC died; cleaning up Aug 26 11:47:44 xps13a.happyassassin.net kernel: xhci_hcd 0000:57:00.0: Error while assigning device slot ID: Command Aborted Aug 26 11:47:44 xps13a.happyassassin.net kernel: xhci_hcd 0000:57:00.0: Max number of devices this xHCI host supports is 64. Aug 26 11:47:44 xps13a.happyassassin.net kernel: usb usb9-port1: couldn't allocate usb_device Aug 26 11:47:44 xps13a.happyassassin.net systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully. Aug 26 11:47:44 xps13a.happyassassin.net audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Aug 26 11:47:50 xps13a.happyassassin.net kernel: Bluetooth: hci0: Opcode 0x200e failed: -110 Aug 26 11:48:00 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: Abort failed to stop command ring: -110 Aug 26 11:48:00 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: xHCI host controller not responding, assume dead Aug 26 11:48:00 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: HC died; cleaning up Aug 26 11:48:00 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: Error while assigning device slot ID: Command Aborted Aug 26 11:48:00 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: Max number of devices this xHCI host supports is 32. Aug 26 11:48:00 xps13a.happyassassin.net kernel: usb usb7-port2: couldn't allocate usb_device Aug 26 11:48:00 xps13a.happyassassin.net kernel: usb usb8-port4: couldn't allocate usb_device and after that, we never see "USB HID v1.00 Keyboard" appear again. In contrast, in the 6.10 logs, we see "USB HID v1.00 Keyboard" appear twice, and we never see any "couldn't allocate usb_device" or "Abort failed to stop command ring" errors. I *think* the 're-enumeration' that seems to be happening here (which seems to work fine on 6.10, but lead to problems on 6.11) is a result of thunderbolt.service starting up. Created attachment 306782 [details]
journal from a 6.10.6 boot where the bug doesn't happen
Created attachment 306783 [details]
journal from a 6.11 rc5 boot where the bug does happen
Created attachment 306784 [details]
kernel log 6.11.0-rc1
I build a vanilla kernel 6.11.0-rc1 with the configuration based on the Fedora kernel.
Replugging the dock result into non working dock USB ports, too.
Does a git bisect help you to identify the problematic change(s) I am currently in the progress... $ git bisect log git bisect start # status: waiting for both good and bad commits # bad: [8400291e289ee6b2bf9779ff1c83a291501f017b] Linux 6.11-rc1 git bisect bad 8400291e289ee6b2bf9779ff1c83a291501f017b # status: waiting for good commit(s), bad commit known # good: [7ba498d9d1bb67bcbc2a79f19a9054cdc8b95098] Linux 6.10.6 git bisect good 7ba498d9d1bb67bcbc2a79f19a9054cdc8b95098 # good: [0c3836482481200ead7b416ca80c68a29cfdaabd] Linux 6.10 git bisect good 0c3836482481200ead7b416ca80c68a29cfdaabd # good: [280e36f0d5b997173d014c07484c03a7f7750668] nsfs: use cleanup guard git bisect good 280e36f0d5b997173d014c07484c03a7f7750668 But if you already know what related changes has been done, I could cancel it. Forget the bisect. I currently tested the another commit. I started the laptop without the dock attached. In a Wayland session I opened a terminal to look at the kernel messages. I plugged in the dock. All loooks good. The USB keyboard attached to the dock is working. Before I entered "git bisect good" I had the idee to test again. I disconnected the dock, waited a moment I connected the dock again Now the lines Aug 27 11:51:07 b0v9by3 kernel: DMAR: DRHD: handling fault status reg 2 Aug 27 11:51:07 b0v9by3 kernel: DMAR: [DMA Read NO_PASID] Request device [04:00.0] fault addr 0xffffe000 [fault reason 0x0c] non-zero reserved fields in PTE are part of the kernel log additional the USB keyboard attached to the dock are not recognized again So, we need to disconnect and reconnect the dock at least once to run into the error. I'm not replugging mine, but as I noted, the Thunderbolt service (I forgot it's bolt.service , not thunderbolt.service) is producing a similar effect. I do indeed see similar messages to yours *after* bolt.service starts: Aug 26 11:47:21 xps13a.happyassassin.net systemd[1]: Started bolt.service - Thunderbolt system service. ... Aug 26 11:47:22 xps13a.happyassassin.net kernel: pci 0000:55:00.0: enabling device (0000 -> 0002) Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:55:00.0: xHCI Host Controller Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:55:00.0: new USB bus registered, assigned bus number 5 Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:55:00.0: hcc params 0x200071e9 hci version 0x100 quirks 0x0000000000000010 Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:55:00.0: xHCI Host Controller Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:55:00.0: new USB bus registered, assigned bus number 6 Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:55:00.0: Host supports USB 3.0 SuperSpeed Aug 26 11:47:22 xps13a.happyassassin.net kernel: DMAR: DRHD: handling fault status reg 2 Aug 26 11:47:22 xps13a.happyassassin.net kernel: DMAR: [DMA Read NO_PASID] Request device [55:00.0] fault addr 0xffffb000 [fault reason 0x06] PTE Read access is not set ... Aug 26 11:47:22 xps13a.happyassassin.net kernel: pci 0000:56:00.0: enabling device (0000 -> 0002) Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: xHCI Host Controller Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: new USB bus registered, assigned bus number 7 Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: hcc params 0x200071e9 hci version 0x100 quirks 0x0000000000000010 Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: xHCI Host Controller Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: new USB bus registered, assigned bus number 8 Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:56:00.0: Host supports USB 3.0 SuperSpeed Aug 26 11:47:22 xps13a.happyassassin.net kernel: DMAR: DRHD: handling fault status reg 2 Aug 26 11:47:22 xps13a.happyassassin.net kernel: DMAR: [DMA Read NO_PASID] Request device [56:00.0] fault addr 0xffffb000 [fault reason 0x0c] non-zero reserved fields in PTE ... Aug 26 11:47:22 xps13a.happyassassin.net kernel: pci 0000:57:00.0: enabling device (0000 -> 0002) Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:57:00.0: xHCI Host Controller Aug 26 11:47:22 xps13a.happyassassin.net kernel: xhci_hcd 0000:57:00.0: new USB bus registered, assigned bus number 9 Aug 26 11:47:22 xps13a.happyassassin.net audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=colord comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [snip unrelated messages] Aug 26 11:47:22 xps13a.happyassassin.net kernel: DMAR: DRHD: handling fault status reg 2 Aug 26 11:47:22 xps13a.happyassassin.net kernel: DMAR: [DMA Read NO_PASID] Request device [57:00.0] fault addr 0xffffb000 [fault reason 0x06] PTE Read access is not set And indeed there are no similar messages in my 6.10.6 log. I would guess the thing to focus on here is the "big set of USB and Thunderbolt changes for 6.11-rc1" - commit 04d17331ca33744e1426fdeee7ba5e975c4b2239 in Linus' tree . It had 112 commits. One additional information:
I masked bolt.service (systemctl mask bolt.service) and restarted my system with dock disconnected.
After the system is running (Wayland session) I looked at the kernel messages and connect the dock, disconnect the dock, connect the dock...
The thunderbolt dock itself is detected but no peripheral.
security is set to user
$ cat /sys/bus/thunderbolt/devices/domain0/security
user
I created this udev rule "/etc/udev/rules.d/99-removable.rules"
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"
Reload the rules and added the dock again.
The attached USB keyboard has been detected.
I disconnected the dock and reconnected it again.
I see the DMAR error and no USB device is detect now.
Just to replace bolt with a the simple udev rule and reduce the user space service(s) that are involved.
I did a git checkout aba9753c0677e860f982edff98c7fe5a2b97758c (the commit id before 04d17331ca33744e1426fdeee7ba5e975c4b2239). It seems to trigger the same error. So, I already tried a some different kernel builds / commit IDs and the RCs. They all result into non recognized USB devices. But additional behaviour differs. On some kernels if the error is hit, the system is not usable anymore as the mouse does not react for seconds. Other ones shows kernel dumps, other ones only non working USB... I still try to find the commit / merge that stops USB first. I found the commit that initially break the USB on second connect. [2b989ab9bc89b29dd4b5509408b8fa42337eda56] iommu/vt-d: Add helper to allocate paging domain $ git bisect log git bisect start # status: waiting for both good and bad commits # good: [3d51520954154a476bfdacf9427acd1d9538734c] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma git bisect good 3d51520954154a476bfdacf9427acd1d9538734c # status: waiting for bad commit, 1 good commit known # bad: [aba9753c0677e860f982edff98c7fe5a2b97758c] Merge tag 'tty-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect bad aba9753c0677e860f982edff98c7fe5a2b97758c # bad: [a4f9285520584977127946a22eab2adfbc87d1bf] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux git bisect bad a4f9285520584977127946a22eab2adfbc87d1bf # bad: [f66b07c56119833b88bffa4ecaf9f983834675de] Merge tag 'vfio-v6.11-rc1' of https://github.com/awilliam/linux-vfio git bisect bad f66b07c56119833b88bffa4ecaf9f983834675de # bad: [afd81d914f6fb3e74a46bf5d0dd0b028591ea22e] Merge tag 'dma-mapping-6.11-2024-07-19' of git://git.infradead.org/users/hch/dma-mapping git bisect bad afd81d914f6fb3e74a46bf5d0dd0b028591ea22e # bad: [afd81d914f6fb3e74a46bf5d0dd0b028591ea22e] Merge tag 'dma-mapping-6.11-2024-07-19' of git://git.infradead.org/users/hch/dma-mapping git bisect bad afd81d914f6fb3e74a46bf5d0dd0b028591ea22e # good: [cbf9520823bdd4c44c94b5988e354ee12d57fa58] Merge branch 'iommu/arm/smmu' into iommu/next git bisect good cbf9520823bdd4c44c94b5988e354ee12d57fa58 # bad: [c2b2e5c50330b29804339df4e7adf70e9f19b793] Merge branch 'iommu/core' into iommu/next git bisect bad c2b2e5c50330b29804339df4e7adf70e9f19b793 # bad: [31000732d56b43765d51e08cccb68818fbc0032c] iommu/vt-d: Fix identity map bounds in si_domain_init() git bisect bad 31000732d56b43765d51e08cccb68818fbc0032c # good: [804f98e224e41c16e3b70f97790f84894745a392] iommu/vt-d: Downgrade warning for pre-enabled IR git bisect good 804f98e224e41c16e3b70f97790f84894745a392 # bad: [3753311c9190f833963fb47336dfe17221d93706] iommu/vt-d: Refactor PCI PRI enabling/disabling callbacks git bisect bad 3753311c9190f833963fb47336dfe17221d93706 # bad: [f90584f4beb84211c4d21b319cc13f391fe9f3c2] iommu/vt-d: Add helper to flush caches for context change git bisect bad f90584f4beb84211c4d21b319cc13f391fe9f3c2 Thx Markus. Can I CC you on a mail to the developers? This would expose your email address to the public. Yes, sure. For the record: The laptop I used for testing is a "Dell Precision 5570". The docks I identified the error and tested the kernels: * Dell WD19TB Thunderbolt Dock * Lenovo ThinkPad Thunderbolt 3 Dock Created attachment 306785 [details]
kernel-6.10.0.804f98e224e4+.txt
Here the log of plug-in the dock, unplug it and plug it again for commit 804f98e224e41c16e3b70f97790f84894745a392
It is the commit before the problem occurs, so all fine here.
Created attachment 306786 [details]
kernel-6.10.0.f90584f4beb8+.txt
Here the log of plug-in the dock, unplug it and plug it again for commit f90584f4beb84211c4d21b319cc13f391fe9f3c2
It is the commit that git bisect told me as the problematic one.
Reading the git log, I wonder why git bisect did not try 2b989ab9bc89b29dd4b5509408b8fa42337eda56
For me it seems it is between the good and bad one and not tested.
But the same author, so I assume he can judge better.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #4) > Do you run "powertop --auto-tune" somewhere? Then it might be related to > https://lore.kernel.org/all/be791564-ccca-4dd5-915f-aa32b2482817@molgen.mpg. > de/ (In reply to Markus Rathgeb from comment #15) > I found the commit that initially break the USB on second connect. > > [2b989ab9bc89b29dd4b5509408b8fa42337eda56] iommu/vt-d: Add helper to > allocate paging domain At least with the commit reverted the Dell DA300z adapter still disconnected, so my problem seems to be a *different* one. $ git log --no-decorate --oneline -2 43275d604d974 Revert "iommu/vt-d: Add helper to allocate paging domain" 86987d84b968b Merge tag 'v6.11-rc5-client-fixes' of git://git.samba.org/sfrench/cifs-2.6 $ sudo dmesg [ 0.000000] Linux version 6.11.0-rc5-00058-g43275d604d97 (build@bohemianrhapsody.molgen.mpg.de) (gcc (Debian 13.3.0-2) 13.3.0, GNU ld (GNU Binutils for Debian) 2.42.50.20240710) #289 SMP PREEMPT_DYNAMIC Wed Aug 28 15:29:09 CEST 2024 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.11.0-rc5-00058-g43275d604d97 root=UUID=32e29882-d94d-4a92-9ee4-4d03002bfa29 ro quiet pci=noaer mem_sleep_default=deep log_buf_len=8M cryptomgr.notests […] [ 7951.874589] usb 4-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd [ 7952.369334] r8152-cfgselector 4-1.2: USB disconnect, device number 3 [ 7952.542017] usb 4-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd Paul: do you see the DMAR fault status log messages that I and Markus see? Created attachment 306787 [details] [unrelated] Linux 6.11-rc5+ messages (output of `dmesg`) (In reply to Adam Williamson from comment #23) > Paul: do you see the DMAR fault status log messages that I and Markus see? No, there are *no* such fault status messages. OK, I would say that kinda seems like a different bug then. I resetted the git tree to 2b989ab9bc89, did another build + test. This commit is still a good one. $ git bisect good f90584f4beb84211c4d21b319cc13f391fe9f3c2 is the first bad commit commit f90584f4beb84211c4d21b319cc13f391fe9f3c2 Author: Lu Baolu <baolu.lu@linux.intel.com> Date: Tue Jul 2 21:08:38 2024 +0800 iommu/vt-d: Add helper to flush caches for context change This helper is used to flush the related caches following a change in a context table entry that was previously present. The VT-d specification provides guidance for such invalidations in section 6.5.3.3. This helper replaces the existing open code in the code paths where a present context entry is being torn down. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20240701112317.94022-2-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20240702130839.108139-7-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org> drivers/iommu/intel/iommu.c | 32 +------------------------------- drivers/iommu/intel/iommu.h | 4 ++++ drivers/iommu/intel/pasid.c | 106 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------- 3 files changed, 92 insertions(+), 50 deletions(-) $ git bisect log git bisect start # status: waiting for both good and bad commits # good: [3d51520954154a476bfdacf9427acd1d9538734c] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma git bisect good 3d51520954154a476bfdacf9427acd1d9538734c # status: waiting for bad commit, 1 good commit known # bad: [aba9753c0677e860f982edff98c7fe5a2b97758c] Merge tag 'tty-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect bad aba9753c0677e860f982edff98c7fe5a2b97758c # bad: [a4f9285520584977127946a22eab2adfbc87d1bf] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux git bisect bad a4f9285520584977127946a22eab2adfbc87d1bf # bad: [f66b07c56119833b88bffa4ecaf9f983834675de] Merge tag 'vfio-v6.11-rc1' of https://github.com/awilliam/linux-vfio git bisect bad f66b07c56119833b88bffa4ecaf9f983834675de # bad: [afd81d914f6fb3e74a46bf5d0dd0b028591ea22e] Merge tag 'dma-mapping-6.11-2024-07-19' of git://git.infradead.org/users/hch/dma-mapping git bisect bad afd81d914f6fb3e74a46bf5d0dd0b028591ea22e # bad: [afd81d914f6fb3e74a46bf5d0dd0b028591ea22e] Merge tag 'dma-mapping-6.11-2024-07-19' of git://git.infradead.org/users/hch/dma-mapping git bisect bad afd81d914f6fb3e74a46bf5d0dd0b028591ea22e # good: [cbf9520823bdd4c44c94b5988e354ee12d57fa58] Merge branch 'iommu/arm/smmu' into iommu/next git bisect good cbf9520823bdd4c44c94b5988e354ee12d57fa58 # bad: [c2b2e5c50330b29804339df4e7adf70e9f19b793] Merge branch 'iommu/core' into iommu/next git bisect bad c2b2e5c50330b29804339df4e7adf70e9f19b793 # bad: [31000732d56b43765d51e08cccb68818fbc0032c] iommu/vt-d: Fix identity map bounds in si_domain_init() git bisect bad 31000732d56b43765d51e08cccb68818fbc0032c # good: [804f98e224e41c16e3b70f97790f84894745a392] iommu/vt-d: Downgrade warning for pre-enabled IR git bisect good 804f98e224e41c16e3b70f97790f84894745a392 # bad: [3753311c9190f833963fb47336dfe17221d93706] iommu/vt-d: Refactor PCI PRI enabling/disabling callbacks git bisect bad 3753311c9190f833963fb47336dfe17221d93706 # bad: [f90584f4beb84211c4d21b319cc13f391fe9f3c2] iommu/vt-d: Add helper to flush caches for context change git bisect bad f90584f4beb84211c4d21b319cc13f391fe9f3c2 # good: [2b989ab9bc89b29dd4b5509408b8fa42337eda56] iommu/vt-d: Add helper to allocate paging domain git bisect good 2b989ab9bc89b29dd4b5509408b8fa42337eda56 # first bad commit: [f90584f4beb84211c4d21b319cc13f391fe9f3c2] iommu/vt-d: Add helper to flush caches for context change Created attachment 306788 [details]
0001-fix-iommu-vt-d-Add-helper-to-flush-caches-for-contex.patch
This patch fixed 6.11.rc5 for me.
6.11rc6 (with the patch merged upstream) is good for me too. Thanks a lot. For the record, that seems to be commit 7af6c720417f (iommu/vt-d: Fix incorrect domain ID in context flush helper) [1]. No idea, why neither this bug report URL nor Markus is mentioned in the patch. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7af6c720417f21f015f46baa33e182f349ddc93b Because there was a parallel - actually somewhat earlier - discussion on a mailing list that led to that patch: https://lore.kernel.org/linux-iommu/20240814162726.5efe1a6e.alex.williamson@redhat.com/ . (no, Alex Williamson is not me, though we get each other's email quite a lot. :>) |