If I plug in my AC adapter, the system suddenly becomes a lot less responsive. The issue disappears again when I remove the AC adapter. Any hints on how to debug this? The System is a Samsung NP535U3C-A04DE with AMI UEFI BIOS in CMS mode. Also noteworthy: Acpi is a bit confused about what's going on and shows the battery is discharging (but it isn't), while correctly stating the AC adapter to be online: acpi -V Battery 0: Discharging, 98%, 11:09:10 remaining Battery 0: design capacity 6100 mAh, last full capacity 6100 mAh = 100% Adapter 0: on-line Thermal 0: ok, 55.0 degrees C Thermal 0: trip point 0 switches to mode critical at temperature 105.0 degrees C Thermal 0: trip point 1 switches to mode passive at temperature 93.0 degrees C Cooling 0: LCD 0 of 50 Cooling 1: Processor 0 of 10 Cooling 2: Processor 0 of 10
Created attachment 100221 [details] dmesg 3.8.5
Created attachment 100231 [details] lspci
Created attachment 100241 [details] lspci -v
acpidump output please: # acpidump > acpidump.txt Do you always have this problem or it occurred from some kernel version? Thanks.
Created attachment 100641 [details] acpidump.txt
I haven't tried much in earlier kernel versions. Any versions I should try in particular? Thanks!!!
I've done some basic testing to get some numbers. It turns out the system is about 3x as fast if it's not charging: http://openbenchmarking.org/result/1307021-AR-CHARGESLO11 Could I have some feedback on the Kernel versions? Are there any particular ones of interest? Thank you.
Very interesting is also the performance progression with charging: (seconds it took for the test to complete while continually charging from about 80% to about 93%: 243.73375082016 214.5262761116 198.98797297478 184.98508787155 147.39234185219 123.78483009338 ... 79.097593069077 78.681077003479 74.135907173157 71.588815927505 67.320019006729 66.545222043991
No any particular kernel version, just want to know if this is a regression or it always has this problem.
Ah, ok. I have always had this problem.
Possible to run powertop? You can check idle stats and freq stats when running the tests with AC charged and not charged.
Thank you, that's a great idea! I will do that! Now I first have to discharge my system somewhat, because as you saw the effect is very low with a high charge. 2013/7/2 <bugzilla-daemon@bugzilla.kernel.org> > https://bugzilla.kernel.org/show_bug.cgi?id=57271 > > > > > > --- Comment #11 from Aaron Lu <aaron.lu@intel.com> 2013-07-03 01:21:15 > --- > Possible to run powertop? You can check idle stats and freq stats when > running > the tests with AC charged and not charged. > > -- > Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
Looks like samsung notebook's common problem, EC bug in ACPI table and anything relies on that fail. It's possible that Linux doesn't read AC/battery status correctly due to EC bug so when AC is connected, Linux was told it's not, thus limiting CPU frequency to lowest possible value. A work around you can try: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c35
Yes. It does seem related. I always thought the AC charging state issue is unrelated. I'll add some powertop outputs now.
Created attachment 106833 [details] Powertop when charging from 65% upwards (html)
Created attachment 106834 [details] Powertop when discharging around 65% (html)
Also, I've tried the trick with resetting the battery. Did not have very much of an effect (at least not for very long) I think. If you want I can try to do some measurements before and after.
From powertop's output, it looks like the frequency stats are correct, i.e. it's not limited to the lowest frequency...
Created attachment 106835 [details] attachment-28562-0.html Yes, but there is definitely something weird. It might have something to do with Samsung's "quiet fan" functionality... the easy_slow_down_manager module does not function when I have the issue and AC plugged in, but it works when the AC is unplugged... (I can set it to 0 or 1) What it's set to does not seem to affect the speed by much though... 2013/7/8 <bugzilla-daemon@bugzilla.kernel.org> > https://bugzilla.kernel.org/show_bug.cgi?id=57271 > > --- Comment #18 from Aaron Lu <aaron.lu@intel.com> --- > From powertop's output, it looks like the frequency stats are correct, i.e. > it's not limited to the lowest frequency... > > -- > You are receiving this mail because: > You reported the bug. >
What is easy_slow_down_manager?
Created attachment 106871 [details] attachment-32042-0.html "Fan, brightness and WiFi controls for Samsung laptops", https://code.google.com/p/easy-slow-down-manager/. 2013/7/11 <bugzilla-daemon@bugzilla.kernel.org> > https://bugzilla.kernel.org/show_bug.cgi?id=57271 > > --- Comment #20 from Aaron Lu <aaron.lu@intel.com> --- > What is easy_slow_down_manager? > > -- > You are receiving this mail because: > You reported the bug. >
Did you notice any interrupt increased a lot after you have AC plugged in? You can check /proc/interrupts. Also, please check if gpe's status before and after plugging AC, see if any gpe occurred a lot: $ grep . /sys/firmware/acpi/interrupts/gpe*
(In reply to Aaron Lu from comment #22) > Did you notice any interrupt increased a lot after you have AC plugged in? No. > Also, please check if gpe's status before and after plugging AC, see if any > gpe occurred a lot: > $ grep . /sys/firmware/acpi/interrupts/gpe* I don't really notice a difference. I've tested with comparatively a high battery charge (70%) though. I'll try again with lower battery charge.
I've no more idea, I'll move it to platform driver see if they know better.
Issue is pretty much still there in 3.13 with radeon driver.
Could be related to https://bugzilla.kernel.org/show_bug.cgi?id=45461
Numbers with 3.13 and Radeon driver: Test is pbzip2 compression with phoronix. Battery: Test Results: 105.09106612206 104.86291503906 104.28584885597 Average: 104.75 Seconds Charging: 138.17296910286 170.25011706352 164.56560707092 136.85453486443 138.0723760128 136.26100611687 Average: 147.36 Seconds
Created attachment 124611 [details] phoronix results in 3.13
(phoronix-test-suite run pts/compress-pbzip2) It appears that the fix from here: https://bugzilla.kernel.org/show_bug.cgi?id=45461#c113 discussed and solved here https://bugzilla.kernel.org/show_bug.cgi?id=44161#c129 also helps for this test / fixes this issue. I now see an average of ~88 seconds when charging, hence it's even better than on battery before. So there is apparently a solution, now it just needs to be made into a kernel patch and sent upstream.
Created attachment 127071 [details] performance with different loads, some using the discussed fix
The fix was definitely working. Let's hope the patch quickly makes it upstream.