[Samsung NP550P5C-T01AR] High CPU load after resuming on in BIOS mode

Bug #1223851 reported by Agustin Barto
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linux
Unknown
Unknown
linux (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Description of problem:

After I resume the system and plug something in one of the machine's USB3 ports, the CPU load raises to 50%, with one particular process with the highest load:
4 root 20 0 0 0 0 R 50.1 0.0 1:43.63 kworker/0:0

WORKAROUND: It doesn't happen if I plug the same device on a USB2 port.

WORKAROUND: I noticed that the ACPI dumps differed when the "USB S3 Wake-Up" was enabled or disabled, so what I took the DSDT for when the option is enabled, recompiled it, and forced it using the instructions given in http://blog.michael.kuron-germany.de/2011/03/patching-dsdt-in-recent-linux-kernels-without-recompiling/ . I then disabled the option (so the laptop won't turn itself on when it's in the bag). So far, I haven't seen any storms when plunging stuff into the USB3 ports and the box stays off at suspend.

The problem seems to be caused by too many ACPI interrupts:
root@ubuntu:~# grep -r . /sys/firmware/acpi/interrupts/
/sys/firmware/acpi/interrupts/sci:12554973
/sys/firmware/acpi/interrupts/error: 0
/sys/firmware/acpi/interrupts/gpe00: 0 invalid
/sys/firmware/acpi/interrupts/gpe01: 0 invalid
/sys/firmware/acpi/interrupts/gpe02: 0 enabled
/sys/firmware/acpi/interrupts/gpe03: 0 disabled
/sys/firmware/acpi/interrupts/gpe04: 0 disabled
/sys/firmware/acpi/interrupts/gpe05: 0 disabled
/sys/firmware/acpi/interrupts/gpe06: 0 enabled
/sys/firmware/acpi/interrupts/gpe07: 0 invalid
/sys/firmware/acpi/interrupts/gpe08: 0 invalid
/sys/firmware/acpi/interrupts/gpe09: 0 disabled
/sys/firmware/acpi/interrupts/gpe10: 0 invalid
/sys/firmware/acpi/interrupts/gpe11: 0 invalid
/sys/firmware/acpi/interrupts/gpe12: 0 invalid
/sys/firmware/acpi/interrupts/gpe13: 0 invalid
/sys/firmware/acpi/interrupts/gpe14: 0 invalid
/sys/firmware/acpi/interrupts/gpe15: 0 invalid
/sys/firmware/acpi/interrupts/gpe16: 0 invalid
/sys/firmware/acpi/interrupts/gpe0A: 0 invalid
/sys/firmware/acpi/interrupts/gpe17: 1504 enabled
/sys/firmware/acpi/interrupts/gpe0B: 0 disabled
/sys/firmware/acpi/interrupts/gpe18: 0 invalid
/sys/firmware/acpi/interrupts/gpe0C: 0 disabled
/sys/firmware/acpi/interrupts/gpe19: 0 invalid
/sys/firmware/acpi/interrupts/gpe0D:12553562 enabled
/sys/firmware/acpi/interrupts/gpe0E: 0 disabled
/sys/firmware/acpi/interrupts/gpe20: 0 disabled
/sys/firmware/acpi/interrupts/gpe0F: 0 invalid
/sys/firmware/acpi/interrupts/gpe21: 0 invalid
/sys/firmware/acpi/interrupts/gpe22: 0 invalid
/sys/firmware/acpi/interrupts/gpe23: 0 invalid
/sys/firmware/acpi/interrupts/gpe24: 0 invalid
/sys/firmware/acpi/interrupts/gpe25: 0 disabled
/sys/firmware/acpi/interrupts/gpe26: 0 invalid
/sys/firmware/acpi/interrupts/gpe1A: 0 invalid
/sys/firmware/acpi/interrupts/gpe27: 0 invalid
/sys/firmware/acpi/interrupts/gpe1B: 0 invalid
/sys/firmware/acpi/interrupts/gpe28: 0 invalid
/sys/firmware/acpi/interrupts/gpe1C: 0 invalid
/sys/firmware/acpi/interrupts/gpe29: 0 invalid
/sys/firmware/acpi/interrupts/gpe1D: 0 invalid
/sys/firmware/acpi/interrupts/gpe1E: 0 enabled
/sys/firmware/acpi/interrupts/gpe30: 0 invalid
/sys/firmware/acpi/interrupts/gpe1F: 0 enabled
/sys/firmware/acpi/interrupts/gpe31: 0 invalid
/sys/firmware/acpi/interrupts/gpe32: 0 invalid
/sys/firmware/acpi/interrupts/gpe33: 0 invalid
/sys/firmware/acpi/interrupts/gpe34: 0 invalid
/sys/firmware/acpi/interrupts/gpe35: 0 invalid
/sys/firmware/acpi/interrupts/gpe36: 0 invalid
/sys/firmware/acpi/interrupts/gpe2A: 0 invalid
/sys/firmware/acpi/interrupts/gpe37: 0 invalid
/sys/firmware/acpi/interrupts/gpe2B: 0 invalid
/sys/firmware/acpi/interrupts/gpe38: 0 invalid
/sys/firmware/acpi/interrupts/gpe2C: 0 invalid
/sys/firmware/acpi/interrupts/gpe39: 0 invalid
/sys/firmware/acpi/interrupts/gpe2D: 0 invalid
/sys/firmware/acpi/interrupts/gpe2E: 0 invalid
/sys/firmware/acpi/interrupts/gpe2F: 0 invalid
/sys/firmware/acpi/interrupts/gpe3A: 0 invalid
/sys/firmware/acpi/interrupts/gpe3B: 0 invalid
/sys/firmware/acpi/interrupts/gpe3C: 0 invalid
/sys/firmware/acpi/interrupts/gpe3D: 0 invalid
/sys/firmware/acpi/interrupts/gpe3E: 0 invalid
/sys/firmware/acpi/interrupts/gpe3F: 0 invalid
/sys/firmware/acpi/interrupts/sci_not: 0
/sys/firmware/acpi/interrupts/ff_pmtimer: 0 invalid
/sys/firmware/acpi/interrupts/ff_rt_clk: 0 disabled
/sys/firmware/acpi/interrupts/gpe_all:12556159
/sys/firmware/acpi/interrupts/ff_gbl_lock: 0 disabled
/sys/firmware/acpi/interrupts/ff_pwr_btn: 0 enabled
/sys/firmware/acpi/interrupts/ff_slp_btn: 0 invalid

I can mitigate the problem by disabling that particular source

# echo disable > /sys/firmware/acpi/interrupts/gpe0D

This also happens on Fedora 19 but doesn't happen on Ubuntu 13.04, so it seems the bug was introduced after the 3.8 kernel.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-5-generic 3.11.0-5.11
ProcVersionSignature: Ubuntu 3.11.0-5.11-generic 3.11.0
Uname: Linux 3.11.0-5-generic x86_64
ApportVersion: 2.12.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ubuntu 4220 F.... pulseaudio
CasperVersion: 1.336
Date: Wed Sep 11 12:31:17 2013
LiveMediaBuild: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130910)
MachineType: SAMSUNG ELECTRONICS CO., LTD. 550P5C/550P7C
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: initrd=/casper/initrd.lz file=/cdrom/preseed/hostname.seed boot=casper quiet splash -- persistent BOOT_IMAGE=/casper/vmlinuz.efi
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-5-generic N/A
 linux-backports-modules-3.11.0-5-generic N/A
 linux-firmware 1.113
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/18/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P08AAA.045.130418.dg
dmi.board.asset.tag: No Asset Tag
dmi.board.name: SAMSUNG_NP1234567890
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: SEC_SW_REVISION_1234567890ABCD
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP08AAA.045.130418.dg:bd04/18/2013:svnSAMSUNGELECTRONICSCO.,LTD.:pn550P5C/550P7C:pvrP08AAA:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSAMSUNG_NP1234567890:rvrSEC_SW_REVISION_1234567890ABCD:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvrN/A:
dmi.product.name: 550P5C/550P7C
dmi.product.version: P08AAA
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.

