2

I have an issue with the touchpad on my notebook where if I use it, it causes a high amount of interrupts which results in significantly higher CPU usage and power drain. The following snippet is after 5 minutes of powering the device on. Notice the amount of interrupts on IRQ 17 in comparison to the rest.

cat /proc/interrupts
            CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
   0:          8          0          0          0          0          0          0          0  IR-IO-APIC    2-edge      timer
   1:          0          0          0          0          0          0          0       1350  IR-IO-APIC    1-edge      i8042
   8:          0          1          0          0          0          0          0          0  IR-IO-APIC    8-edge      rtc0
   9:          0         31          0          0          0          0          0          0  IR-IO-APIC    9-fasteoi   acpi
  14:          0          0      14671          0          0          0          0          0  IR-IO-APIC   14-fasteoi   INT344B:00
  16:          0          0          0       6167          0          0          0          0  IR-IO-APIC   16-fasteoi   i801_smbus, idma64.0, i2c_designware.0
  17:          0          0          0          0     604999          0          0          0  IR-IO-APIC   17-fasteoi   idma64.1, i2c_designware.1
  20:          0          0          0          0          0          0          0          0  IR-IO-APIC   20-fasteoi   idma64.2
  23:          0          0          0          0          0          0          0          0  IR-IO-APIC   23-fasteoi   idma64.3, pxa2xx-spi.3
 120:          0          0          0          0          0          0          0          0  DMAR-MSI    0-edge      dmar0
 121:          0          0          0          0          0          0          0          0  DMAR-MSI    1-edge      dmar1

In threads with similar issues it was recommended to blacklist i2c_designware or intel_lpss_pci but neither helped in my case. Using the kernel parameter initcall_blacklist=dw_i2c_init_driver as recommended here lead to my touchpad not being recognized at all anymore. There also is no BIOS parameter or something similar to switch trackpad modes. Is there anything else I can try or am I stuck with using my mouse until this is fixed in the kernel?

cat /proc/bus/input/devices | grep i2c -B2 -A7
I: Bus=0018 Vendor=06cb Product=19ac Version=0100
N: Name="SYNA2393:00 06CB:19AC"
P: Phys=i2c-SYNA2393:00
S: Sysfs=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-SYNA2393:00/0018:06CB:19AC.0001/input/input23
U: Uniq=
H: Handlers=mouse0 event8 
B: PROP=2
B: EV=1b
B: KEY=400 0 0 0 0 0
B: ABS=260800000000003
B: MSC=20
--
I: Bus=0018 Vendor=06cb Product=cd48 Version=0100
N: Name="SYNA1D31:00 06CB:CD48 Mouse"
P: Phys=i2c-SYNA1D31:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-SYNA1D31:00/0018:06CB:CD48.0002/input/input27
U: Uniq=
H: Handlers=mouse1 event9 
B: PROP=0
B: EV=17
B: KEY=30000 0 0 0 0
B: REL=3
B: MSC=10
--
I: Bus=0018 Vendor=06cb Product=cd48 Version=0100
N: Name="SYNA1D31:00 06CB:CD48 Touchpad"
P: Phys=i2c-SYNA1D31:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-SYNA1D31:00/0018:06CB:CD48.0002/input/input28
U: Uniq=
H: Handlers=mouse2 event10 
B: PROP=5
B: EV=1b
B: KEY=e520 10000 0 0 0 0
B: ABS=2e0800000000003
B: MSC=20
lspci -nnkv | grep 'IRQ 17' -B3 -A4

00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
    Subsystem: Huawei Technologies Co., Ltd. Sunrise Point-LP Serial IO I2C Controller [19e5:3e04]
    Flags: bus master, fast devsel, latency 0, IRQ 17
    Memory at 2ff3020000 (64-bit, non-prefetchable) [size=4K]
    Capabilities: <access denied>
    Kernel driver in use: intel-lpss
    Kernel modules: intel_lpss_pci

4 Answers 4

0

I'm encountering the same issue on my laptop for a few years. I noticed it because the CPU was draining the battery/triggering the fan when idle. The workaround I have used until now was to enter in sleep mode (s3) a few seconds and after the resume, the problem was gone. I was doing that after every reboot but this fix doesn't work anymore. Initially, I thought that was a problem with the Intel P-State scheduler until I found your question here.

The new workaround for me now is to unload the kernel module.

rmmod intel_lpss_pci

suspend to ram, wait a few seconds, resume, reload the kernel module

modprobe intel_lpss_pci

That's getting more and more convoluted, I wish this could be really fixed...

0

I am:

5.4.0-73-generic #82~18.04.1-Ubuntu x86_64 GNU/Linux

on

HP Pavilion - 14-ce2014

In my case I have had ACPI-related IRQ storms (related to pinctrl_cannonlake, I presume) from both:

I915 (Intel graphics)

and this

INT34BB (Trackpad)

HP drivers. Both take up to 95% of a CPU core after some minutes.

In the end, after many hours or days wasted hunting the culprit, even BIOS flashing, etc. I discovered that the only working method is masking the interrupt(s), e.g. via adding:

acpi_mask_gpe=0x6F

to the kernel parameter for the former I915 bug

and the above temporary fix:

sudo systemctl suspend 

(and then just resuming, even without disabling/enabling the offending module) for the latter INT34BB Trackpad one.

0

Yet another update:

Neither of them worked long-term. This one only works, at least since yesterday: initcall_blacklist=cnl_pinctrl_driver_init

as per https://www.reddit.com/r/archlinux/comments/gdxln8/high_cpu_load_on_a_single_thread/

2
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review Oct 24, 2021 at 13:51
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review Oct 24, 2021 at 13:52
0

Update re the above.

I have also tried:

pci=nocrs

in the kernel parameters, which supposedly does this: "Ignore PCI host bridge windows from ACPI" and now I have zero interrupts from INT34BB:

 14:          0          0          0          0          0          0          0          0  IR-IO-APIC   14-fasteoi   INT34BB:00

even after some hours.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.