Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora: https://github.com/Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00
Many thanks,
Jörg Berkel
Hi Jörg
Did you try bisecting the faulty commit? Is is starting from 6.12 or some version above it?
You can also try testing pre-compiled kernels from here:
https://kernel.ubuntu.com/mainline/
or here:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/releases
Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora: https://github.com/Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00
Many thanks,
Jörg Berkel
Ccing Lukas and IOMMU devs
On 5/8/25 01:07, Aditya Garg wrote:
Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Also what does below message mean from a SPI driver's perspective?
"applespispi-APP000D:00: Error writing to device: 01 0e 00 00"
I am asking this because the IOMMU fault messages are about DMA Reads (device raised memory read), while above message complains failing to write to device.
Thanks, baolu
On Thu, May 08, 2025 at 10:15:31AM +0800, Baolu Lu wrote:
On 5/8/25 01:07, Aditya Garg wrote:
Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Also what does below message mean from a SPI driver's perspective?
"applespispi-APP000D:00: Error writing to device: 01 0e 00 00"
I am asking this because the IOMMU fault messages are about DMA Reads (device raised memory read), while above message complains failing to write to device.
When sending a command to the peripheral device applespi expects it to acknowledge successful transfer with
static u8 status_ok[] = { 0xac, 0x27, 0x68, 0xd5 };
but we are getting "01 0e 00 00" instead.
See applespi_check_write_status() in drivers/input/Keyboard/applespi.c
Thanks.
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Also what does below message mean from a SPI driver's perspective?
"applespispi-APP000D:00: Error writing to device: 01 0e 00 00"
I am asking this because the IOMMU fault messages are about DMA Reads (device raised memory read), while above message complains failing to write to device.
When sending a command to the peripheral device applespi expects it to acknowledge successful transfer with
static u8 status_ok[] = { 0xac, 0x27, 0x68, 0xd5 };
but we are getting "01 0e 00 00" instead.
See applespi_check_write_status() in drivers/input/Keyboard/applespi.c
Thanks.
Since its working with `iommu.passthrough=1`, probably disable iommu for this hardware (if possible)?
Although there must be some other fix since it was working without passthrough before.
On 2025-05-08 3:15 am, Baolu Lu wrote:
On 5/8/25 01:07, Aditya Garg wrote:
Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/ Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/ pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Maybe it's retrying the same buffer a few times before finally giving up? The address does look like a plausible iommu-dma IOVA, so I can imagine at least two possibilities where a change in the IOMMU driver might have an impact:
- It's the right address in the right context but incorrectly mapped as DMA_FROM_DEVICE, where that previously had implicit read permission as well but is now write-only (can the Intel 2nd-stage format do that like Arm does? I forget...)
- It's the right address in the wrong context, because the DMA mapping was done with the wrong device, which was previously in the same IOMMU group as 00:1e.3, but now we assign groups differently. I don't know if lpss_spi_setup() is relevant to this particular hardware setup, but "dma_dev = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));" there certainly catches my attention, at least.
The DMA mapping tracepoints should be able to shed light on how that address is mapped prior to the fault.
Also what does below message mean from a SPI driver's perspective?
"applespispi-APP000D:00: Error writing to device: 01 0e 00 00"
I am asking this because the IOMMU fault messages are about DMA Reads (device raised memory read), while above message complains failing to write to device.
AFAICS it's a "write" at the SPI level, i.e. the SPI controller is sending data *to* the SPI device (the keyboard), so at the PCI/platform level the controller itself is fetching that data *from* memory.
Thanks, Robin.
On 8 May 2025, at 5:00 PM, Robin Murphy robin.murphy@arm.com wrote:
On 2025-05-08 3:15 am, Baolu Lu wrote:
On 5/8/25 01:07, Aditya Garg wrote: Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/ Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/ pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Maybe it's retrying the same buffer a few times before finally giving up? The address does look like a plausible iommu-dma IOVA, so I can imagine at least two possibilities where a change in the IOMMU driver might have an impact:
It's the right address in the right context but incorrectly mapped as DMA_FROM_DEVICE, where that previously had implicit read permission as well but is now write-only (can the Intel 2nd-stage format do that like Arm does? I forget...)
It's the right address in the wrong context, because the DMA mapping was done with the wrong device, which was previously in the same IOMMU group as 00:1e.3, but now we assign groups differently. I don't know if lpss_spi_setup() is relevant to this particular hardware setup, but "dma_dev = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));" there certainly catches my attention, at least.
The DMA mapping tracepoints should be able to shed light on how that address is mapped prior to the fault.
A full dmesg with debug log level should be nice to have imo.
Jörg can you do that for both 6.11 and 6.12?
Am 08.05.25 um 14:54 schrieb Aditya Garg:
On 8 May 2025, at 5:00 PM, Robin Murphy robin.murphy@arm.com wrote:
On 2025-05-08 3:15 am, Baolu Lu wrote:
On 5/8/25 01:07, Aditya Garg wrote: Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/ Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/ pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Maybe it's retrying the same buffer a few times before finally giving up? The address does look like a plausible iommu-dma IOVA, so I can imagine at least two possibilities where a change in the IOMMU driver might have an impact:
It's the right address in the right context but incorrectly mapped as DMA_FROM_DEVICE, where that previously had implicit read permission as well but is now write-only (can the Intel 2nd-stage format do that like Arm does? I forget...)
It's the right address in the wrong context, because the DMA mapping was done with the wrong device, which was previously in the same IOMMU group as 00:1e.3, but now we assign groups differently. I don't know if lpss_spi_setup() is relevant to this particular hardware setup, but "dma_dev = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));" there certainly catches my attention, at least.
The DMA mapping tracepoints should be able to shed light on how that address is mapped prior to the fault.
A full dmesg with debug log level should be nice to have imo.
Jörg can you do that for both 6.11 and 6.12?
you'll find attached the two kernel-logfiles created using "systemd.log_level=debug systemd.log_target=kmsg log_buf_len=15M"
Thanks, Jörg
Hi Jörg
Can you test the kernel here to see if this fixes your issue:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200...
Alternatively you can try compiling your own kernel with this patch:
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
________________________________________ From: Berkel Jörg joerg.berkel@bfh.ch Sent: 09 May 2025 20:53 To: Aditya Garg; Robin Murphy Cc: Baolu Lu; linux-input@vger.kernel.org; dmitry.torokhov@gmail.com; stable@vger.kernel.org; regressions@lists.linux.dev; linux-spi@vger.kernel.org; lukas@wunner.de; David Woodhouse; iommu@lists.linux.dev; Joerg Roedel; Will Deacon Subject: Re: [REGRESSION] applespi from 6.12 onwards
Am 08.05.25 um 14:54 schrieb Aditya Garg:
On 8 May 2025, at 5:00 PM, Robin Murphy robin.murphy@arm.com wrote:
On 2025-05-08 3:15 am, Baolu Lu wrote:
On 5/8/25 01:07, Aditya Garg wrote: Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/ Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/ pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Maybe it's retrying the same buffer a few times before finally giving up? The address does look like a plausible iommu-dma IOVA, so I can imagine at least two possibilities where a change in the IOMMU driver might have an impact:
It's the right address in the right context but incorrectly mapped as DMA_FROM_DEVICE, where that previously had implicit read permission as well but is now write-only (can the Intel 2nd-stage format do that like Arm does? I forget...)
It's the right address in the wrong context, because the DMA mapping was done with the wrong device, which was previously in the same IOMMU group as 00:1e.3, but now we assign groups differently. I don't know if lpss_spi_setup() is relevant to this particular hardware setup, but "dma_dev = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));" there certainly catches my attention, at least.
The DMA mapping tracepoints should be able to shed light on how that address is mapped prior to the fault.
A full dmesg with debug log level should be nice to have imo.
Jörg can you do that for both 6.11 and 6.12?
you'll find attached the two kernel-logfiles created using "systemd.log_level=debug systemd.log_target=kmsg log_buf_len=15M"
Thanks, Jörg
Hi
I'm also experiencing this problem on my MacBookPro14,3.
Aditya Garg wrote:
Hi Jörg
Can you test the kernel here to see if this fixes your issue:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200...
Alternatively you can try compiling your own kernel with this patch:
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
As far as I have tried, this patch did not solve the problem.
By bisecting, I found that this problem was introduced by commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain"). In fact, since this commit, it will panic at startup. This panic was fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices"). So I applied commit 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard and touchpad is not working.
I also found that I can workaround this problem by reverting only the intel_iommu_attach_device() change in commit 2031c469f816 as in the attached patch, but I'm not sure if this is a reasonable fix.
On 5/11/25 21:31, kobarity wrote:
Hi
I'm also experiencing this problem on my MacBookPro14,3.
Aditya Garg wrote:
Hi Jörg
Can you test the kernel here to see if this fixes your issue:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200...
Alternatively you can try compiling your own kernel with this patch:
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
As far as I have tried, this patch did not solve the problem.
By bisecting, I found that this problem was introduced by commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain"). In fact, since this commit, it will panic at startup. This panic was fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices"). So I applied commit 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard and touchpad is not working.
Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device comparison in context_setup_pass_through_cb")?
I also found that I can workaround this problem by reverting only the intel_iommu_attach_device() change in commit 2031c469f816 as in the attached patch, but I'm not sure if this is a reasonable fix.
Thanks, baolu
Baolu Lu wrote:
On 5/11/25 21:31, kobarity wrote:
Hi
I'm also experiencing this problem on my MacBookPro14,3.
Aditya Garg wrote:
Hi Jörg
Can you test the kernel here to see if this fixes your issue:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200...
Alternatively you can try compiling your own kernel with this patch:
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
As far as I have tried, this patch did not solve the problem.
By bisecting, I found that this problem was introduced by commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain"). In fact, since this commit, it will panic at startup. This panic was fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices"). So I applied commit 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard and touchpad is not working.
Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device comparison in context_setup_pass_through_cb")?
Yes, I tried it on yesterday's master branch, including commit 64f792981e35.
- Keyboard/Touchpad NOT working: - No patches - With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia... - Keyboard/Touchpad working: - With my workaround patch
On 5/12/25 20:16, kobarity wrote:
Baolu Lu wrote:
On 5/11/25 21:31, kobarity wrote:
Hi
I'm also experiencing this problem on my MacBookPro14,3.
Aditya Garg wrote:
Hi Jörg
Can you test the kernel here to see if this fixes your issue:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200...
Alternatively you can try compiling your own kernel with this patch:
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
As far as I have tried, this patch did not solve the problem.
By bisecting, I found that this problem was introduced by commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain"). In fact, since this commit, it will panic at startup. This panic was fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices"). So I applied commit 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard and touchpad is not working.
Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device comparison in context_setup_pass_through_cb")?
Yes, I tried it on yesterday's master branch, including commit 64f792981e35.
- Keyboard/Touchpad NOT working:
- No patches
- With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
- Keyboard/Touchpad working:
- With my workaround patch
Okay, thanks! Can you please try below change? I also attached a diff file in the attachment for your convenience.
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 49530d5d8c85..9a86ead8377d 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1832,6 +1832,8 @@ static int dmar_domain_attach_device(struct dmar_domain *domain, if (ret) goto out_block_translation;
+ info->domain_attached = true; + return 0;
out_block_translation: @@ -3206,6 +3208,10 @@ void device_block_translation(struct device *dev) struct intel_iommu *iommu = info->iommu; unsigned long flags;
+ /* Device in DMA blocking state. Noting to do. */ + if (!info->domain_attached) + return; + if (info->domain) cache_tag_unassign_domain(info->domain, dev, IOMMU_NO_PASID);
@@ -4302,6 +4308,9 @@ static int identity_domain_attach_dev(struct iommu_domain *domain, struct device else ret = device_setup_pass_through(dev);
+ if (!ret) + info->domain_attached = true; + return ret; }
diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index cbfb8bb4c94a..3ddbcc603de2 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -774,6 +774,7 @@ struct device_domain_info { u8 ats_supported:1; u8 ats_enabled:1; u8 dtlb_extra_inval:1; /* Quirk for devices need extra flush */ + u8 domain_attached:1; /* Device has domain attached */ u8 ats_qdep; unsigned int iopf_refcount; struct device *dev; /* it's NULL for PCIe-to-PCI bridge */
Thanks, baolu
Baolu Lu wrote:
On 5/12/25 20:16, kobarity wrote:
Baolu Lu wrote:
On 5/11/25 21:31, kobarity wrote:
Hi
I'm also experiencing this problem on my MacBookPro14,3.
Aditya Garg wrote:
Hi Jörg
Can you test the kernel here to see if this fixes your issue:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200...
Alternatively you can try compiling your own kernel with this patch:
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
As far as I have tried, this patch did not solve the problem.
By bisecting, I found that this problem was introduced by commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain"). In fact, since this commit, it will panic at startup. This panic was fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices"). So I applied commit 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard and touchpad is not working.
Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device comparison in context_setup_pass_through_cb")?
Yes, I tried it on yesterday's master branch, including commit 64f792981e35.
- Keyboard/Touchpad NOT working:
- No patches
- With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
- Keyboard/Touchpad working:
- With my workaround patch
Okay, thanks! Can you please try below change? I also attached a diff file in the attachment for your convenience.
Thanks! The keyboard and touchpad now work with this patch. I tested it with the same master branch as before (commit 3ce9925823c7).
On 5/13/25 20:08, kobarity wrote:
Baolu Lu wrote:
On 5/12/25 20:16, kobarity wrote:
Baolu Lu wrote:
On 5/11/25 21:31, kobarity wrote:
Hi
I'm also experiencing this problem on my MacBookPro14,3.
Aditya Garg wrote:
Hi Jörg
Can you test the kernel here to see if this fixes your issue:
https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/actions/runs/14944200...
Alternatively you can try compiling your own kernel with this patch:
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
As far as I have tried, this patch did not solve the problem.
By bisecting, I found that this problem was introduced by commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain"). In fact, since this commit, it will panic at startup. This panic was fixed by commit 6e02a277f1db ("iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices"). So I applied commit 6e02a277f1db on commit 2031c469f816 and confirmed that the keyboard and touchpad is not working.
Have you tried to apply commit 64f792981e35 ("iommu/vt-d: Remove device comparison in context_setup_pass_through_cb")?
Yes, I tried it on yesterday's master branch, including commit 64f792981e35.
- Keyboard/Touchpad NOT working:
- No patches
- With patch in https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
- Keyboard/Touchpad working:
- With my workaround patch
Okay, thanks! Can you please try below change? I also attached a diff file in the attachment for your convenience.
Thanks! The keyboard and touchpad now work with this patch. I tested it with the same master branch as before (commit 3ce9925823c7).
Okay, thanks! Let me post a formal fix patch for this.
Thanks, baolu
On 5/8/25 19:29, Robin Murphy wrote:
On 2025-05-08 3:15 am, Baolu Lu wrote:
On 5/8/25 01:07, Aditya Garg wrote:
Keyboard and touchpad stopped working on several Apple Macbooks from the year 2017 using kernel 6.12.xx . Until now I could only find this discussion affirming the bug on Debian and Fedora:https://github.com/ Dunedan/mbp-2016-linux/issues/202
On siduction I also tried the more recent kernels 6.14.5 and mainline 6.15-rc4 (from Ubuntu) and the issue persisted with my testdevice MacBookPro14,1 -- see the relevant output:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/ pci0000:00/0000:00:1e.3/ pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/ input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespispi-APP000D:00: Error writing to device: 01 0e 00 00
It appears that all DMA faults are related to a fixed address, 0xffffa000. Is this address something special?
Maybe it's retrying the same buffer a few times before finally giving up? The address does look like a plausible iommu-dma IOVA, so I can imagine at least two possibilities where a change in the IOMMU driver might have an impact:
- It's the right address in the right context but incorrectly mapped as
DMA_FROM_DEVICE, where that previously had implicit read permission as well but is now write-only (can the Intel 2nd-stage format do that like Arm does? I forget...)
Intel 2nd-stage page table format allows write-only permission. But commit eea53c581688 ("iommu/vt-d: Remove WO permissions on second-level paging entries") has already removed it, and v6.12 kernel contains this commit.
By the way, we are about to restore the write-only permission on 2nd- stage page table,
https://lore.kernel.org/all/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia...
... if the device driver provides only DMA_FROM_DEVICE and the iommu driver uses 2nd-stage page table for its dma translation.
The iommu driver currently treats DMA_FROM_DEVICE as a hint rather than a mandatory requirement. If we want to enforce write-only permission in the future, we should allocate a domain allocation flag so that the iommu driver could have the opportunity to select the appropriate page table format.
- It's the right address in the wrong context, because the DMA mapping
was done with the wrong device, which was previously in the same IOMMU group as 00:1e.3, but now we assign groups differently. I don't know if lpss_spi_setup() is relevant to this particular hardware setup, but "dma_dev = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));" there certainly catches my attention, at least.
The DMA mapping tracepoints should be able to shed light on how that address is mapped prior to the fault.
Yes. DMA mapping trace messages would shed more lights.
Thanks, baolu
linux-stable-mirror@lists.linaro.org
-
Aditya Garg -
Baolu Lu -
Berkel Jörg -
Dmitry Torokhov -
kobarity -
Robin Murphy