Bug 211441
Summary: | S0ix: high battery drain - Dell 9500 | ||
---|---|---|---|
Product: | Power Management | Reporter: | kostadin.karaivanov |
Component: | Run-Time-PM | Assignee: | Zhang Rui (rui.zhang) |
Status: | CLOSED UNREPRODUCIBLE | ||
Severity: | normal | CC: | david.e.box, kostadin.karaivanov, leho, rui.zhang, wendy.wang |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.10.9-201.fc33.x86_64 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
3 minutes turbostat output
ts-running.out dmesg with pm debug enabled lspci -vvv output |
Description
kostadin.karaivanov
2021-01-27 15:01:55 UTC
in not idle state with almost no user activity the upower says: # upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: SMP model: DELL 70N2F95 serial: 58 power supply: yes updated: 27.01.2021 (ср) 17:09:48 (9 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging warning-level: none energy: 48,564 Wh energy-empty: 0 Wh energy-full: 78,0216 Wh energy-full-design: 84,2916 Wh energy-rate: 5,0046 W voltage: 11,508 V time to empty: 9,7 hours percentage: 62% capacity: 92,5615% technology: lithium-polymer icon-name: 'battery-full-symbolic' History (rate): 1611760188 5,005 discharging discharge rate while in S0ix is only half the 5W I see while not in S0ix. please run "turbostat -o ts-freeze-3m.out rtcwake -m freeze -s 180" and attach the ts-freeze-3m.out in this bug report. Let's see how much S0ix residency we can get during the sleep. Note that this command will bring the system back after 3 minutes, so please be patient until the system wakes up. Created attachment 295631 [details]
3 minutes turbostat output
turbostat attached Ok, from the turbostat output attached, you can get 98% PC10 residency and 0 S0ix residency. CC Wendy. Created attachment 296965 [details]
ts-running.out
Strange thing is leaving the device idle with just turbostat running shows(In reply to Zhang Rui from comment #5) > Ok, from the turbostat output attached, you can get 98% PC10 residency and 0 > S0ix residency. > > CC Wendy. Strange thing is leaving the device idle with just turbostat running shows some SYS%LPI residency (ts-running.out attached) While "turbostat -o ts-freeze-3m.out rtcwake -m freeze -s 180" shows SYS%LPI 0. Both done with 5.12.5-300.fc34.x86_64 kernel Which means you get the opportunistic(runtime) s0ix, it's good, but the residency is not good enough: ~31.06% of course you can check any good residency with large interval, e.g. 10 minutes turbostat -o tc.out -i 600 (In reply to wendy.wang from comment #8) > Which means you get the opportunistic(runtime) s0ix, it's good, but the > residency is not good enough: ~31.06% > of course you can check any good residency with large interval, e.g. 10 > minutes > turbostat -o tc.out -i 600 well not really. Running turbostat with -i 600 gives SYS%LPI 0.5 perhaps due to the fact that half way through suspend kicks in and I have no s0ix there. Ping. Is there anything I can contribute as info to get this worked on? I can suggest to look at some of the common issues that blocked s0ix on those early platforms. 1. First we need to see dmesg logs. Please set /sys/power/pm_debug_messages to 1 and provide the debug log for your suspend. Also enable PCI PM debug with this command (as root): echo -n "file pci-driver.c +p" > /sys/kernel/debug/dynamic_debug/control We can check the suspend state of devices as well as look for device errors, wakeups, or other issues. 2. Set /sys/module/acpi/parameters/sleep_no_lps0 to Y. This disables calls to an ACPI method which may (among many things it does) be enforcing extra S0ix requirements that some platforms cannot achieve. 3. Provide lspci -vvv (run as root). 4. Since you are getting 98% PC10 the issue is unlikely to be Embedded Controller (EC) related. But you can try anyway to disable EC wakeup by writing Y to /sys/module/acpi/parameters/ec_no_wakeup. After doing this, only the power button will wake your system from suspend. This option prevents EC interrupts that could block s0ix (but this would typically also block most package c-state too). If these do not work you may consider using s3 instead if the BIOS supports it. To check you need to cat /sys/power/state to see if mem is supported. To use it you need to set /sys/power/mem_sleep to deep. David Created attachment 298317 [details]
dmesg with pm debug enabled
Created attachment 298319 [details]
lspci -vvv output
(In reply to David Box from comment #11) > I can suggest to look at some of the common issues that blocked s0ix on > those early platforms. > > 1. First we need to see dmesg logs. Please set /sys/power/pm_debug_messages > to 1 and provide the debug log for your suspend. Also enable PCI PM debug > with this command (as root): > > echo -n "file pci-driver.c +p" > /sys/kernel/debug/dynamic_debug/control > > We can check the suspend state of devices as well as look for device errors, > wakeups, or other issues. dmesg output with both options attached. The last suspend entry with debug enabled starts at line 1573 > > 2. Set /sys/module/acpi/parameters/sleep_no_lps0 to Y. This disables calls > to an ACPI method which may (among many things it does) be enforcing extra > S0ix requirements that some platforms cannot achieve. > no change in the behavior. turbostat --show SYS%LPI echo mem > /sys/power/state ... 86.760754 sec SYS%LPI 0.00 0.00 > 3. Provide lspci -vvv (run as root). attached > > 4. Since you are getting 98% PC10 the issue is unlikely to be Embedded > Controller (EC) related. But you can try anyway to disable EC wakeup by > writing Y to /sys/module/acpi/parameters/ec_no_wakeup. After doing this, > only the power button will wake your system from suspend. This option > prevents EC interrupts that could block s0ix (but this would typically also > block most package c-state too). > With this one I was unable to wake up the system with the power button. I had to hold it for some (long) time and then press it again to cold boot the laptop. > If these do not work you may consider using s3 instead if the BIOS supports > it. To check you need to cat /sys/power/state to see if mem is supported. To > use it you need to set /sys/power/mem_sleep to deep. S3 is not an option. The BIOS is supporting it bit the platform does not as confirmed in https://bugzilla.kernel.org/show_bug.cgi?id=208603 > > David not sure if it helps but experiment I did. I left this running in terminal: sudo turbostat -q -S -s GFX%rc6,Pkg%pc2,Pkg%pc8,Pkg%pc9,CPU%LPI,SYS%LPI GFX%rc6 Pkg%pc2 Pkg%pc8 Pkg%pc9 CPU%LPI SYS%LPI 79.91 8.38 32.70 0.00 7.35 5.56 92.53 9.36 35.41 0.00 30.05 22.52 86.83 10.17 35.80 0.00 18.31 17.52 <-- suspend here 6349.58 1.52 0.22 0.00 67.22 0.00 <-- first line after resume 57.27 4.60 0.00 0.00 0.00 0.00 ^C82.47 7.22 0.00 0.00 0.00 0.00 Does it still needs more info and what it could be ? with the update to kernel 5.18.6-200.fc36.x86_64 I am finally able to achieve s0ix residency. I'm not sure what change between 5.17.7-300.fc36.x86_64 and 5.18 fixed it but now it is OK. Good to know. But once it works, at least we can git bisect when the problem come back again. Bug closed. Mark as unreproducible as we don't know what exactly the fix is for now. I can still try to bisect it as time permits. Will post update here if appropriate. booting with vanilla 5.17.0 also gets s0ix working so it must have been the firmware upgrade to version 1.14.0 that fixed it. Today's upgrade to bios firmware 1.15.1 with fedora kernel 5.18.7-200 is good too. |