Created attachment 1697670 [details] Notice the #1 CPU bar Description of problem: When my laptop goes out of sleep, a very high CPU usage is being reported despite nothing going on the computer. As soon as I touch the touchpad, the CPU usage drops. It has mostly an impact on battery life and laptop temperature especially when using a mouse and keyboard. Version-Release number of selected component (if applicable): 32 How reproducible: Always Steps to Reproduce: 1. Make the laptop enter deep sleep 2. turn it back on 3. Notice high CPU usage in htop 4. touch the touchpad 5. notice CPU usage drop Actual results: High CPU usage Expected results: Normal idle CPU usage Additional info: Laptop Dell XPS 13 7390 developper edition. maybe leads..? https://randomascii.wordpress.com/2017/09/05/hey-synaptics-can-you-please-stop-polling/ https://certification.ubuntu.com/catalog/component/input:CUST0001:0006CB:76AFTouchpad
sounds like a kernel issue rather than a libinput issue. does libinput record show any data coming out of the device after suspend and before you touch it?
Digging deeper mpstat -P ALL 1 ↵ 10011 00:21:18 Linux 5.6.18-300.fc32.x86_64 (grey-matter) 17/06/2020 _x86_64_ (8 CPU) 00:21:20 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 00:21:20 all 13,19 0,03 3,53 0,02 6,36 0,23 0,00 0,00 0,00 76,64 00:21:20 0 3,02 0,01 1,39 0,03 14,57 0,10 0,00 0,00 0,00 80,89 00:21:20 1 19,90 0,03 4,88 0,02 0,97 0,52 0,00 0,00 0,00 73,68 00:21:20 2 20,30 0,09 5,11 0,01 0,82 0,61 0,00 0,00 0,00 73,06 00:21:20 3 20,36 0,04 5,22 0,02 0,44 0,27 0,00 0,00 0,00 73,66 00:21:20 4 20,50 0,06 4,49 0,01 1,37 0,21 0,00 0,00 0,00 73,36 00:21:20 5 20,40 0,04 4,93 0,02 0,43 0,21 0,00 0,00 0,00 73,97 00:21:20 6 19,90 0,04 5,08 0,01 0,49 0,22 0,00 0,00 0,00 74,26 00:21:20 7 19,91 0,07 5,27 0,01 0,49 0,24 0,00 0,00 0,00 74,00 watch -n1 -d cat /proc/interrupts shows that 17: 120699862 0 0 0 1712788 0 0 0 IR-IO-APIC 17-fasteoi i2c_designware.1, idma64.1 and 51: 1876859 0 0 0 0 0 28310 0 IR-IO-APIC 51-fasteoi CUST0001:00 have a very high rate of increase while the CPU is high, and stops as soon as I touch the touchpad. Hope it helps, thanks.
libinput record does show lots of events indeed. libinput record (device 8, CUST0001 touchpad) - evdev: - [ 57, 954750, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 954750, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1ms - evdev: - [ 57, 956400, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 956400, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +2ms - evdev: - [ 57, 958049, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 958049, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +2ms - evdev: - [ 57, 959699, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 959699, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1ms - evdev: - [ 57, 961348, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 961348, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +2ms - evdev: - [ 57, 962998, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 962998, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1ms - evdev: - [ 57, 964647, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 964647, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +2ms - evdev: - [ 57, 966299, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 966299, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +2ms - evdev: - [ 57, 967957, 4, 5, 0] # EV_MSC / MSC_TIMESTAMP 0 - [ 57, 967957, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1ms
and it stops after I touch the touchpad.
Punting to the kernel, those events are the touchpad going crazy sending nothing but zero-value timestamps every ms. That interrupt storm has been seen before but I don't know the bug number though.
Hi, is there anything more I can provide, or an upstream to link the bug to? Cheers
Hi, the issue is still there on fedora 34. Again, I'd like to help if I only knew some upstream to link the bug to. Currently, my kernel is 5.11.7-300.fc34.x86_64 Kind regards
I have an XPS-13 and it does not exhibit this behavior. Did you change any powertop tunables?
In today's Prioritized Bugs meeting, we voted to accept this as a prioritized bug. I will put out a call for testing to see if we can narrow down the cause.
(In reply to andreas.mack from comment #8) > I have an XPS-13 and it does not exhibit this behavior. Ben asked for "me too"s. Cannot reproduce on XPS-13.
I used to see this until recently on my XPS 13 9360: I have psi-notify installed and would immediately get a notification of high CPU pressure. I just tried resuming just now and didn't see it (on 5.11.11-300.fc34), but will report back if I manage to repro again.
For users chiming in with reproduction, may I suggest that you include the output of "cat /sys/power/mem_sleep" and "uname -r" with your report? Recent XPS 13 laptops default to s2idle sleep, and the 11th gen CPU models don't even support "deep" sleep as an option any more, which may be relevant to reproducing the bug.
I'm on a XPS-13 9370, cannot reproduce the bug. # cat /sys/power/mem_sleep [s2idle] deep # uname -r 5.11.14-200.fc33.x86_64 I've also tried: - activating touchscreen - disable usb-related tunables in powertop.
I am also responding to the call to testing: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/Y747IOMOJ7WVAVVJUUPQ6IVB6OJVDBZA/ I do not get any high CPU usage after resuming: no core/threat exceeds 25% usage, so it appears I cannot reproduce it. I use a rather new model: XPS 13 9380 which is different from the OP. My steps to try to reproduce: Steps to Reproduce: 1. Suspend the laptop from the Power Off/Log Out menu 2. turn it back on by pressing button on the keyboard # cat /sys/power/mem_sleep [s2idle] deep # uname -r 5.11.13-300.fc34.x86_64
Responding to the call for testing. Dell XPS 13 9360. Cannot reproduce. # cat /sys/power/mem_sleep [s2idle] deep # uname -r 5.11.12-300.fc34.x86_64
XPS 9300, cannot duplicate: $ cat /sys/power/mem_sleep s2idle [deep] $ uname -r 5.11.15-300.fc34.x86_64 Also could not reproduce on a 9310 but it doesn't support the s2idle mode. Same version of the kernel on that machine.
Hi, Thanks everyone for your attention on that. I am still able to reproduce the bug. It's indeed the case that I have changed some settings to save power: cat /sys/power/mem_sleep s2idle [deep] cat /proc/cmdline BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.11.14-300.fc34.x86_64 root=UUID=bf91a10c-578d-44d0-b113-2b564b180f54 ro resume=/dev/mapper/luks-b240fb0c-ee33-478e-8b9b-75d9fdbe5f13 rd.luks.uuid=luks-b25c2db9-b81e-4253-8cf9-fc3569d7fbdb rd.luks.uuid=luks-b240fb0c-ee33-478e-8b9b-75d9fdbe5f13 rhgb quiet mitigations=off systemd.unified_cgroup_hierarchy=0 mem_sleep_default=deep However I don't believe I'v change powertop settings, so I believe they're mostly default from boot systemctl status powertop ○ powertop.service - PowerTOP autotuner Loaded: loaded (/usr/lib/systemd/system/powertop.service; disabled; vendor preset: disabled) Active: inactive (dead) >> Bad NMI watchdog should be turned off Bad VM writeback timeout Bad Autosuspend for USB device YubiKey OTP+FIDO+CCID [Yubico] Bad Runtime PM for PCI Device Micron Technology Inc Device 5410 Bad Runtime PM for PCI Device Intel Corporation Wi-Fi 6 AX200 Good Enable Audio codec power management Good Bluetooth device interface status Good Autosuspend for USB device xHCI Host Controller [usb1] Good Autosuspend for USB device xHCI Host Controller [usb2] Good Runtime PM for I2C Adapter i2c-5 (i915 gmbus dpd) Good Runtime PM for I2C Adapter i2c-0 (Synopsys DesignWare I2C adapter) Good Runtime PM for I2C Adapter i2c-10 (SMBus I801 adapter at efa0) Good Runtime PM for I2C Adapter i2c-2 (i915 gmbus dpb) Good Runtime PM for I2C Adapter i2c-3 (i915 gmbus dpc) Good Runtime PM for I2C Adapter i2c-4 (i915 gmbus misc) Good Autosuspend for USB device xHCI Host Controller [usb3] Good Autosuspend for unknown USB device 1-7 (8087:0029) Good Runtime PM for I2C Adapter i2c-1 (Synopsys DesignWare I2C adapter) Good Autosuspend for USB device Integrated_Webcam_HD [CN09357G8LG0097GA5BLA01] Good Autosuspend for USB device xHCI Host Controller [usb4] Good Runtime PM for PCI Device Intel Corporation Comet Lake PCH-LP Shared SRAM Good Runtime PM for PCI Device Intel Corporation CometLake-U GT2 [UHD Graphics] Good Runtime PM for PCI Device Intel Corporation Comet Lake Serial IO I2C Host Controller Good Runtime PM for PCI Device Intel Corporation Comet Lake PCH-LP USB 3.1 xHCI Host Controller Good Runtime PM for PCI Device Intel Corporation Comet Lake PCH-LP SMBus Host Controller Good Runtime PM for PCI Device Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] Good Runtime PM for PCI Device Intel Corporation Comet Lake Thermal Subsytem Good Runtime PM for PCI Device Intel Corporation Comet Lake-U v1 4c Host Bridge/DRAM Controller Good Runtime PM for PCI Device Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Good Runtime PM for PCI Device Intel Corporation Comet Lake PCH-LP cAVS Good Runtime PM for PCI Device Intel Corporation Comet Lake PCI Express Root Port #13 Good Runtime PM for PCI Device Intel Corporation Comet Lake SPI (flash) Controller Good Runtime PM for PCI Device Intel Corporation Comet Lake PCH-LP LPC Premium Controller/eSPI Controller Good Runtime PM for PCI Device Intel Corporation Comet Lake Management Engine Interface Good Runtime PM for PCI Device Intel Corporation Comet Lake PCI Express Root Port #5 Good Runtime PM for PCI Device Intel Corporation Comet Lake PCI Express Root Port #9 Good Runtime PM for PCI Device Intel Corporation Device 02be Good Runtime PM for PCI Device Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Good Runtime PM for PCI Device Intel Corporation JHL6540 Thunderbolt 3 NHI (C step) [Alpine Ridge 4C 2016] Good Runtime PM for PCI Device Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model Good Runtime PM for PCI Device Intel Corporation Serial IO I2C Host Controller Good Runtime PM for PCI Device Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Good Runtime PM for PCI Device Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Good Runtime PM for PCI Device Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader Good Runtime PM for PCI Device Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem Good Runtime PM for PCI Device Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Cheers
May I mention that by default, the laptop is set to s2idle, which was related to a bg power draw. The laptop could barely handle a night without running out of power in sleep mode.
systemctl is-enabled powertop disabled
Could it be worthwhile to see if more people could try and reproduce with [deep] sleep setting instead of s2idle ?
(In reply to fred from comment #20) > Could it be worthwhile to see if more people could try and reproduce with > [deep] sleep setting instead of s2idle ? Can you still reproduce using [s2idle]?
I can confirm the behavior described in comment 2 with my XPS 9360 and [deep] sleep.
Indeed, the problem disappear if I set back the sleep setting to [s2idle].
I can confirm this to happen on my 9370 when I switch to "deep". High interrupts from irq/51-DELL07E6. Staying with "deep" to see if power saving is really that much better.
I stumbled on https://bugzilla.redhat.com/show_bug.cgi?id=1656416 "irq/51-DELL0820 causes 100% load of CPU" via a google search.
Sorry, irq/51-DELL07E6 is the kernel thread (I guess). But from cat /proc/interrupts I see a lot more interrupts happening from "i2c_designware.1" 17: 7884710 0 0 0 89935 0 0 0 IR-IO-APIC 17-fasteoi i2c_designware.1, idma64.1 51: 121956 0 0 0 2068 0 0 0 IR-IO-APIC 51-fasteoi DELL07E6:00 When I touch the touchpad, it stops counting up on both.
I believe that Peter was referencing bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/263 earlier, which also mentionned touchpad, i2c_designware.1 and an IRQ flood. The bug report has this workaround: sudo rmmod i2c_hid sudo modprobe i2c_hid
Please attach dmesg output.
[ 199.038874] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 [ 199.063770] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 [ 199.083860] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 [ 199.102611] wlp2s0: deauthenticating from 38:94:ed:29:5b:ec by local choice (Reason: 3=DEAUTH_LEAVING) [ 199.300657] PM: suspend entry (deep) [ 199.315419] Filesystems sync: 0.014 seconds [ 199.445003] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 199.447719] OOM killer disabled. [ 199.447720] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 199.448796] printk: Suspending console(s) (use no_console_suspend to debug) [ 199.688920] psmouse serio1: Failed to disable mouse on isa0060/serio1 [ 203.001424] PM: suspend devices took 3.552 seconds [ 203.021806] ACPI: EC: interrupt blocked [ 203.096232] ACPI: Preparing to enter system sleep state S3 [ 203.102929] ACPI: EC: event blocked [ 203.102931] ACPI: EC: EC stopped [ 203.102932] PM: Saving platform NVS memory [ 203.103014] Disabling non-boot CPUs ... [ 203.103850] IRQ 162: no longer affine to CPU1 [ 203.104906] smpboot: CPU 1 is now offline [ 203.106857] IRQ 163: no longer affine to CPU2 [ 203.107897] smpboot: CPU 2 is now offline [ 203.109719] IRQ 164: no longer affine to CPU3 [ 203.110756] smpboot: CPU 3 is now offline [ 203.112546] IRQ 165: no longer affine to CPU4 [ 203.113578] smpboot: CPU 4 is now offline [ 203.116179] IRQ 166: no longer affine to CPU5 [ 203.117210] smpboot: CPU 5 is now offline [ 203.118731] IRQ 167: no longer affine to CPU6 [ 203.119778] smpboot: CPU 6 is now offline [ 203.121552] IRQ 168: no longer affine to CPU7 [ 203.122590] smpboot: CPU 7 is now offline [ 203.126911] ACPI: Low-level resume complete [ 203.126999] ACPI: EC: EC started [ 203.126999] PM: Restoring platform NVS memory [ 203.128160] Enabling non-boot CPUs ... [ 203.128203] x86: Booting SMP configuration: [ 203.128204] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 203.129293] CPU1 is up [ 203.129320] smpboot: Booting Node 0 Processor 2 APIC 0x4 [ 203.129939] CPU2 is up [ 203.129965] smpboot: Booting Node 0 Processor 3 APIC 0x6 [ 203.130587] CPU3 is up [ 203.130611] smpboot: Booting Node 0 Processor 4 APIC 0x1 [ 203.131338] CPU4 is up [ 203.131367] smpboot: Booting Node 0 Processor 5 APIC 0x3 [ 203.132016] CPU5 is up [ 203.132042] smpboot: Booting Node 0 Processor 6 APIC 0x5 [ 203.132693] CPU6 is up [ 203.132726] smpboot: Booting Node 0 Processor 7 APIC 0x7 [ 203.133380] CPU7 is up [ 203.135901] ACPI: Waking up from system sleep state S3 [ 203.244865] ACPI: EC: interrupt unblocked [ 203.294049] ACPI: button: The lid device is not compliant to SW_LID. [ 204.671746] ACPI: EC: event unblocked [ 204.674443] usb usb3: root hub lost power or was reset [ 204.674460] usb usb4: root hub lost power or was reset [ 204.703804] nvme nvme0: 8/0/0 default/read/poll queues [ 204.942922] usb 1-7: reset full-speed USB device number 4 using xhci_hcd [ 205.182932] usb 1-5: reset high-speed USB device number 3 using xhci_hcd [ 205.332104] PM: resume devices took 0.661 seconds [ 205.332116] acpi LNXPOWER:07: Turning OFF [ 205.332155] acpi LNXPOWER:02: Turning OFF [ 205.332179] acpi LNXPOWER:01: Turning OFF [ 205.332193] acpi LNXPOWER:00: Turning OFF [ 205.332205] OOM killer enabled. [ 205.332206] Restarting tasks ... [ 205.332855] pci_bus 0000:05: Allocating resources [ 205.332871] pci_bus 0000:3b: Allocating resources [ 205.336082] done. [ 205.339294] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915]) [ 205.414794] PM: suspend exit [ 205.415179] Bluetooth: hci0: Bootloader revision 0.3 build 0 week 24 2017 [ 205.416210] Bluetooth: hci0: Device revision is 1 [ 205.416214] Bluetooth: hci0: Secure boot is enabled [ 205.416215] Bluetooth: hci0: OTP lock is enabled [ 205.416216] Bluetooth: hci0: API lock is enabled [ 205.416217] Bluetooth: hci0: Debug lock is disabled [ 205.416218] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 205.416228] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi [ 205.699864] mmc0: cannot verify signal voltage switch [ 206.997627] Bluetooth: hci0: Waiting for firmware download to complete [ 206.999165] Bluetooth: hci0: Firmware loaded in 1547209 usecs [ 206.999173] Bluetooth: hci0: Waiting for device to boot [ 207.014200] Bluetooth: hci0: Device booted in 14681 usecs [ 207.014222] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-20-1-3.ddc [ 207.016232] Bluetooth: hci0: Applying Intel DDC parameters completed [ 207.019238] Bluetooth: hci0: Firmware revision 0.0 build 121 week 7 2021 [ 209.056325] wlp2s0: authenticate with 38:94:ed:29:5b:ec [ 209.061672] wlp2s0: send auth to 38:94:ed:29:5b:ec (try 1/3) [ 209.090876] wlp2s0: authenticated [ 209.091772] wlp2s0: associate with 38:94:ed:29:5b:ec (try 1/3) [ 209.094324] wlp2s0: RX AssocResp from 38:94:ed:29:5b:ec (capab=0x1511 status=0 aid=3) [ 209.099308] iwlwifi 0000:02:00.0: Got NSS = 8 - trimming to 2 [ 209.106501] wlp2s0: associated [ 209.124108] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready [ 209.211770] wlp2s0: Limiting TX power to 21 (24 - 3) dBm as advertised by 38:94:ed:29:5b:ec
Sorry, I meant a full dmesg after a fresh boot, not post resume.
Created attachment 1779157 [details] full boot dmesg
Thanks, turns out I have this exact laptop config from Dell. I can probably debug it, but it is going to be late next week at the earliest as we are in the middle of the merge window for 5.13 this week, and next week is the kernel-5.12 test week. I know this bug is listed as "priority" but it really isn't. This is not a default config for this machine, and while the machine is common, having to explain to people how to configure their machine to reproduce it shows that most users are not hitting it.
Looks like I never flipped the flag.
Thanks for the testing, everyone. Based on what we know now, this bug is no longer considered a Prioritized Bug. The impact is limited to a specific touchpad model used in a non-default configuration: https://meetbot.fedoraproject.org/fedora-meeting-1/2021-05-05/fedora_prioritized_bugs_and_issues.2021-05-05-15.00.log.html#l-96 However, the kernel maintainer believes he will be able to address this bug in the coming weeks.
Hi, happy to know that a kernel maintainer has the same laptop :) In honesty, I would not have changed the default setting if the default [s2idle] hadnt such a dramatic battery drain a year back when I got the laptop. It could use more that half of the battery in a single night with the lid closed. Maybe hardware, software, firmware or a combination of the three has fixed the issue since then, so I'm going to revisit this. Thanks for taking the time to consider (maybe) taking a look at the issue. It's much appreciated. Cheers
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.