Update: root-caused into two separate issues; both now worked around After further testing I can split this report into two distinct problems. The original symptom (keyboard unresponsive at boot / during setup) was one of them; a suspend/resume symptom I hit later was a different one. Apologies for the initial conflation. Hardware: Apple MacBook8,1 (MacBook Retina 12-inch, Early 2015, Broadwell M-5Y51) OS: Ubuntu 24.04.5, kernel 7.0.0-31-generic (7.0.0-31.31~24.04.1) Drivers: spi_pxa2xx_pci (PCI glue) + applespi SPI controller: 0000:00:15.4 (Wildcat Point-LP Serial IO GSPI #1, 8086:9ce6) Serial IO DMA: 0000:00:15.0 (8086:9ce0) ================================================================ ISSUE 1 - boot-time keyboard/trackpad failure (fixed by forcing PIO) This is the symptom that led me to the "disable DMA for SPI transfers" patch (spi: pxa2xx: disable DMA for ..., PATCH v16 5/7). Cause: an init ordering race. spi_pxa2xx_pci comes up and can select DMA before the DesignWare DMA controller is usable, so SPI transfers to the Apple input controller time out and driver state is left corrupted. Relevant log from a failing boot: kernel: dw_dmac_pci 0000:00:15.0: DesignWare DMA Controller, 8 channels kernel: pxa2xx_spi_pci 0000:00:15.4: Forcing PIO mode (disabling DMA) kernel: input: Apple SPI Keyboard as .../spi1/spi-APP000D:00/input/input4 kernel: applespi spi-APP000D:00: Received corrupted packet (crc mismatch) kernel: applespi spi-APP000D:00: modeswitch done. kernel: input: Apple SPI Touchpad as .../spi1/spi-APP000D:00/input/input5 I previously also saw -110 transfer timeouts and list_add double add list corruption on the SPI message queue. Workaround 1a - patched module (what I applied): An out-of-tree/DKMS build of spi_pxa2xx_pci with DMA disabled for this controller (forcing PIO), installed to /lib/modules//updates/ so it shadows the in-tree module. The patch adds a force_pio module parameter plus a DMI match on "Apple Inc." / "MacBook8,1". Since applying it, all boots reach a working keyboard. Workaround 1b - no patched module required (simpler, worth noting): The SPI driver falls back to PIO if no DMA engine is bound. Blacklisting the Serial IO DMA controller alone is enough to avoid the race: /etc/modprobe.d/blacklist-dw-dmac.conf: blacklist dw_dmac_pci With 0000:00:15.0 unbound, even the stock in-tree spi_pxa2xx_pci uses PIO. This holds even if a kernel update breaks the DKMS build, so I now run both. Neither of these is a real fix. The proper fix would be in-tree: either the upstream patch, or ordering the SPI probe after the DMA controller is ready. ================================================================ ISSUE 2 - keyboard unresponsive after suspend (fixed by switching to s2idle) This is a DIFFERENT failure and is NOT addressed by the PIO patch. Suspend mode in use was deep (S3). On suspend the kernel logs the suspend entry and then nothing further - no "PM: suspend exit", no "Restarting tasks": kernel: PM: suspend entry (deep) <nothing further in this boot> The next boot reports an unclean shutdown, i.e. a forced power-off: systemd-journald: File .../system.journal corrupted or uncleanly shut down, renaming and replacing. So on the deep/S3 path this machine never completes the suspend or resume transaction. The display comes back (login screen appears) but the input controller does not, which is what I was observing as "keyboard unresponsive after wake". Switching to s2idle fixes it. Two full suspend/resume cycles, both clean: kernel: PM: suspend entry (s2idle) kernel: Restarting tasks: Starting kernel: Restarting tasks: Done kernel: PM: suspend exit kernel: PM: suspend entry (s2idle) kernel: Restarting tasks: Starting kernel: Restarting tasks: Done kernel: PM: suspend exit No "Failed to re-enable GPE handler" errors from applespi, and both "Apple SPI Keyboard" and "Apple SPI Touchpad" are present and functional after wake. Applied persistently via the kernel command line: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=s2idle" /sys/power/mem_sleep is now [s2idle] deep. ================================================================ SUMMARY The boot-time issue and the post-suspend issue are two separate bugs. The patch referenced in the original report only affects the first. The post-suspend failure looks like a platform/firmware issue with the S3 (deep) suspend path on this Broadwell MacBook8,1, not an applespi bug: the kernel never reaches the applespi resume callbacks at all, so no driver-side fix would have helped. Forcing s2idle is a viable workaround. Suggestion for discussion (not a demand): should the default suspend mode be reconsidered for this platform, e.g. defaulting to s2idle when the DMI identifies Apple MacBook8,1, or blacklisting the deep path? It may affect other Broadwell Apple machines too. I can provide full journal extracts (journalctl -b -2 -k for the deep hang, journalctl -b 0 -k for the working s2idle cycles), lspci -vv -s 00:15.4, dmidecode output, or test patches if useful. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167177 Title: Intermittent SPI keyboard/trackpad failure at boot — DMA/PIO module load order race in spi_pxa2xx_pci Status in linux package in Ubuntu: New Bug description: On a MacBook8,1 (2016 12" MacBook, Intel Broadwell), the internal SPI keyboard and trackpad intermittently fail to initialize at boot. A restart always resolves the issue. The failure is caused by a race between dw_dmac_pci and pxa2xx_spi_pci module probe order. Symptoms: Intermittent: keyboard and trackpad not detected after boot (no input: Apple SPI Keyboard / input: Apple SPI Touchpad in dmesg) Restart always fixes it No external keyboard required to reproduce (it's a boot-time race) Root Cause: The spi_pxa2xx_pci driver checks for DMA channel availability at probe time. The outcome depends on whether dw_dmac_pci has already registered its channels: Good boot: pxa2xx_spi_pci probes first → "no DMA channels available, using PIO" → works Bad boot: dw_dmac_pci probes first → SPI sees DMA → uses DMA → transfers time out (-110) → driver re-queues a message still linked in the SPI core's list → list corruption (__list_add_valid_or_report warning) → driver is permanently stuck Failed boot log (kernel 7.0.0-31-generic): dw_dmac_pci 0000:00:15.0: DesignWare DMA Controller, 8 channels input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:15.4/spi_master/spi1/spi-APP000D:00/input/input4 applespi spi-APP000D:00: SPI transfer timed out applespi spi-APP000D:00: Error writing to device: -110 spi_master spi1: failed to transfer one message from queue applespi spi-APP000D:00: SPI transfer timed out applespi spi-APP000D:00: Error reading from device: -110 WARNING: lib/list_debug.c:35 at __list_add_valid_or_report+0xc6/0xe0, CPU#3: spi1/455 spi_queued_transfer+0xed/0x110 __spi_async+0xd5/0x160 spi_async+0xd6/0xe0 applespi_send_cmd_msg+0x17d/0x400 [applespi] applespi_msg_complete+0xc5/0x110 [applespi] applespi_async_read_complete+0x5c/0x60 [applespi] spi_master spi1: failed to transfer one message from queue applespi spi-APP000D:00: SPI transfer timed out applespi spi-APP000D:00: Error writing to device: -110 Successful boot log (same kernel, same machine): pxa2xx_spi_pci 0000:00:15.4: no DMA channels available, using PIO dw_dmac_pci 0000:00:15.0: DesignWare DMA Controller, 8 channels input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:15.4/spi_master/spi1/spi-APP000D:00/input/input4 applespi spi-APP000D:00: Received corrupted packet (crc mismatch) applespi spi-APP000D:00: modeswitch done. input: Apple SPI Touchpad as /devices/pci0000:00/0000:00:15.4/spi_master/spi1/spi-APP000D:00/input/input5 Upstream Status: The list-corruption bug (re-queueing applespi->wr_m via spi_async() while still linked in SPI core lists) was identified in the sashiko- bot review of the v4/v5 patch series (Shih-Yuan Lee, July 2026, linux- spi mailing list). The same series adds a force_pio module parameter to spi_pxa2xx_pci as a workaround. Workaround (untested, for reference): # /etc/modprobe.d/spi-force-pio.conf options spi_pxa2xx_pci force_pio=1 (Requires the upstream patch to be applied; the parameter does not exist in 7.0.0-31-generic.) System: Ubuntu 24.04.1 LTS Kernel: 7.0.0-31-generic Hardware: MacBook8,1 (Intel Core M, Broadwell) SPI controller: Intel LPSS at 00:15.4 DMA controller: DesignWare at 00:15.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167177/+subscriptions
Комментариев нет:
Отправить комментарий