Issue Description:
Immediately following the system update to kernel 6.8.0-101-generic, the system experiences massive, persistent CPU throttling, with total usage sitting at 90-100% on idle. This results in severe UI lag and system stuttering.
Diagnostics & Root Cause:
Initial inspection of user processes via gnome-system-monitor showed normal resource consumption, but a deeper check of all system processes via top revealed multiple hardware interrupt storms completely saturating the CPU.
The two primary offending threads are:
irq/51-SYN1B7F:00 (Synaptics Touchpad) - Fluctuating heavily, often consuming 40-70% CPU.
irq/138-iwlwifi (Intel Wi-Fi) - Spiking up to 80% CPU.
Additionally, the touchegg process spikes up to 51% CPU when physical mouse movement wakes the input subsystem, as it struggles to process the massive backlog of bogus interrupt data generated by the failing touchpad driver.
Testing & Verification:
Hardware Failure Ruled Out: Booted into a dual-boot Windows partition. The system runs flawlessly at idle with no thermal throttling or lag. Windows Fast Startup is disabled.
Driver Isolation: Running sudo modprobe -r i2c_hid_acpi i2c_hid temporarily stops the irq/51 interrupt storm and drops CPU usage, confirming the driver/kernel mismatch.
Workaround: Rebooting the system and explicitly selecting the older 6.8.0-90-generic kernel from the GRUB menu instantly resolves all issues. CPU returns to normal idle levels, and both the touchpad and Wi-Fi function properly without generating interrupt storms.
Conclusion:
Kernel 6.8.0-101-generic appears to have introduced a regression regarding IRQ routing or power management specifically affecting the motherboard/hardware configuration of the Acer Swift SF314-54-34GJ. I am currently locked on kernel 6.8.0-90-generic as a workaround until this is patched.
As a "Bug Report" I have moved this to Feedback section.
If there is a fix for it other than a subsequent linux kernel update, then maybe can be moved back to a Help section.
FWIW I have kernel 6.8.0-101 on a antique 2 core laptop running Z17.3 Core and it seems OK. Must be something with Acer.
Did you have to go all the way back to 6.8.0-90 kernel to correct the issue?
I mean did you try 6.8.0-100 if you have it?
Having searched for your issue a lot of results came back with pre-2020 issues using your thread heading in the search so looked up Brave A.I. which may be irrelevant as it looks at Acer Chromebooks:
" Interrupt storms in Linux kernels like 6.8.0-101-generic on systems such as the Acer Swift SF314-54-34GJ typically stem from hardware-level issues, misconfigured drivers, or firmware (BIOS/coreboot) settings causing spurious interrupts on specific IRQ lines (e.g., irq10 , irq16 , irq17 ). These storms flood the CPU with interrupt requests, leading to severe CPU throttling and system slowdowns.
Root Causes & Diagnostics
Spurious GPIO/ACPI interrupts : On Intel Cherry View (chv-gpio) platforms, misconfigured GPIO pins (e.g., GPIO_DFX_8 on INT33FF:00 ) can trigger interrupts without proper handler mapping. Logs show No irq mapping found and Disabling chained interrupt line , indicating the kernel cannot resolve the interrupt source.
ACPI/EC-based storms : On older systems (like the Acer TravelMate 4021WLCi), ACPI events (e.g., lid close) can trigger infinite interrupt loops if action scripts or DSDT tables are misconfigured. While less likely on newer models, similar issues can occur with EC or power management.
Unassigned or shared IRQs : An unconfigured device sharing an IRQ with a functional device can generate interrupts that go unhandled, causing the kernel to repeatedly process them (as seen in FreeBSD forums).
Network interface issues : In some cases, NICs (e.g., ste0 on irq16 ) can cause storms if the driver fails to properly acknowledge interrupts.
High, rapidly increasing counts on any line (especially 0) indicate a storm.
2. Use vmstat -i :
vmstat -i
Identify which device (e.g., ste0 , atapci0 , chv-gpio ) is responsible.
3. Apply Kernel Workarounds (if applicable) :
For Cherry View (Intel) platforms, apply patches that mask unhandled interrupt lines (e.g., chv-gpio driver fixes).
Add kernel boot parameters:
acpi_sci=low – reduces ACPI interrupt frequency.
noapic – disables APIC (may help if routing is broken).
irqpoll – forces polling instead of interrupts (diagnostic only).
BIOS/UEFI Settings :
Disable unused devices (e.g., audio, Bluetooth, unused USB controllers).
Disable "Interrupt Swizzling" or "PCI Express IRQ Sharing" if available.
Update BIOS to the latest version (Acer may have fixed interrupt routing).
Driver/Device-Specific Fixes :
If chv-gpio is involved, ensure coreboot/firmware disables interrupt triggers on unused pins (e.g., GPI(trig_edge_low, L5, NA, non_maskable, ...) ).
For network devices, check driver compatibility with kernel 6.8.0.
Temporary Workaround :
Use cpuset to isolate the problematic IRQ to a single CPU core:
cpuset -l 3 -x 256 # Example: move irq256 to CPU 3
Or increase HZ to 2000+ in kernel config to reduce interrupt latency.
Long-Term Resolution
Report to kernel maintainers : If the issue is due to a driver bug (e.g., chv-gpio ), submit logs and patches to the Linux kernel mailing list.
Firmware fix : Contact Acer for BIOS updates that disable unnecessary interrupt triggers on GPIOs.
Avoid irq10 /irq16 conflicts : These are often used by audio or network devices—disable them in BIOS if unused.
Note : The 6.8.0-101-generic kernel is likely from Ubuntu 24.04 LTS. Check for updates via sudo apt update && sudo apt upgrade . If the issue persists, consider testing a newer kernel version or disabling CONFIG_IRQ_FORCED_THREADING if it's causing thrashing.
If logs show interrupt storm detected on "irq10:" or cherryview-pinctrl , the GPIO misconfiguration is the most probable root cause. Focus on firmware and driver fixes for chv-gpio .
Hi, thanks for taking the time to search for a solution and welcoming me to the forum!
Unfortunately, that AI-generated response is pulling in a lot of hallucinated and highly outdated information that doesn't apply to this specific hardware regression.
Just to clarify for anyone else looking into this:
The AI is referencing Intel Cherry View platforms (Atom processors) and Windows XP-era TravelMates. My specific machine is an Acer Swift SF314-54-34GJ, which runs on an Intel Core i3-7020U (Kaby Lake architecture).
It suggests FreeBSD commands like cpuset which obviously don't apply here.
It completely ignored the actual hardware interrupts I isolated in my diagnostics (irq/51-SYN1B7F:00 and irq/138-iwlwifi), instead guessing random IRQs like 10, 16, and 17.
I'm definitely going to avoid throwing legacy, system-breaking boot parameters like noapic or acpi_sci=low at this machine, as that's a practical way to cause a boot loop.
Since I've already isolated the exact Zorin OS kernel update (6.8.0-101-generic) that caused the i2c_hid and iwlwifi drivers to start generating interrupt storms, I am just going to stay rolled back on the stable 6.8.0-90-generic kernel for now.
I'll leave this thread open for the Zorin devs/maintainers so they are aware of the specific hardware regression on the SF314-54 line. If the team needs me to pull any specific logs or test a future patch, just let me know!
To answer your question: I didn't skip 6.8.0-100 on purpose. I checked my /boot directory, and my system only had 101 and 90 installed. The Zorin update manager jumped me straight from 90 to 101, so rolling back to 6.8.0-90 was my only available fallback option.
Your note about 101 running fine on your older laptop makes perfect sense and practically confirms my suspicion. This isn't a universally broken kernel; it's a hardware-specific regression regarding IRQ/ACPI routing that specifically breaks the touchpad (i2c_hid) and Wi-Fi (iwlwifi) on the Acer Swift SF314-54-34GJ motherboard.
I'll stay parked on the 90 kernel for now so I can actually use my machine. If you or the dev team need me to pull dmesg logs or test anything specific to get this hardware profile patched in a future update, just let me know.
I just pulled down the new 6.8.0-106-generic kernel update today, and I can confirm it completely resolves the lagging issue on my Acer Swift SF314-54.
After doing a full cold boot, the system initially lagged for a few minutes while packagekitd and the background update processes finished compiling everything. Once that cleared, the system stabilized perfectly.
I verified with top that the irq/51-SYN1B7F:00 (touchpad) and irq/138-iwlwifi (Wi-Fi) hardware interrupt storms are completely gone. CPU usage is back down to a normal resting idle, and both devices are functioning flawlessly.
@Steve - thanks again for the intel_pstate suggestion! Thankfully, this official kernel patch fixed the underlying ACPI/IRQ routing bug, so no GRUB boot parameter workarounds are needed after all.
Marking this issue as resolved. Thanks to everyone for the help!
As new kernel update to 6.8.0-106 did the trick. I will move this to General Help and mark your last post as Solution (we can't do that in the Feedback section).
EDIT: I marked wrong post as solution yesterday. Now corrected. Zab
Note : The 
Solution (we can't do that in the Feedback section).