You are not logged in.
SOLUTION:
1. Open /usr/lib/initcpio/install/block
sudo nano /usr/lib/initcpio/install/block2. Find add_checked_modules '/drivers/mfd/' and comment out it.
# nvdimm
add_checked_modules '/drivers/nvdimm/'
# pci controller
add_checked_modules '/drivers/pci/controller/'
# low-level drivers for certain pci/usb controllers
add_checked_modules '/drivers/mfd/' # <-- COMMENT THIS
add_checked_modules '/drivers/clk/'
add_checked_modules '/drivers/phy/'
}3. Rebuild mkinitcpio:
sudo mkinitcpio -P4. Reboot system
=====
Hello Arch community,
I'm documenting a persistent touchpad issue on my AVITA AM15A2IN laptop that requires resolution. The SYNA3602 touchpad was fully functional on Arch Linux, but stopped working entirely after a system update performed in November 2025. I will resolve this issue, but wanted to share technical details for community insight.
Hardware and current setup:
Laptop: AVITA AM15A2IN
Touchpad: SYNA3602 (identified from previous dmesg logs)
BIOS: EM_IDL819_S_SUB26_V1.0.5 (07/24/2023)
Current OS: CachyOS (kernel 6.18.2-2-cachyos) - I prefer to remain on CachyOS due to its Arch compatibility and performance benefits
Environment: Wayland only (GNOME and Hyprland), no Xorg
Issue timeline:
Touchpad worked perfectly on clean Arch Linux installation
In November 2025, I performed a routine system update (`pacman -Syu`)
Immediately after the November update, the touchpad completely disappeared from system detection
Both LTS kernel and latest kernels exhibit the same failure
Complete Arch reinstall did not resolve the issue
Migration to CachyOS also fails to detect the touchpad
Both GNOME and Hyprland environments show identical behavior
Critical system logs show multiple failures:
[ 8.220253] intel-hid INTC1070:00: failed to enable HID power button
[ 8.220984] irq 27: nobody cared (try booting with the "irqpoll" option)
[ 8.221050] Disabling IRQ #27
[ 8.256627] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.LPCB.HEC.TSR1], AE_NOT_FOUND
[ 8.256637] ACPI Error: Aborting method \_SB.PC00.LPCB.H_EC.SEN1._TMP due to previous error (AE_NOT_FOUND)Device detection status:
`libinput list-devices` shows no touchpad device at all. The system detects standard input devices (keyboard, power buttons, lid switch, Bluetooth mouse) but completely fails to recognize the touchpad hardware.
What works:
The touchpad functions perfectly when booted from an MX Linux live USB environment, confirming this is not a hardware failure but a software/driver issue specific to Arch-based systems.
Troubleshooting performed:
Tested kernel parameters: `i2c_hid.acpi_quirks=1`, `module_blacklist=i2c_hid_acpi`, `acpi_osi=Linux` with `acpi_enforce_resources=lax` and `irqpoll`
Blacklisted problematic modules (`i2c_hid_acpi`, `intel_ishtp_hid`) in modprobe configuration
Verified all firmware packages are properly installed
This appears to be a regression introduced specifically in the November 2025 update that affects touchpad detection for this hardware configuration. The contrast between working MX Linux live environment and failing installed Arch/CachyOS systems suggests differences in driver loading sequence, module dependencies, or ACPI handling.
I will continue working toward a solution and will document the resolution once found. Full system logs and diagnostic outputs are available upon request.
Last edited by ng-link (2025-12-30 08:26:13)
Offline
Good report, thanks for the detailed logs
given that the touchpad works on MX Linux and also works after a manual modprobe i2c_hid, this suggests a possible upstream regression in I²C-HID / ACPI initialization order rather than a firmware or hardware failure.
A few points that may help narrow it down:
The irq 27: nobody cared message followed by IRQ disable looks significant. Once that IRQ is disabled, the touchpad would no longer be able to generate events, which could indicate a regression in IRQ routing or ACPI resource handling.
intel-hid has been known to interfere with I²C devices on some systems. It may be worth testing with:
module_blacklist=intel-hid,intel_ishtp_hid
while leaving i2c_hid_acpi enabled.
Since manual module reload works, another thing to test is forcing early loading via initramfs:
MODULES=(i2c_hid i2c_hid_acpi hid_multitouch)
followed by mkinitcpio -P.
For testing purposes only, it might also be useful to try:
pci=nomsi
or
acpi=noirq
If either restores the touchpad consistently, that would further point toward an IRQ/ACPI-related issue.
MX Linux may be carrying downstream ACPI quirks that Arch does not. If the last known-working kernel prior to Nov 2025 can be identified, this may be a good candidate for upstream reporting (ACPI / i2c-hid).
If you’re able to share acpidump output and the MX Linux kernel version, it could help narrow this down further.
Last edited by 5hridhyan (2026-01-01 06:52:31)
I expect some mercy from my fellow humans! ^^
Keep your virtue sharpened in a kingdom of carrion, and the throne they offer will be built from your ribs.
Offline
This is a support forum, new threads are expected to be [unsolved] , please remove it from the title (edit first post).
Current OS: CachyOS (kernel 6.18.2-2-cachyos) - I prefer to remain on CachyOS due to its Arch compatibility and performance benefits
If you stick to that, this thread will be dustbinned as we can only help with troubleshooting archlinux systems.
What was the kernel version used before that november update ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
https://pastebin.com/c4eDtrjz DMESG LOGS
https://pastebin.com/qWFfhirB JOURNALCTL LOGS
Offline
This is a support forum, new threads are expected to be [unsolved] , please remove it from the title (edit first post).
removed.
If you stick to that, this thread will be dustbinned as we can only help with troubleshooting archlinux systems.
i meant that i don't want to use distros that aren't based on arch
What was the kernel version used before that november update ?
the laptop was not updated for a long time (about six months), I don’t remember the exact version on which it worked
Offline
Good report, thanks for the detailed logs.
Given that the touchpad works on MX Linux and also works after a manual modprobe i2c_hid, this suggests a possible upstream regression in I²C-HID / ACPI initialization order rather than a firmware or hardware failure.
A few points that may help narrow it down:
The irq 27: nobody cared message followed by IRQ disable looks significant. Once that IRQ is disabled, the touchpad would no longer be able to generate events, which could indicate a regression in IRQ routing or ACPI resource handling.
intel-hid has been known to interfere with I²C devices on some systems. It may be worth testing with:
module_blacklist=intel-hid,intel_ishtp_hid
while leaving i2c_hid_acpi enabled.
Since manual module reload works, another thing to test is forcing early loading via initramfs:
MODULES=(i2c_hid i2c_hid_acpi hid_multitouch)
followed by mkinitcpio -P.
For testing purposes only, it might also be useful to try:
pci=nomsi
or
acpi=noirq
If either restores the touchpad consistently, that would further point toward an IRQ/ACPI-related issue.
MX Linux may be carrying downstream ACPI quirks that Arch does not. If the last known-working kernel prior to Nov 2025 can be identified, this may be a good candidate for upstream reporting (ACPI / i2c-hid).
If you’re able to share acpidump output and the MX Linux kernel version, it could help narrow this down further.
Sorry for misleading you, there used to be a problem with the touchpad turning off and reloading the kernel modules helped. i'll fix post.
also i will try everything you suggest
Offline
@ng-link Thank you for sharing the dmesg and journalctl logs.
I just realized this is the Arch Linux forum, so I won’t be able to help troubleshoot CachyOS directly.
If you can reproduce the issue on Arch Linux itself and share the corresponding logs, I (or others here) can help debug further.
Last edited by 5hridhyan (2025-12-31 19:19:33)
I expect some mercy from my fellow humans! ^^
Keep your virtue sharpened in a kingdom of carrion, and the throne they offer will be built from your ribs.
Offline
@ng-link Thank you for sharing the dmesg and journalctl logs.
I just realized this is the Arch Linux forum, so I won’t be able to help troubleshoot CachyOS directly.
If you can reproduce the issue on Arch Linux itself and share the corresponding logs, I (or others here) can help debug further.
I had the same problem on Arch Linux, I tried changing it to Cachy Os, but it didn't help. I'll try to get logs from Arch Linux.
Offline
I saw a similar issue after updating mkinitcpio on my IdeaPad laptop. I documented a potential workaround in mkinitcpio and sent a bug report to the kernel regressions mailing list:
- https://gitlab.archlinux.org/archlinux/ … issues/295
- https://lore.kernel.org/regressions/513 … l.com/T/#u
If that workaround doesn't help, there may be a different touchpad regression:
- https://lore.kernel.org/regressions/2c8 … .info/T/#u
- https://discuss.cachyos.org/t/touchpad- … date/18348
Here are other similar reports:
- https://bbs.archlinux.org/viewtopic.php?id=310589
- https://bbs.archlinux.org/viewtopic.php?id=310946
Offline
@ng-link
You don't have to remember your previous kernel before update - you can get it from log: /var/log/pacman.log.
What is the kernel version in MX Linux live USB?
https://lkml.org/lkml/2025/11/28/306 suggest changes in 6.17.7 kernel (6.17.6 and previous was working), but it would be nice if you would post your previous working kernel version and MX Linux live USB kernel version.
Last edited by xerxes_ (2025-12-29 21:13:11)
Offline
@ng-link
You don't have to remember your previous kernel before update - you can get it from log: /var/log/pacman.log.
What is the kernel version in MX Linux live USB?https://lkml.org/lkml/2025/11/28/306 suggest changes in 6.17.7 kernel (6.17.6 and previous was working), but it would be nice if you would post your previous working kernel version and MX Linux live USB kernel version.
i couldn't find a flash drive with MX, but i tested touchpad on Tails 6.19 (6.1.0-38-amd64 Debian 6.1.147 (2025-08-02)) and it worked perfectly.
i will try to install 6.17.6 kernel and test it
in an attempt to fix the problem i have reinstalled the system, but as far as I remember, then it was updated higher than the version of kernel that has the problem
Offline
@xerxes_ I booted from Linux kernel 6,17,6, the problem remains. LOG: https://pastebin.com/pw49Gcf3
Last edited by ng-link (2025-12-30 07:21:15)
Offline
I the problem appeared along with the IRQ nobody carried error.
Offline
@xerxes_
i have found flash drive with MX Linux (23.2) and booted into it.
Touchpad worked perfectly.
SysInfo: Linux mx1 6.14.2-1-liquorix-amd64 #1 ZEN SMP PREEMPT_DYNAMIC liquorix 6.14-3~mx23ahs
LOGS: https://pastebin.com/pLiMcLyc
Offline
@correctmost
thank you, the problem is solved as in workaround.
SOLUTION:
1. Open /usr/lib/initcpio/install/block
sudo nano /usr/lib/initcpio/install/block2. Find add_checked_modules '/drivers/mfd/' and comment out it.
# nvdimm
add_checked_modules '/drivers/nvdimm/'
# pci controller
add_checked_modules '/drivers/pci/controller/'
# low-level drivers for certain pci/usb controllers
add_checked_modules '/drivers/mfd/' # <-- COMMENT THIS
add_checked_modules '/drivers/clk/'
add_checked_modules '/drivers/phy/'
}3. Rebuild mkinitcpio:
sudo mkinitcpio -P4. Reboot system
Offline