|Summary:||System slows down when AC plugged in on Samsung NP535U3C-A04DE|
|Product:||Drivers||Reporter:||Dennis Jansen (dennis.jansen)|
Powertop when charging from 65% upwards (html)
Powertop when discharging around 65% (html)
phoronix results in 3.13
performance with different loads, some using the discussed fix
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 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 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 <email@example.com> > https://bugzilla.kernel.org/show_bug.cgi?id=57271 > > > > > > --- Comment #11 from Aaron Lu <firstname.lastname@example.org> 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 <email@example.com> > https://bugzilla.kernel.org/show_bug.cgi?id=57271 > > --- Comment #18 from Aaron Lu <firstname.lastname@example.org> --- > 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 <email@example.com> > https://bugzilla.kernel.org/show_bug.cgi?id=57271 > > --- Comment #20 from Aaron Lu <firstname.lastname@example.org> --- > 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.