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?