Revision history for this message
Agustin Barto (abarto) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Re: High CPU load after resuming on Samsung NP550P5C in BIOS mode

I'd like to perform a bisect to figure out what commit caused this regression. We need to identify the earliest kernel where the issue started happening as well as the latest kernel that did not have this issue.

Can you test the following kernels and report back? We are looking for the first kernel version that exhibits this bug:

v3.8 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-raring
v3.9 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-saucy
v3.10 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-saucy
v3.11-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11-rc1-saucy/

You don't have to test every kernel, just up until the kernel that first has this bug.

Thanks in advance!

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
tags: added: performing-bisect
Revision history for this message
Agustin Barto (abarto) wrote :

The issue is not present in the latest raring kernel (linux-image-3.8.0-30-generic), but it's present on linux-image-3.9.0-030900-generic.

Revision history for this message
Agustin Barto (abarto) wrote :

The issue is not present in linux-image-3.8.13-03081307-generic, so it's between this and linux-image-3.9.0-030900-generic.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

It sounds like this bug was introduced in v3.9. In order to bisect, we need to identify the last good and first bad kernel versions.

Can you test the following kernels and report back? We are looking for the earliest kernel version that exhibits this bug:

v3.9-rc4: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc4-saucy/

If v3.9-rc4 does not exhibit the bug then test v3.9-rc6:
v3.9-rc6: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc6-saucy/

