Bug 118751
Summary: | Laptop CPU cores stuck at minimal 800MHz on AC | ||
---|---|---|---|
Product: | Power Management | Reporter: | Marcin Nowak (marcin.j.nowak) |
Component: | intel_pstate | Assignee: | Chen Yu (yu.c.chen) |
Status: | CLOSED OBSOLETE | ||
Severity: | normal | CC: | dsmythies, jan.dugacek, marcin.j.nowak, onedeathbyflame, rjw, rui.zhang, srinivas.pandruvada |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.6.0-1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Kernel config
trace output when stuck trace output after cpu unlock stress+stuck trace stress+unstuck trace Turbostat started when cpu was stuck, then I've reconnected AC during capture Turbostat when unstuck turbostart (torvalds/linux@master) results when stuck turbostart (torvalds/linux@master) results when unstuck Stuck: sleep+stress Unstuck: sleep+stress trace |
Description
Marcin Nowak
2016-05-23 10:23:47 UTC
Sometimes battery isn't charging, even upower prints something else: $ upower -i /org/freedesktop/UPower/devices/battery_BAT1 native-path: BAT1 vendor: SANYO model: DELL 6HY59349 serial: 09CE power supply: yes updated: nie, 29 maj 2016, 13:41:00 (20 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: charging warning-level: none energy: 9,3684 Wh energy-empty: 0 Wh energy-full: 46,4868 Wh energy-full-design: 66,6 Wh energy-rate: 13,0425 W voltage: 11,316 V time to full: 2,8 hours percentage: 20% capacity: 69,8% icon-name: 'battery-low-charging-symbolic' History (rate): 1464522055 13,043 charging The percentage is stuck at 20% for almost an hour. The CPU is also stuck at 800MHz. When I do some reconnectings of AC power, the CPU unlocks and laptop is charging. AC reconnection sequence: History (rate): 1464522339 12,210 unknown 1464522338 13,575 discharging 1464522326 16,139 charging 1464522325 11,844 discharging 1464522323 15,207 discharging 1464522322 12,354 discharging 1464522314 2,808 charging 1464522313 11,400 charging 1464522312 11,566 charging 1464522311 12,354 charging 1464522309 14,096 discharging 1464522302 15,107 charging 1464522293 17,778 discharging 1464522282 5,594 charging 1464522281 23,044 discharging 1464522274 13,942 charging Upower BAT after unlock: $ upower -i /org/freedesktop/UPower/devices/battery_BAT1 native-path: BAT1 vendor: SANYO model: DELL 6HY59349 serial: 09CE power supply: yes updated: nie, 29 maj 2016, 13:47:40 (5 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: charging warning-level: none energy: 10,3119 Wh energy-empty: 0 Wh energy-full: 46,4868 Wh energy-full-design: 66,6 Wh energy-rate: 23,0325 W voltage: 11,728 V time to full: 1,6 hours percentage: 22% capacity: 69,8% icon-name: 'battery-low-charging-symbolic' History (charge): 1464522460 22,000 charging History (rate): 1464522460 23,033 charging Intersting... could you attach your kernel config? sudo grep . /sys/devices/system/cpu/cpu1/cpufreq/* sudo grep . /sys/devices/system/cpu/intel_pstate/ and # cd /sys/kernel/debug/tracing/ # echo 1 > events/power/pstate_sample/enable # echo 1 > events/power/cpu_frequency/enable # cat trace // also attach here (In reply to Chen Yu from comment #2) > Intersting... > could you attach your kernel config? > > sudo grep . /sys/devices/system/cpu/cpu1/cpufreq/* > sudo grep . /sys/devices/system/cpu/intel_pstate/ > > and > # cd /sys/kernel/debug/tracing/ > # echo 1 > events/power/pstate_sample/enable > # echo 1 > events/power/cpu_frequency/enable > # cat trace // also attach here sudo grep . /sys/devices/system/cpu/intel_pstate/* and try to provide 'cat trace' before/after reproduced Created attachment 218311 [details]
Kernel config
Thank you for concern. When stuck: $ sudo grep . /sys/devices/system/cpu/cpu1/cpufreq/* /sys/devices/system/cpu/cpu1/cpufreq/affected_cpus:1 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq:799945 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:2700000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:800000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency:4294967295 /sys/devices/system/cpu/cpu1/cpufreq/related_cpus:1 /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors:performance powersave /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:799945 /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_pstate /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:powersave /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq:2700000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:800000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed:<unsupported> $ sudo grep . /sys/devices/system/cpu/intel_pstate/* /sys/devices/system/cpu/intel_pstate/max_perf_pct:100 /sys/devices/system/cpu/intel_pstate/min_perf_pct:29 /sys/devices/system/cpu/intel_pstate/no_turbo:0 /sys/devices/system/cpu/intel_pstate/num_pstates:20 /sys/devices/system/cpu/intel_pstate/turbo_pct:50 When unstuck: $ sudo grep . /sys/devices/system/cpu/cpu1/cpufreq/* /sys/devices/system/cpu/cpu1/cpufreq/affected_cpus:1 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq:864984 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:2700000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:800000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency:4294967295 /sys/devices/system/cpu/cpu1/cpufreq/related_cpus:1 /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors:performance powersave /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:1003710 /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_pstate /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:powersave /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq:2700000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:800000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed:<unsupported> $ sudo grep . /sys/devices/system/cpu/intel_pstate/* /sys/devices/system/cpu/intel_pstate/max_perf_pct:100 /sys/devices/system/cpu/intel_pstate/min_perf_pct:29 /sys/devices/system/cpu/intel_pstate/no_turbo:0 /sys/devices/system/cpu/intel_pstate/num_pstates:20 /sys/devices/system/cpu/intel_pstate/turbo_pct:50 Created attachment 218321 [details]
trace output when stuck
Created attachment 218331 [details]
trace output after cpu unlock
please run 'stress -c 4' and do the same testing. I saw most the trace data are sampled when in idle. should I clean trace somehow? it outputs 16M file for now... (In reply to Marcin Nowak from comment #9) > should I clean trace somehow? it outputs 16M file for now... Yes, please echo NULL > trace to clear it. stuck: stress -c 4 echo NULL > trace cat trace > stuck.log unstuck: stress -c 4 echo NULL > trace cat trace > unstuck.log Created attachment 218341 [details]
stress+stuck trace
Created attachment 218351 [details]
stress+unstuck trace
please provide the following info both when stunk/unstunk: rdmsr 0x774 -p 0 rdmsr 0x774 -p 1 rdmsr 0x774 -p 2 rdmsr 0x774 -p 3 rdmsr 0x19c -p 0 rdmsr 0x19c -p 1 rdmsr 0x19c -p 2 rdmsr 0x19c -p 3 use latest turbostat (cd linux/tools/power/x86/turbostat/;make) turbostat --debug -i 10 Is it reproduced if boot with 'intel_pstate=disable' ? plus: rdmsr 0x19a -p 0 rdmsr 0x19a -p 1 rdmsr 0x19a -p 2 rdmsr 0x19a -p 3 Unstuck: # rdmsr 0x774 -p 0 rdmsr: CPU 0 cannot read MSR 0x00000774 # rdmsr 0x774 -p 1 rdmsr: CPU 1 cannot read MSR 0x00000774 # rdmsr 0x774 -p 2 rdmsr: CPU 2 cannot read MSR 0x00000774 # rdmsr 0x774 -p 3 rdmsr: CPU 3 cannot read MSR 0x00000774 # rdmsr 0x19c -p 0 88360008 # rdmsr 0x19c -p 1 88370008 # rdmsr 0x19c -p 2 88380008 # rdmsr 0x19c -p 3 88390008 # rdmsr 0x19a -p 0 8 # rdmsr 0x19a -p 1 8 # rdmsr 0x19a -p 2 8 # rdmsr 0x19a -p 3 8 Stuck: # rdmsr 0x774 -p 0 rdmsr: CPU 0 cannot read MSR 0x00000774 # rdmsr 0x774 -p 1 rdmsr: CPU 1 cannot read MSR 0x00000774 # rdmsr 0x774 -p 2 rdmsr: CPU 2 cannot read MSR 0x00000774 # rdmsr 0x774 -p 3 rdmsr: CPU 3 cannot read MSR 0x00000774 # rdmsr 0x19c -p 0 8833000c # rdmsr 0x19c -p 1 8834000c # rdmsr 0x19c -p 2 8833000c # rdmsr 0x19c -p 3 8833000c # rdmsr 0x19a -p 0 8 # rdmsr 0x19a -p 1 8 # rdmsr 0x19a -p 2 8 # rdmsr 0x19a -p 3 8 Give me some time to test latest turbostat and intel_pstate disabled. I'll try to deliver results today. Until I get newest turbostat I'll post results from v4.12 5 Apr 2016 Created attachment 218381 [details]
Turbostat started when cpu was stuck, then I've reconnected AC during capture
Created attachment 218391 [details]
Turbostat when unstuck
Created attachment 218401 [details]
turbostart (torvalds/linux@master) results when stuck
Created attachment 218411 [details]
turbostart (torvalds/linux@master) results when unstuck
After a few tests I can't reproduce the bug when intel_pstate is disabled (cpu scales well, just the max is limited to 1801.000 MHz) $ sudo grep . /sys/devices/system/cpu/cpu1/cpufreq/* /sys/devices/system/cpu/cpu1/cpufreq/affected_cpus:1 /sys/devices/system/cpu/cpu1/cpufreq/bios_limit:1801000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq:1801000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:1801000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:774000 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency:10000 /sys/devices/system/cpu/cpu1/cpufreq/freqdomain_cpus:0 1 2 3 /sys/devices/system/cpu/cpu1/cpufreq/related_cpus:1 /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies:1801000 1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000 1000000 900000 800000 774000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors:ondemand performance /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:1801000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:acpi-cpufreq /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq:1801000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:774000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed:<unsupported> I'll work next days without intel_pstate to be sure for 1000% (but it looks that the issue is related to intel_pstate). Today is a second day without intel_pstate - still can't reproduce the issue. Should I check/test something else? acpi-cpufreq works well because it does not rely on the feedback of aperf/mperf as intel_pstate does. BTW, msr 19c:bit10~11 are not set, this means the rapl does not restrict the freq. According to the trace log at #Comment 11, the increment of aperf is very small compared to unstuck: stress-21785 [000] d.h2 195679.724800: pstate_sample: core_busy=44 scaled=88 from=9 to=8 mperf=17959383 aperf=7981962 tsc=17959365 freq=799945 could you adjust the test sequence to the following: stuck: cd /sys/kernel/debug/tracing/ echo NULL > trace echo 1 > events/power/pstate_sample/enable echo 1 > events/power/cpu_frequency/enable sleep 5 stress -c 4 cat trace > stuck_all.log unstuck: cd /sys/kernel/debug/tracing/ echo NULL > trace echo 1 > events/power/pstate_sample/enable echo 1 > events/power/cpu_frequency/enable sleep 5 stress -c 4 cat trace > unstuck_all.log please stop 'stress' before each time you retest with plug/unplug AC, since I want to see the full process how the cpu freq raise up in unstuck situation. > acpi-cpufreq works well because it does not rely on the feedback of
aperf/mperf as intel_pstate does.
I'm still thinking about the issue. The strange for me is that when working on battery the CPU is working at full speed, but when connecting AC - it slows down to minimum. Shouldn't be opposite? CPU scales well but sometimes is locked to minimum on AC.
To be clear - the term "stuck" means: on AC - 800MHz, on BATT - full speed. And "unstuck" means: on AC - full speed, after disconnecting AC - full speed. And I need just one AC connect to get from "unstuck" into "stuck", but escaping from "stuck" into "unstuck" requires a few AC reconnects (sometime less, sometime more).
I'm attaching fresh logs... I've tried to do tests the way you've asked.
Created attachment 218771 [details]
Stuck: sleep+stress
Created attachment 218781 [details]
Unstuck: sleep+stress trace
I can also reproduce on Linux 3.18.34-1-MANJARO #1 SMP PREEMPT, but I can't remember which version was okay... Maybe root of the problem lies elsewhere? Then this is not a regression, It's weird the increment of aperf is so small,besides Thermal monitor/Clock modulation, the other component might affect aperf is HDC, what's the value when stunk/unstunk: rdmsr 0xdb0 -p 0 rdmsr 0xdb1 -p 0 rdmsr 0xdb2 -p 0 rdmsr 0x652 -p 0 rdmsr 0x653 -p 0 rdmsr 0x655 -p 0 rdmsr 0x656 -p 0 rdmsr 0xdb0 -p 1 rdmsr 0xdb1 -p 1 rdmsr 0xdb2 -p 1 rdmsr 0x652 -p 1 rdmsr 0x653 -p 1 rdmsr 0x655 -p 1 rdmsr 0x656 -p 1 rdmsr 0xdb0 -p 2 rdmsr 0xdb1 -p 2 rdmsr 0xdb2 -p 2 rdmsr 0x652 -p 2 rdmsr 0x653 -p 2 rdmsr 0x655 -p 2 rdmsr 0x656 -p 2 rdmsr 0xdb0 -p 3 rdmsr 0xdb1 -p 3 rdmsr 0xdb2 -p 3 rdmsr 0x652 -p 3 rdmsr 0x653 -p 3 rdmsr 0x655 -p 3 rdmsr 0x656 -p 3 Also + Srinivas and Rafael For every call I've got: rdmsr: CPU <number> cannot read MSR <hex> (while stuck and unstuck) I'm wondering about these failed reads. Maybe I should do tests on some fresh install of some distro booted from usb stick? Feel free to ask for anything, I'd like to help as I can... (In reply to Marcin Nowak from comment #30) > For every call I've got: > > rdmsr: CPU <number> cannot read MSR <hex> > > > (while stuck and unstuck) I guess your cpu does not support HDC (Ivy Bridge), so HDC is not the cause of this problem. I've no idea why the aperf increase so slow when AC plugged, @Rafael @Srinivas do you have any clue on this? thanks With AC connected and without connected, please provide dump of the following: rdmsr 0xCE rdmsr 0x1AD rdmsr 0x610 rdmsr 0x614 rdmsr 0x648 rdmsr 0x649 rdmsr 0x64A rdmsr 0x64B rdmsr 0x64C AC Connected / unstuck: ----------------------- rdmsr 0xCE: 80813e0011200 rdmsr 0x1AD: 1919191b rdmsr 0x610: 800080aa00dc8088 rdmsr 0x614: 88 rdmsr 0x648: 12 rdmsr 0x649: 80070 rdmsr 0x64A: 0 rdmsr 0x64B: 0 rdmsr 0x64C: 11 AC disconnected: ---------------- rdmsr 0xCE: 80813e0011200 rdmsr 0x1AD: 1919191b rdmsr 0x610: 800080aa00dc8088 rdmsr 0x614: 88 rdmsr 0x648: 12 rdmsr 0x649: 80070 rdmsr 0x64A: 0 rdmsr 0x64B: 0 rdmsr 0x64C: 11 AC connected / stuck: --------------------- rdmsr 0xCE: 80813e0011200 rdmsr 0x1AD: 1919191b rdmsr 0x610: 800080aa00dc8088 rdmsr 0x614: 88 rdmsr 0x648: 12 rdmsr 0x649: 80070 rdmsr 0x64A: 0 rdmsr 0x64B: 0 rdmsr 0x64C: 11 These values are not different for connected vs unconnected. So we are not TDP limited. These values are not different for connected vs unconnected. So we are not TDP limited. I'm using currently Linux draco 4.6.2-1-MANJARO #1 SMP PREEMPT Wed Jun 8 11:00:08 UTC 2016 x86_64 GNU/Linux. The problem still exists. Today the issue is corelated with unability to charge battery, as mentioned in comment #1. And the going from stuck to unstuck is much harder (I can't "unlock" it for a 15 minutes for now...). Still, when working on battery, the CPU scales well. After some reconnects it looks like the battery started charging. * * * I've tried booting from ArchLinux iso installer image, i.e. using very clean and lightweight linux image, and the issue exists, too. So it looks like it is not related to my installed OS. * * * If I should deliver more info, please tell me what can I do. Errata: The batt is not charging or charging very, very, very slowly. It's still 10% for a half an hour.. Typically, Dell bios forces low CPU frequency when something is wrong with the power and / or it no longer recognizes the power adapter. However, such limiting should also apply when using the acpi-cpufreq CPU frequency driver. Thank you, Doug. I'll replace power adapter. (In reply to Marcin Nowak from comment #21) > After a few tests I can't reproduce the bug when intel_pstate is disabled > (cpu scales well, just the max is limited to 1801.000 MHz) Please note that when you are using the acpi-cpufreq CPU frequency scaling driver, CPU frequencies listed are what were asked for and may not be what you are actually getting. Also, "1801" means somewhere in the turbo range, with no indication as to where. You have to use turbostat to know for sure. Below is an example from my computer, where max non-turbo = 3.4GHz, and a CPU brun program is running on CPU 7: $ grep MHz /proc/cpuinfo cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 3401.000 $ sudo turbostat sleep 10 CPUID(7): No-SGX 10.000828 sec CPU Avg_MHz Busy% Bzy_MHz TSC_MHz - 472 12.53 3754 3411 0 3 0.09 3631 3411 4 1 0.02 3578 3411 1 3 0.09 3585 3411 5 1 0.04 3562 3411 2 2 0.05 3573 3411 6 1 0.03 3573 3411 3 1 0.02 3737 3411 7 3765 99.94 3754 3411 As a sanity check, I get my CPU burn programs to print something every so often, so that, once I have calibrated myself, I can calculate the approximate CPU frequency. Example: doug@s15:~/c$ taskset -c 7 ./test1 Elapsed: 175.75 s. Elapsed: 351.23 s. Whereas using powersave mode to lock the CPU frequency at 1.6 GHz (for my processor), I get: doug@s15:~/c$ taskset -c 7 ./test1 Elapsed: 409.56 s. 1600 MHz * 409.56 / 175.75 = 3729 MHz Therefore sanity check is O.K. (In reply to Marcin Nowak from comment #40) > Thank you, Doug. I'll replace power adapter. I say again, both CPU scaling drivers should be affected, not just intel_pstate. So something still doesn't make sense. I've found an info that it may be related to Intel SpeedStep. The issue is reproducible when Intel SpeedStep is enabled in my bios. When I disable it, all cpu cores are stuck at ~800MHz (on AC, on battery, with powersave and performance governors). I don't know how it should work when SpeedStep is disabled. I read somewhere that some "crappy" bioses will disable turbo mode. I have that one, I think. Or I have a hardware failure, as somebody suggsted earlier. In that case I'm going to buy a new laptop. Let's don't waste more time for it. Thank you for your help and patience. Marcin I am experiencing the same issue. Some discussion has taken place on: http://askubuntu.com/questions/802170/cpu-frequency-is-always-at-minimum-even-if-cpu-isage-is-100 A workaround is known there. Do you need any experimental results, Doug Smythies? @Dugi: O.K. thanks for coming here and adding to this bug report. I'll copy and paste my last entry from our chat over on ask.ubuntu.com. I do not see anything special in the pstate-frequency program, but might have missed something, so I think we should be able to use primitive commands to achieve the same result. Using the intel_pstate CPU frequency driver, and with all CPU under full load, such that the problems exists, what do you get for: cat /sys/devices/system/cpu/intel_pstate/turbo_pct cat /sys/devices/system/cpu/intel_pstate/num_pstates cat /sys/devices/system/cpu/intel_pstate/min_perf_pct cat /sys/devices/system/cpu/intel_pstate/max_perf_pct cat /sys/devices/system/cpu/intel_pstate/no_turbo sudo cat /sys/kernel/debug/pstate_snb/sample_rate_ms sudo cat /sys/kernel/debug/pstate_snb/setpoint sudo grep . /sys/devices/system/cpu/cpufreq/policy0/* Anything you can observe in /sys/class/power_supply @Chen Yu: Marcin's trace data suggests that something external to the intel_pstate driver is holding the pstate at minimum. However, I haven't been able to figure out what. Dugi looked at: cat /sys/devices/system/cpu/cpufreq/policy0/bios_limit while using the acpi-cpufreq driver, and that wasn't it (and that is what I am used to seeing Dell use). Dugi also looked at what pstates were been asked for and what pstates are actually been given (MSRs 0x198 and 0x199), and it didn't seem to be ramping up properly either. I still think this is a Dell AC adpater problem, but: Would like to sure; Would like to know how to identify it as such, quickly in the future. I was trying to check if the problem was a problem of my installation or generally a problem of this version of Ubuntu, so I booted Ubuntu from a USB stick. The problem was still in place. The battery started charging and now it's fully charged. The problem cannot be replicated now, the CPU clock works as it's supposed to. I recall that the battery problem reappears after some time, so it's quite likely that the problem will return. I will report back then. pstate-frequency 3.4.0 does not work for me. CPU is still locked at 800MHz on AC. Enabling "auto" mode makes incorrect max_perf_pct and sometimes is disabling turbo. No luck here. I'm pretty sure that I have a problem with something like charging circuit. I've noticed problems with battery charging, and I did some checks in Dell Diagnostics recently. "Current battery flow was" ~0mA, AC adapter was recognized as 255 watt (which is invalid AFAIK), status was "Charging" but nothing were changed. After few touches of AC connector battery charging has begun, AC adapter was recognized properly, and current flow grown to ~1.5A or something like that. @Marcin Nowak What helped me was the "max" mode, other modes did nothing. @Dugi yes, I've tried "max" mode, but without luck for me. You can check what your Dell Diagnostics shows about battery/AC. Maybe there are two independent problems. @Marcin Nowak It would be quite a coincidence that we have the same two rare problems. Furthermore, the fact that my problem vanished at similar time as my battery got charged (after two weeks) is even more unlikely. I can't install Dell Diagnostics, it won't let me click on the I agree with the licence button. I've tried all browsers I have. @Dugi, my Inspiron has Diagnostics accessible from BIOS from "Boot options" menu (hit a F12 key when booting). Mine doesn't. The stupid UEFI gives me access to almost nothing. I've tried another browser, this time webkit based, but the stupid website won't let me get to it. I have saved the page, edited it locally and it gave me only a Windows executable, which is useless since I broke my Windows some time ago and it's not bootable. This is what I get when I print the contents of /sys/class/power_supply/BAT0/ File: alarm 0 File: capacity 127 File: capacity_level Full File: charge_full 3135000 File: charge_full_design 4000000 File: charge_now 4000000 File: current_now 1000 File: cycle_count 0 File: device cat: device: Is a directory File: manufacturer SANYO File: model_name DELL TPMCF2C File: power cat: power: Is a directory File: present 1 File: serial_number 2519 File: status Full File: subsystem cat: subsystem: Is a directory File: technology Li-ion File: type Battery File: uevent POWER_SUPPLY_NAME=BAT0 POWER_SUPPLY_STATUS=Full POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000 POWER_SUPPLY_VOLTAGE_NOW=12475000 POWER_SUPPLY_CURRENT_NOW=1000 POWER_SUPPLY_CHARGE_FULL_DESIGN=4000000 POWER_SUPPLY_CHARGE_FULL=3135000 POWER_SUPPLY_CHARGE_NOW=4000000 POWER_SUPPLY_CAPACITY=127 POWER_SUPPLY_CAPACITY_LEVEL=Full POWER_SUPPLY_MODEL_NAME=DELL TPMCF2C POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER= 2519 File: voltage_min_design 11100000 File: voltage_now 12475000 File: power/async disabled File: power/autosuspend_delay_ms cat: power/autosuspend_delay_ms: Input/output error File: power/control auto File: power/runtime_active_kids 0 File: power/runtime_active_time 0 File: power/runtime_enabled disabled File: power/runtime_status unsupported File: power/runtime_suspended_time 0 File: power/runtime_usage 0 This is what I get for AC power: File: power/async disabled File: power/autosuspend_delay_ms cat: power/autosuspend_delay_ms: Input/output error File: power/control auto File: power/runtime_active_kids 0 File: power/runtime_active_time 0 File: power/runtime_enabled disabled File: power/runtime_status unsupported File: power/runtime_suspended_time 0 File: power/runtime_usage 0 File: power/wakeup enabled File: power/wakeup_abort_count 0 File: power/wakeup_active 0 File: power/wakeup_active_count 1 File: power/wakeup_count 1 File: power/wakeup_expire_count 0 File: power/wakeup_last_time_ms 990 File: power/wakeup_max_time_ms 2 File: power/wakeup_total_time_ms 2 After replacing power adapter CPU scaling back to (almost) normal. On AC it scales up to 2499MHz (when turbo is on), and on battery downscales to ~800MHz. I have a little trouble with disabling turbo mode after disconnecting AC - it's not getting enabled after reconnecting AC and CPU goes up to ~1699.945. But it may be related to TLP or something like that. Calling pstate-frequency with plan set to "max" solves the issue. @Dugi, thanks for pstate-freq tip. -- @Doug, thanks for a tip about Dell bioses and power issues! It looks like the BIOS (or something else) was forcing CPU to minimum when AC was connected but when battery wasn't charging. -- @Chen, @Srinivas - thank you for focusing on my issue and helping me with solving the problem. Also many thanks to everyone who also was involved in my issue. -- @Dugi, try to find and run some Dell Diagnostics before digging the problem in kernel or other software. I wasted hundreds of hours for searching problem in a wrong place, probably same for people from Intel mentioned here. I saw many posts related to Dell-AC power problems, faulty bioses, etc. Google it first and check everything related to your laptop. It may be hardware issue, so call to Dell support if you have warranty. Feel free to email me if you have some questions related to this issue. Marcin. Interesting. After slightly discharging the battery, the problem is back. I can collect some more information if requested, as long as it does not concern Dell Diagnostics to which I don't have access. My response time will be bad in the near future. @Dugi: I (still) think your problem is your Dell AC power adapter. Is there any way you could borrow one from a friend or something, as a test? (In reply to Dugi from comment #49) > @Marcin Nowak > It would be quite a coincidence that we have the same two rare problems. It actually isn't that rare. @Doug Smythies I am not able to do it right now. I will report back when I get to try it, but it will not be too soon. Still, I am not really sure how could an AC adapter that doesn't seem to have any trouble feeding sufficient power to the computer cause all of this. @Dugi, my AC adapter was powering laptop but not always charging the battery. It looks like there are seperate ciricuts, for powering and charging. Currently, while stressing my CPU (stress -p 4), I'm observing sequence where on battery it works at ~800MHz, and when connecting AC it upscales to max freq, then downscales for a ~second to 800MHz and upscales againg to max. When using the old AC adapter the CPU was stuck at 800MHz (not always and I was able to "switch" betwen stuck and unstuck, what was very misleading). That was repeatable for months. Last days, just after Doug's comment, the adapter stopped charging battery completely (fortunately!) and I replaced it. The only one thing that I don't understand is why on the old AC adapter CPU was working at max freq after disconnecting AC (currently it is working at MIN freq after disconnecting AC). Maybe this is related to some bugs in Dell's BIOS routines. Marcin Another report: The problem is becoming even weirder. I have disabled intel_pstate in /etc/default/grub. Now, ACPI should control the CPU. I can set the CPU frequency to higher values and these higher values are reported by lscpu, but the performance is terrible. If I unplug the AC power, everything becomes much more fluent and performance-heavy tasks are completed way faster. Meanwhile, the battery sometimes does charge, and when it charged, the problem disappeared for a while. I will try to get another AC power source when possible. The pstate-frequency trick does not always work, which means that there is no clear way to get past this issue except for fixing the underlying hardware issue. (In reply to Dugi from comment #57) > Another report: > > The problem is becoming even weirder. I have disabled intel_pstate in > /etc/default/grub. Now, ACPI should control the CPU. I can set the CPU > frequency to higher values and these higher values are reported by lscpu, > but the performance is terrible. It is very important to know that when using the acpi-cpufreq CPU frequency scaling driver, the system reports CPU frequencies (pstates, actually) that have been asked for, and may not be what you actually get. You need to use turbostat to know for sure. see also my comment 41 above. > If I unplug the AC power, everything > becomes much more fluent and performance-heavy tasks are completed way > faster. > > Meanwhile, the battery sometimes does charge, and when it charged, the > problem disappeared for a while. I will try to get another AC power source > when possible. Due to the ID pin stuff, it should be the correct Dell part. > > The pstate-frequency trick does not always work, which means that there is > no clear way to get past this issue except for fixing the underlying > hardware issue. Agreed. Please report back whenever you can. Eventually we will want to close this bug report, as it is invalid with respect to the intel_pstate CPU frequency scaling driver. I have found the root cause. There was a piece of black cloth in the (black) power socket in the laptop. It was invisible until I put a spotlight right in front of it. When I removed it, charging and CPU frequency is back in normal. However, I still don't understand why the processor frequency is minimal when the battery is not charging but AC power is present. Hello I've come to the conclusion that this is a general hardware problem. I arrived here by having the exact same problem on a Razer Laptop (RZ09-02393E31) searching the web for answers with similar symptoms. This is my attempt at a hypothesis for my problem. I like most, use USB-C for our charging ports. How power delivery is managed is what I'll be explaining here. If my explanations are not enough please seek further detail by looking up USB-PD(Power Delivery) protocols. When you plug "in", the device seeking to charge will send a signal to the charger to indicate the desired Voltage and Amperage. (I don't understand how the voltage is set.) The Amperage is set by reading the resistance on signal lines CC1 and CC2. (Both serve the same purpose and are used for bi-directional cabling). The higher the resistance the less amperage the charger will send. Sometimes lint, powder, dust and other particles get stuck inside of our ports or cables. The physical obstruction increased resistance and therefore lowers amperage. When this happens the computer (either through the kernel, bios, or other mechanisms) will clock down it's frequency. This is also why reproducing the issue can be difficult. If your battery is charging very slowly this is the most likely culprit. Using an external power meter in between the charger and charging device would be more accurate. Once the charger is removed the amperage jumps back up and performance increase follows. Of course the problem can also be any other part of the circuitry responsible for power delivery to your system. Could be the charger, cable, port, negotiating chip/resistor or others. Please correct me if I'm wrong or if you have more information to help flesh out the problem/solution in greater detail. Hope that helps. |