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 a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167177
Title:
Intermittent SPI keyboard/trackpad failure at boot — DMA/PIO module
load order race in spi_pxa2xx_pci
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167177/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