If v3.9-rc4 does exhibit the bug then test v3.9-rc2:
v3.9-rc2: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc2-saucy

You don't have to test every kernel, just up until the kernel that first has this bug.

Thanks in advance!

Revision history for this message
Agustin Barto (abarto) wrote :

I had a lot of problems resuming with most of rc kernels (the screen doesn't turn on), but I manage to test the bug. The problem is present in rc1, 2, 3, and 4.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Can you confirm the bug does not exist in upstream v3.8 final:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-raring/

If it does not, we can bisect between v3.8 final and v3.9-rc1.

Revision history for this message
Agustin Barto (abarto) wrote :

I can't test whether the bug is there or not because the system barely works. I tried the same trick I used to test the 3.9rc* (booting in recovery mode and using pm-suspend) but that didn't work. Notice that with the current kernel (linux-image-3.8.0-30-generic) works just fine.

Revision history for this message
Agustin Barto (abarto) wrote :

The issue is still present in 3.11.1-031101-generic.

Revision history for this message
Agustin Barto (abarto) wrote :

The issue is still present in Ubuntu 13.10 Beta2.

Revision history for this message
Agustin Barto (abarto) wrote :

The issue is still present in 3.11.0-12-generic

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

The v3.12-rc4 kernel is now available. Can you test this kernel, which can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc4-saucy/

Revision history for this message
Agustin Barto (abarto) wrote :

The issue is still present in linux-image-3.12.0-031200rc4-generic

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

It might be good to open an upstream bug report, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

Once this bug is reported upstream, please add the tag: 'kernel-bug-reported-upstream'.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Revision history for this message
Agustin Barto (abarto) wrote :

An e-mail was sent to <email address hidden> with the relevant information.

Revision history for this message
Agustin Barto (abarto) wrote :

I had to send another e-mail [0] because the report for the first one was generated using the wrong kernel version.

[0] http://marc.info/?l=linux-acpi&m=138170536231873&w=2

Revision history for this message
Agustin Barto (abarto) wrote :

I found a workaround for the problem. Enabling the "USB S3 Wake-Up" BIOS option seems to fix this problem. I had it turned off since I bought the machine, but I guess something was introduced in 3.9 that triggers the issue. Judging from the amount of ACPI related issues on Samsung laptops, a true solution for the problem would be to never install Linux on them.

Revision history for this message
Agustin Barto (abarto) wrote :

I tried the latest kernel version (3.12.0-031200-generic) from Ubuntu's kernel PPA and the issue is no longer present.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

That's good news. Can you also give the latest upstream 3.11.7 stable kernel a test to see if the fix in 3.12 was also sent to stable?

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.7-saucy/

tags: added: kernel-bug-fixed-upstream
Changed in linux (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Agustin Barto (abarto) wrote :

3.11.7 works fine too

Revision history for this message
Agustin Barto (abarto) wrote :

Just to make sure I went back to 3.11.0 and I couldn't reproduce the issue. I think installing the Intel MEI drivers on Windows (this is a dual boot box) did something. Weird.

Revision history for this message
Agustin Barto (abarto) wrote :

Nevermind, the bug is still there on 3.11.0, 3.11.7 and 3.12.0. I had left the "USB S3 Wake-Up" option enabled by mistake.

tags: added: kernel-bug-exists-upstream
removed: kernel-bug-fixed-upstream
Revision history for this message
Agustin Barto (abarto) wrote :

I found a proper work-around for the problem. I noticed that the ACPI dumps differed when the "USB S3 Wake-Up" was enabled or disabled, so what I took the DSDT for when the option is enabled, recompiled it, and forced it using the instructions given in [1]. I then disabled the option (so the laptop won't turn itself on when it's in the bag). So far, I haven't seen any storms when plunging stuff into the USB3 ports and the box stays off at suspend.

Now I can wait until the bug is fixed or until I manage to get rid of this piece of crap. I'd avoid Samsung laptops if I were you. They're Linux support is atrocious.

Revision history for this message
Agustin Barto (abarto) wrote :
penalvch (penalvch)
description: updated
tags: added: needs-full-computer-model needs-upstream-testing regression-release
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Agustin Barto (abarto) wrote :

The model code is NP550P5C-T01AR. It's an Argentinean model. The only difference with the factory model is the harddrive (which I had to replace because the original died a month after I bought it) and the RAM, which I bumped to 16Gb.

penalvch (penalvch)
summary: - High CPU load after resuming on Samsung NP550P5C in BIOS mode
+ [Samsung NP550P5C-T01AR] High CPU load after resuming on in BIOS mode
penalvch (penalvch)
tags: removed: needs-full-computer-model
tags: added: kernel-bug-exists-upstream-v3.12-rc4
removed: kernel-bug-exists-upstream
description: updated
penalvch (penalvch)
Changed in linux (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Agustin Barto (abarto) wrote :

I've bisected the commit the causes the issue upstream and now there's a patch [1] that fixes the problem. Thanks for the help.

[1] https://bugzilla.kernel.org/attachment.cgi?id=119601

Revision history for this message
penalvch (penalvch) wrote :

Agustin Barto, thank you for fully commit bisecting the kernel. Given the root cause is suspected to be a poorly written BIOS version, and because Samsung does not easily reveal what the latest BIOS is for this model, could you please download the latest firmware software as per http://www.samsung.com/ar/support/model/NP550P5C-T01AR-downloads, and advise if a BIOS update is available? If so, when you update to this, does it change anything? If it doesn't, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful.

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Thank you for your understanding.

tags: added: bisect-done needs-bios-check
removed: performing-bisect
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Agustin Barto (abarto) wrote :

I was already using the latest BIOS version when I reported the issue. This is the output of
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date:

P08AAA.045.130418.dg
04/18/2013

penalvch (penalvch)
Changed in linux (Ubuntu):
status: Incomplete → Triaged
tags: added: latest-bios-04-18-2013
removed: needs-bios-check
Revision history for this message
Agustin Barto (abarto) wrote :

This issue was fixed upstream [1] and can be closed.

[1] https://patchwork.kernel.org/patch/3407631/

Revision history for this message
penalvch (penalvch) wrote :

Agustin Barto, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1223851/comments/31 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in linux (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.