Bug 57271

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.