Bug 1847627 - Cpu usage very high until touchpad is touched
Summary: Cpu usage very high until touchpad is touched
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-16 17:31 UTC by fred
Modified: 2021-05-05 20:30 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
bcotton: fedora_prioritized_bug-


Attachments (Terms of Use)
Notice the #1 CPU bar (311.15 KB, image/png)
2020-06-16 17:31 UTC, fred
no flags Details
full boot dmesg (104.35 KB, text/plain)
2021-05-03 22:52 UTC, fred
no flags Details

Description fred 2020-06-16 17:31:07 UTC
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

Comment 1 Peter Hutterer 2020-06-16 22:27:35 UTC
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?

Comment 2 fred 2020-06-16 22:40:03 UTC
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.

Comment 3 fred 2020-06-16 22:43:57 UTC
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

Comment 4 fred 2020-06-16 22:44:41 UTC
and it stops after I touch the touchpad.

Comment 5 Peter Hutterer 2020-06-16 23:53:03 UTC
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.

Comment 6 fred 2020-06-24 08:37:48 UTC
Hi, is there anything more I can provide, or an upstream to link the bug to? Cheers

Comment 7 fred 2021-03-22 23:07:20 UTC
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

Comment 8 andreas.mack@konsec.com 2021-04-21 15:43:05 UTC
I have an XPS-13 and it does not exhibit this behavior. Did you change any powertop tunables?

Comment 9 Ben Cotton 2021-04-21 16:37:33 UTC
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.

Comment 10 Garry T. Williams 2021-04-21 18:44:42 UTC
(In reply to andreas.mack@konsec.com 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.

Comment 11 Michel Alexandre Salim 2021-04-22 00:24:08 UTC
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.

Comment 12 Gordon Messmer 2021-04-22 02:27:16 UTC
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.

Comment 13 andreas.mack@konsec.com 2021-04-22 07:07:57 UTC
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.

Comment 14 d.vicesss 2021-04-22 13:01:10 UTC
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

Comment 15 Brandon Nielsen 2021-04-22 19:15:49 UTC
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

Comment 16 Leander 2021-04-22 20:38:43 UTC
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.

Comment 17 fred 2021-04-22 20:54:51 UTC
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

Comment 18 fred 2021-04-22 20:57:59 UTC
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.

Comment 19 fred 2021-04-22 21:08:58 UTC
systemctl is-enabled powertop
disabled

Comment 20 fred 2021-04-22 21:10:53 UTC
Could it be worthwhile to see if more people could try and reproduce with [deep] sleep setting instead of s2idle ?

Comment 21 Brandon Nielsen 2021-04-22 23:33:43 UTC
(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]?

Comment 22 Brandon Nielsen 2021-04-23 00:03:24 UTC
I can confirm the behavior described in comment 2 with my XPS 9360 and [deep] sleep.

Comment 23 fred 2021-04-23 07:57:32 UTC
Indeed, the problem disappear if I set back the sleep setting to [s2idle].

Comment 24 andreas.mack@konsec.com 2021-04-23 08:42:35 UTC
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.

Comment 25 fred 2021-04-23 12:30:11 UTC
I stumbled on https://bugzilla.redhat.com/show_bug.cgi?id=1656416 "irq/51-DELL0820 causes 100% load of CPU" via a google search.

Comment 26 andreas.mack@konsec.com 2021-04-23 14:25:24 UTC
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.

Comment 27 fred 2021-04-23 19:59:37 UTC
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

Comment 28 Justin M. Forbes 2021-04-30 20:59:47 UTC
Please attach dmesg output.

Comment 29 fred 2021-04-30 21:22:46 UTC
[  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

Comment 30 Justin M. Forbes 2021-05-03 18:33:55 UTC
Sorry, I meant a full dmesg after a fresh boot, not post resume.

Comment 31 fred 2021-05-03 22:52:49 UTC
Created attachment 1779157 [details]
full boot dmesg

Comment 32 Justin M. Forbes 2021-05-04 15:19:59 UTC
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.

Comment 33 Ben Cotton 2021-05-04 15:28:10 UTC
Looks like I never flipped the flag.

Comment 34 Ben Cotton 2021-05-05 16:08:04 UTC
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.

Comment 35 fred 2021-05-05 20:30:27 UTC
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


Note You need to log in before you can comment on or make changes to this bug.