Bug 57271 - System slows down when AC plugged in on Samsung NP535U3C-A04DE
System slows down when AC plugged in on Samsung NP535U3C-A04DE
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Product: Drivers
Classification: Unclassified
Component: Platform_x86
All Linux
: P1 normal
Assigned To: drivers_platform_x86@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-29 09:10 UTC by Dennis Jansen
Modified: 2014-02-26 13:36 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.8.5-3.13
Tree: Mainline
Regression: No


Attachments
dmesg 3.8.5 (56.79 KB, text/plain)
2013-04-29 09:10 UTC, Dennis Jansen
Details
lspci (2.03 KB, text/plain)
2013-04-29 09:11 UTC, Dennis Jansen
Details
lspci -v (8.57 KB, text/plain)
2013-04-29 09:12 UTC, Dennis Jansen
Details
acpidump.txt (191.72 KB, text/plain)
2013-05-03 18:12 UTC, Dennis Jansen
Details
Powertop when charging from 65% upwards (html) (63.89 KB, text/html)
2013-07-08 06:49 UTC, Dennis Jansen
Details
Powertop when discharging around 65% (html) (62.75 KB, text/html)
2013-07-08 06:51 UTC, Dennis Jansen
Details
attachment-28562-0.html (1.23 KB, text/html)
2013-07-08 07:27 UTC, Dennis Jansen
Details
attachment-32042-0.html (1.05 KB, text/html)
2013-07-11 16:23 UTC, Dennis Jansen
Details
phoronix results in 3.13 (2.86 KB, application/xml)
2014-02-05 08:20 UTC, Dennis Jansen
Details
performance with different loads, some using the discussed fix (28.03 KB, image/png)
2014-02-22 17:47 UTC, Dennis Jansen
Details

Description Dennis Jansen 2013-04-29 09:10:08 UTC
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
Comment 1 Dennis Jansen 2013-04-29 09:10:53 UTC
Created attachment 100221 [details]
dmesg 3.8.5
Comment 2 Dennis Jansen 2013-04-29 09:11:44 UTC
Created attachment 100231 [details]
lspci
Comment 3 Dennis Jansen 2013-04-29 09:12:02 UTC
Created attachment 100241 [details]
lspci -v
Comment 4 Aaron Lu 2013-05-03 05:07:20 UTC
acpidump output please:
# acpidump > acpidump.txt

Do you always have this problem or it occurred from some kernel version? Thanks.
Comment 5 Dennis Jansen 2013-05-03 18:12:14 UTC
Created attachment 100641 [details]
acpidump.txt
Comment 6 Dennis Jansen 2013-05-03 18:14:16 UTC
I haven't tried much in earlier kernel versions. Any versions I should try in particular? Thanks!!!
Comment 7 Dennis Jansen 2013-07-02 18:20:29 UTC
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.
Comment 8 Dennis Jansen 2013-07-02 18:57:36 UTC
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
Comment 9 Aaron Lu 2013-07-03 00:42:51 UTC
No any particular kernel version, just want to know if this is a regression or it always has this problem.
Comment 10 Dennis Jansen 2013-07-03 01:17:36 UTC
Ah, ok. I have always had this problem.
Comment 11 Aaron Lu 2013-07-03 01:21:15 UTC
Possible to run powertop? You can check idle stats and freq stats when running the tests with AC charged and not charged.
Comment 12 Dennis Jansen 2013-07-03 01:23:57 UTC
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.
>
Comment 13 Aaron Lu 2013-07-08 06:26:26 UTC
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
Comment 14 Dennis Jansen 2013-07-08 06:48:23 UTC
Yes. It does seem related. I always thought the AC charging state issue is unrelated.


I'll add some powertop outputs now.
Comment 15 Dennis Jansen 2013-07-08 06:49:47 UTC
Created attachment 106833 [details]
Powertop when charging from 65% upwards (html)
Comment 16 Dennis Jansen 2013-07-08 06:51:37 UTC
Created attachment 106834 [details]
Powertop when discharging around 65%  (html)
Comment 17 Dennis Jansen 2013-07-08 06:54:14 UTC
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.
Comment 18 Aaron Lu 2013-07-08 07:21:10 UTC
From powertop's output, it looks like the frequency stats are correct, i.e. it's not limited to the lowest frequency...
Comment 19 Dennis Jansen 2013-07-08 07:27:24 UTC
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.
>
Comment 20 Aaron Lu 2013-07-11 08:32:37 UTC
What is easy_slow_down_manager?
Comment 21 Dennis Jansen 2013-07-11 16:23:02 UTC
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.
>
Comment 22 Aaron Lu 2013-07-15 06:53:01 UTC
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*
Comment 23 Dennis Jansen 2013-07-15 23:50:09 UTC
(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.
Comment 24 Aaron Lu 2013-12-19 07:06:51 UTC
I've no more idea, I'll move it to platform driver see if they know better.
Comment 25 Dennis Jansen 2014-02-04 21:40:07 UTC
Issue is pretty much still there in 3.13 with radeon driver.
Comment 26 Dennis Jansen 2014-02-04 21:43:45 UTC
Could be related to https://bugzilla.kernel.org/show_bug.cgi?id=45461
Comment 27 Dennis Jansen 2014-02-05 08:19:02 UTC
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
Comment 28 Dennis Jansen 2014-02-05 08:20:37 UTC
Created attachment 124611 [details]
phoronix results in 3.13
Comment 29 Dennis Jansen 2014-02-22 14:50:31 UTC
(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.
Comment 30 Dennis Jansen 2014-02-22 17:47:12 UTC
Created attachment 127071 [details]
performance with different loads, some using the discussed fix
Comment 31 Dennis Jansen 2014-02-26 13:36:18 UTC
The fix was definitely working. Let's hope the patch quickly makes it upstream.

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