Bug Hunting with Linux (The story of the Samsung Ultrabooks lid close / AC status bug)

If you have a Samsung laptop series 5 or series 9 from 2011 and 2012, you’ll find the following interesting.



If you have one of the following symptoms:

  • Lost the ability to get the laptop to sleep by closing the lid (both in windows and linux).
  • Linux doesn’t realize that you plugged or unplugged the power supply.
  • Windows takes many seconds to realize that you plugged or unplugged the power supply, instead of having immediate feedback.
  • Keyboard backlight doesn’t turn on at night (ambient light sensor events issue).

then it means that you have a “stuck” embedded controller.

For the anxious, I’ll let you know two more important facts, before getting into the story, the embedded controller talk, and the workaround fix:

  1. These issues are caused by an “unlucky” suspend/resume. If you never suspend your laptop, you’ll never get a stuck embedded controller.
  2. You can fix the symptoms temporarily by pushing the reset button through the small hole in the back of the laptop (the other side of the touchpad). The computer must be turned off and unplugged. After hitting the button, you’ll need to plug it to the wall to start for the first time. This is temporary and the issues will come back with a bad sleep / resume.

There is a permanent fix, which will not require you to hit the reset button. More on that later.

My end of the story:

I bought my Samsung ultrabook Series 5 in november 2013. I started noticing these issues during the first week. On that saturday I decided I had enough and spent the day trying to find a way to recover the lost functionality, and be able to go to suspend by closing the lid again. I figured that since the screen went off when closing the lid, it meant that the lid sensor was working fine, and that it must have been a BIOS or motherboard problem, since neither linux nor windows were capable of detecting the lid, wheras they both previously did.
I toggled all BIOS screen options and all Samsung Easy Settings options. None of this brought functionality back.
So I set out to reflash the BIOS, hoping that some hidden internal option causing this would get reset to default. But I quickly found out that Samsung bios update tool doesn’t let you flash the BIOS if it’s already the latest version. Long story short, that same saturday of november I found a way to do that and shared it here:
After flashing the same BIOS version over, the lid detection and power supply unit (PSU) detection started working fine again.

A few weeks later the syndrome came back. I reflashed the BIOS again and it got fixed once again. This time I realized that it came back right after resuming the laptop from sleep, so I refrained from suspending it in the future. Using the laptop bacame no-fun. It lost its cool.

Two months later, now February 2014, I became careless and started suspending the laptop again.

The issue came back.

Closing the lid was ignored, and the charging icon persisted even after unplugging the laptop from the wall.

I searched online once again for this issue, and this time I found a bug report in ubuntu’s launchpad website. In that thread I found a better way to fix the issue that didn’t involve reflashing a bios, but just involved hitting the reset button in the back, which I never noticed before:


Reading that forum, it quickly became obvious that they talked about the same problem, even though they mentioned different models. It confirmed to me that the issue was suspend related, and some posters suggested that the issue came back for sure when leaving the laptop suspended for a long time, though there was no precision as to why some suspensions didn’t trigger the bug and others did.

At first I just shared my own temporary fix (reflashing the bios), since I read that some folks thought that samsung fixed the issue with a new bios… though it is a temporary fix, not due to the new BIOS, but due to the act of flashing itself (which is actually because the embedded controller gets reset after a bios flash). And while sharing my own fix in post #97, I theorized that the “problem state” might be triggered by a poor implementation of Intel Rapid Start. Later I found I was wrong with Intel Rapid Start. It made some sense at the time to me, given that the posters said that a long time suspended triggered the issue and that Intel Rapid Start also gets triggered during suspend (by time or by battery low). I began to leave the laptop suspended overnight

Vacation time came from work. After a few days of recovering from lost hours of sleep, and having gone around the house fixing things (fawcets, etc.), getting up to date with housekeeping,  I gave a look at my ultrabook and thought to myself: “you’re next”. hahahaha

First I tried to put my theory of Intel Rapid Start interfering from sleep to the test. I had rapid start disabled since the day I bought it. So I thought that that could be the cause, I thought that the BIOS expected rapid start to be enabled and that when it didn’t find support for it the bug was triggered (but I was wrong). I enabled intel rapid start (this required me to resize the SSD partition to make room for a special hibernation partition). To enable intel rapid start, I had to do it from Easy Settings in windows, (otherwise, the INT3392 acpi device wouldn’t show up).  Having enabled it, I could now use the intel_irst module in linux, which had a /sys interface (wakeup_time and wakeup_events) to enable/disable rapid start triggers by time or battery, and to configure the time.
I started a text file keep a log of my tests.
I started leaving the laptop suspended for whole nights, trying different values for wakeup_time and wakeup_events.
I realized that they made absolutely no difference. Intel rapid start was ruled out as a cause.

I made further tests (see post #100 of the launchpad bug thread). Too many to mention here.

At the same time I studied my laptop’s DSDT. (Attached here). In case you don’t know: DSDT code is an almost platform independant code (it’s not assembler or machine code) provided by the BIOS to be run by the OS. This code is interpreted by the OS. It’s like “a driver provided by the BIOS” to be run and interpreted by linux or windows, to serve as an interface or glue. It’s different for each laptop, and when you update your BIOS, you are updating the DSDT too. The DSDT code is read once by the OS, on each boot, from the BIOS.

The DSDT showed that event handlers for LID and Battery status change were of course inplace, (_Q51, _Q52 (AC), _Q53, _Q54 _Q66 (Battery), _Q5E, _Q5F(LID)).

Searching for everything I needed to know regarding the production of those events, I found these two useful links, which gave me a break:



It goes like this: when battery changes one percent (up or down), or when you close the lid on your laptop, the Embedded Controller notices this, and produces an interrupt through the general purpose event 0x17 (other laptops might have different GPE for the EC). Code in the OS handles the interruption, and asks the EC for the exact event produced:

  • 0x51 and 0x52 for AC plugged or unplugged.
  • 0x53 and 0x54, and 0x66 for battery changed
  • 0x5E and 0x5F for LID closed or open

If the event has a status with 0x20 bit mask set, the OS runs the corresponding _Q## method of the DSDT to handle the event. In the case of the LID, the _Q5E() method could be called, and if the lid status was different than before, an ACPI event gets generated through a call to Notify(LID0, 0x80). Pretty much the same for AC (ADP1 device) and Battery (BAT1 device) status.

Now, because of my tests, (see post #100) I realized that there was a rythm to all this. Events were missing in the problem state, and there was an almost exact number of events which I pinpointed as 8 plugs/unplugs from AC when suspended (or some battery drop or increase during suspension), that put the laptop into the problem state again. The Embedded Controller was at the center of all this. I also found the quickest way to reproduce the issue and get into the “problem state”, to test potential fixes:

  1. Sleep the computer in linux (by closing the lid or any other means).
  2. Unplug from the wall, plug, unplug, plug, unplug, plug, unplug, plug (8 actions or more).
  3. Resume from sleep.

There is another way to get the laptop into the problem state that I discovered:

  1. echo disable > /sys/firmware/acpi/interrupts/gpe17
  2. plug, unplug, plug, unplug, plug, unplug, plug, unplug (8 actions)
  3. echo enable > /sys/firmware/acpi/interrupts/gpe17

Reading the presentation in this link provided me with the inspiration to try to query the embedded controller directly. Little did I know that that was all that was required to make it unstuck, and see events again being produced with “acpi_listen” in the console.

The Fix

I made this program to poll the events left in the embedded controller directly. I realized that it fixes the issue immediately (in the same way that hitting the reset button through the small hole in the back). You can run it at any time, but ideally run right after resume from suspend.

What we can deduce from this is that the Embedded Controller keeps trying to report events while the computer is suspended. Since there is no OS to reply to them, it accumulates them, and after a certain number of events (battery percentage drop or increase, AC plugged or unplugged, Lid open or closed, are all each one event), after a certain number of events, it stops producing GPE 0x17 and the OS doesn’t query them anymore… CLASSIC CHICKEN AND EGG situation!!! because the OS only queries the events when it receives a GPE interruption.

You can find it in post #102 of the launchpad issue. I’ll put it here too.

There is a better solution based on my research, that Lan Tianyu made as a patch to the kernel, waiting for further tests in the kernel bugzilla issue 44161, see comments #133 and #135 there, I confirmed that it does the same job perfectly as my workaround fix.  If that gets merged to the kernel someday, you won’t need my workaround anymore to enjoy your laptop. The kernel patch uses proper ec.c functions to query the Embedded Controller after resume from sleep, instead of direct port poking.

UPDATE (1) 2014-02-23: Kieran Clancy has made a better kernel patch and posted it on the usual kernel bugzilla, comment #149. I tested it and it does the job, perfectly as my userspace program workaround does, but from inside the kernel. It also unstucks the EC not only on resume but also on start.

UPDATE (2) 2014-02-23: I made a better workaround that doesn’t hardcode the EC port numbers as constants but instead reads them from /proc/ioports. It is a much safer workaround, and should work on any model. It also now sleeps for a millisecond between queries, which I found doesn’t query the same event more than once. It is now also GPL. It follows below (you can still find the original in the launchpad issue post #102).

UPDATE (3) 2014-03-01: The latest version of the fix in the form of a kernel patch by Kieran Clancy has been posted to linux-acpi and linux-kernel mailing lists: http://marc.info/?l=linux-acpi&m=139359680828880&w=2 You can still use my non-kernel workaround if you don’t want to recompile a new kernel. But this is great news, it means that the fix is moving towards being included by default some day in the kernel.

My workaround fix (Updated with version2, doesn’t hardcode EC ports anymore):

---- samsung_fix_ec_events.c ------------------------------------------
* samsung_fix_ec_events
* Copyright © 2014 Juan Manuel Cabo <juanmanuel.cabo@gmail.com>
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program.  If not, see <http://www.gnu.org/licenses/>.

#include <stdio.h>
#include <unistd.h>
#include <sys/io.h>
#include <string.h>
#include <stdlib.h>

 * Compile with:
 *    gcc -o samsung_fix_ec_events samsung_fix_ec_events.c
 * Run as:
 *    sudo ./samsung_fix_ec_events
 * You may copy it to /usr/local/bin/samsung_fix_ec_events and then call it 
 * automatically after resume from sleep with a /usr/lib/pm-utils/sleep.d script:
 *    sudo cp ./samsung_fix_ec_events /usr/local/bin/

/* Constants: */
enum ec_command {
    /* Standard command for querying LID, Battery and AC events: */

int get_ec_ports(int* ec_cmd_port, int* ec_data_port);

int main (int argc, char** argv) {
    char status = 0;
    char data = 0;
    int count = 0;

    /* Get EC data and command ports numbers from /proc/ioports */
    int ec_cmd_port = 0;
    int ec_data_port = 0;
    if (!get_ec_ports(&ec_cmd_port, &ec_data_port) || !ec_cmd_port || !ec_data_port) {
        fprintf(stderr, "Error: couldn't determine EC ports by looking in '/proc/ioports'.\n");
        return 1;
    printf("Using EC ports 0x%x and 0x%x\n", ec_cmd_port, ec_data_port);

    /* Ask for permition to use the EC ports for the duration of this execution only: */
    if (iopl(3)) {
        fprintf(stderr, "Error: Permission to read/write to EmbeddedController port not granted.\n");
        return 1;

    /* Query AC, Battery, LID, etc. events until there are no more. 
     * This clears them for the EC so that it can send them again in the future, thus unblocking the EC. */
    do {
        outb(ACPI_EC_COMMAND_QUERY, ec_cmd_port);
        status = inb(ec_cmd_port);
        data = inb(ec_data_port);
        printf("CommandQuery 0x84, status=0x%x, data=0x%x\n", status, data);
        usleep(1000); /* Give the EC 1ms time between queries */
    } while (data != 0 && ++count < 1000);

    printf("EmbeddedController GPE events flushed. New events can be produced now.\n");

    return 0;

/* Reads EC port addresses from /proc/ioports. Returns 1 if successful */
int get_ec_ports(int* ec_cmd_port, int* ec_data_port) {
    if (!ec_cmd_port || !ec_data_port) {
        return 0;
    *ec_cmd_port = 0;
    *ec_data_port = 0;

    /* Allocate line buffer on the heap for parsing */
    char* line_buffer = (char*) malloc(LINE_BUFFER_SIZE);
    if (!line_buffer) {
        return 0;

    /* Open ioports file */
    FILE* ioports_file = fopen("/proc/ioports", "r");
    if (!ioports_file) {
        return 0;

    /* Find ports 'EC data' and 'EC cmd' */
    char* line = NULL;
    while (line = fgets(line_buffer, LINE_BUFFER_SIZE, ioports_file)) {
        if (strstr(line, "EC cmd")) {
            if (sscanf(line, "%x", ec_cmd_port) != 1) {
                return 0;
        } else if (strstr(line, "EC data")) {
            if (sscanf(line, "%x", ec_data_port) != 1) {
                return 0;
    if (ec_cmd_port == 0 || ec_data_port == 0) {
        return 0;
    /* Found both ports successfully */
    return 1;
----END samsung_fix_ec_events.c ------------------------------------------

----- 99samsung_fix_ec_events ----------------------------------------------
# NOTE: Put this file in: /usr/lib/pm-utils/sleep.d/99samsung_fix_ec_events
# and do: chmod +x 99samsung_fix_ec_events
# On some samsung laptops (series 5 2012, series 9 2011, etc) , if many EC
# GPE events are produced during sleep (AC plugged/unplugged, battery % change
# change, LID open/close, etc), and they are not queried, the
# EmbeddedController stops sending them and this creates a chicken and egg
# situation, that can only be resolved either by hitting the reset button in
# the back while powered off, or by simply forcing a query for the events here after resume.

case "$1" in
        #NOTE: edit this path if necessary to point to the program with the fix:
    *) exit $NA

exit 0

----- END 99samsung_fix_ec_events -------------------------------------------

Affected Laptops

I want to thank the community so much for all the good feedback that I received. This bug has been causing frustration to many people since at least two years. I’m just happy that I found a diagnosis of it, and a solution, and that I could share it with all of you guys. In particular I want to thank Kieran Clancy for bringing my workaround fix to the attention of the linux kernel people, where a kernel patch has now been made and I guess is now waiting for further tests.

From the feedback I gathered so far, my fix works in the following models:

  • Samsung Series 5 (models NP530U3C, NP535U3C, NP530U3B, NP550P5C)
  • Samsung Series 9 (models NP900X3F, NP900X4B, NP900X4C, NP900X4D, NP900X3C)

there maybe more models out there affected by this issue. Mine is the NP530U3C (2012 Ivy Bridge i5 cpu, bought in november 2013). And there might be more problems solved by this than just the LID close detection and AC status detection. For instance, Dennis Jansen has numbers showing that it fixed performance issues with his laptop: https://bugzilla.kernel.org/show_bug.cgi?id=57271#c29 Its no surprise really, the embedded controller handles many tasks and provides a lot of different events.


Please, leave comments as desired here.

— Juan Manuel Cabo


72 thoughts on “Bug Hunting with Linux (The story of the Samsung Ultrabooks lid close / AC status bug)

  1. Hi Juan,

    thank you for the effort you took eliminating that frustrating problem which lasted so long. Im now very happy with my machine (NP900x3f). Good job and we need those people in our community having your attitude.

    Thank you and many greetings from Germany!

  2. Hi Juan,

    Thanks a lot for your hard work, this had been annoying me for the past year and a half and I’m glad to see this finally sorted.

    My eOS running ultrabook is now perfect thanks to you 🙂

  3. Sir Juan,

    You are THE MAN. I too have been working around this issue in bizarre ways (I thought having the laptop plugged in when resuming was causing it, but I would still charge it once suspended, so I would inadvertently trigger the problem after doing that a few times). This was becoming a serious issue, because if I accidentally plugged it in before resuming, it would be stuck thinking it was plugged in, and not warn me at all if I unplugged it and the battery died down. And this is saying nothing of the considerable power-saving measures being ignored because the system things it’s running off AC.

    I wish I could have sent you the smile on my face when I compiled your fix, ran it, unplugged the laptop, and saw the backlight auto-dim!!!

    You should set up a simple way to accept donations. I would gladly toss $5-$10 your way for the functionality it’s returned to me.

    Thank you, thank you, THANK YOU,

  4. Pingback: Bug Hunting with Linux (The story of the Samsung Ultrabooks lid close / AC status bug) | Hallow Demon

  5. Pingback: Links 27/2/2014: Instructionals | Techrights

  6. close lid suspend seems to work fine now.
    israel@israel-sam:~/Downloads$ uname -a
    Linux israel-sam 3.2.0-59-generic #90-Ubuntu SMP Tue Jan 7 22:43:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
    israel@israel-sam:~/Downloads$ sudo dmidecode | grep Product Product Name: 530U3BI/530U4BI/530U4BH
    btw, is there a way/tutorial on how to boot thru the flash drive?

    • > close lid suspend seems to work fine now.
      > Thanks!

      I’m glad!

      > btw, is there a way/tutorial on how to boot thru the flash drive?

      About booting to the SSD, the bios doesn’t see it as a bootable drive.
      I have a 24GB SSD alongside a 500GB HDD. I have linux installed to the SSD, and the /home and windows partitions in the HDD.
      What I did was use a free program called EasyBCD to add linux in the SSD to the windows boot menu.

      If you don’t have windows, AND HAVE NOTHING BOOTABLE IN THE HDD, you can write the GRUB loader directly to the HDD (and it will automatically point to the SSD and boot). But I don’t know of a tutorial on that. It should be as simple as running:

      # sudo grub-install /dev/sda

      Note: ‘sda’ is the HDD and ‘sdb’ is the SSD in my laptop.
      You only need to do that once. But you need to run it from a live usb, and having mounted the SSD partition, and using chroot so that grub uses the installed config files:

      $ sudo su
      # mkdir installedLinux
      # mount /dev/sdb installedLinux
      # chroot installedLinux
      # grub-install /dev/sda

      (from a live usb, after installing linux to the SSD).
      Restart after that, and you will be booting directly to the SSD from now on.

      Juan Manuel Cabo

  7. hmmm, the suspend by close lid issue is back after reboot,
    even upon hitting

    sudo samsung_fix_ec_events
    Using EC ports 0x66 and 0x62
    CommandQuery 0x84, status=0xa, data=0x5
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x66
    CommandQuery 0x84, status=0xb, data=0x0
    EmbeddedController GPE events flushed. New events can be produced now.

    • Did you create the second file in /usr/lib/pm-utils/sleep.d/99samsung_fix_ec_events so that it runs automatically after resume from sleep? (and chmod +x)

      Also, remember it takes about ten seconds for the lid event to be produced.


      Juan Manuel Cabo

  8. it’s all in there:

    israel@israel-sam:~/Is/Aulas/2014I/gaal/ichico$ ls -l /usr/lib/pm-utils/sleep.d/99samsung_fix_ec_events
    -rwxrwxr-x 1 israel israel 799 Mar 2 13:04 /usr/lib/pm-utils/sleep.d/99samsung_fix_ec_events

    I’m not disciplined enuf to register exactly the events leading to that intermittent behaviour.
    so just now, Adapter 0: on-line
    it did suspend. and again.
    but it does fail every now and then.

    • From what you pasted in your comment, I can tell that /usr/lib/pm-utils/sleep.d is not the right directory. If it were, then the user/group owner of that file would have been “root root” instead of “israel israel” in your comment:

      > $ ls -l /usr/lib/pm-utils/sleep.d/99samsung_fix_ec_events
      > -rwxrwxr-x 1 israel israel 799 Mar 2 13:04 /usr/lib/pm-utils/sleep.d/99samsung_fix_ec_events

      So the program is not running automatically in your system.
      Events will get accumulated in the embedded controller during sleep (such as battery % change, or AC plug/unplug), until you run the program manually.

      To make it run automatically after suspend, you need to create the second file in the correct location:

      For ubuntu/kubuntu/xubuntu it is:

      For fedora linux, it is “lib64” instead of “lib”. As in:

      For other systems using “systemd” instead of “pm-utils” it would be:
      (and maybe a different script; you can base it in existing scripts in that directory).

      If your system uses pm-utils, and you copied the file correctly, then you should see the message:
      “EmbeddedController GPE events flushed. New events can be produced now.”
      after sleep/resume in the file:


      If in doubt, please re read carefully all the info. And don’t hesitate to re-ask, it is no problem.


      Juan Manuel Cabo

  9. thanx a lot,
    I’ve changed ownership so it now reads

    -rwxrwxr-x 1 root root 799 Mar 2 13:04 /usr/lib/pm-utils/sleep.d/99samsung_fix_ec_events

    I’ll keep an eye in /var/log/pm-suspend.log
    as of now, it shows things as follows:

    /usr/lib/pm-utils/sleep.d/01PulseAudio resume suspend: success.
    Running hook /usr/lib/pm-utils/sleep.d/00powersave resume suspend:

    /usr/lib/pm-utils/sleep.d/00powersave resume suspend: success.
    Running hook /usr/lib/pm-utils/sleep.d/00logging resume suspend:

    /usr/lib/pm-utils/sleep.d/00logging resume suspend: success.
    Running hook /usr/lib/pm-utils/sleep.d/000kernel-change resume suspend:

    /usr/lib/pm-utils/sleep.d/000kernel-change resume suspend: success.
    Wed Mar 5 16:36:32 BRT 2014: Finished.

  10. so, it’s just stopped suspend-on-lid-close again;
    then I rebooted, to no avail; then I ran

    sudo samsung_fix_ec_events

    with success, except that on resume, the last few lines in that varlog file read

    /usr/lib/pm-utils/sleep.d/00logging resume suspend: success.
    Running hook /usr/lib/pm-utils/sleep.d/000kernel-change resume suspend:

    /usr/lib/pm-utils/sleep.d/000kernel-change resume suspend: success.
    Wed Mar 5 17:08:54 BRT 2014: Finished.

    instead of
    “EmbeddedController GPE events flushed. New events can be produced now.”

    should I post the entire /var/log/pm-suspend.log

    • The problem was not the ownership of the file, but the location. If it was the correct location in the first place, it wouldn’t have let you create the file without root.

      You don’t need to post the entire pm-suspend.log.

      See if you have an existing directory in /usr/lib64/pm-utils/sleep.d and put it there if so.

      I have the following in my directory. If yours was empty, then it means it was the wrong directory:

      $ ls -l /usr/lib/pm-utils/sleep.d/
      total 72
      -rwxr-xr-x 1 root root 292 Jun 13 2013 000kernel-change
      -rwxr-xr-x 1 root root 323 Mar 19 2013 000record-status
      -rwxr-xr-x 1 root root 274 Jun 13 2013 00logging
      -rwxr-xr-x 1 root root 483 Jun 13 2013 00powersave
      -rwxr-xr-x 1 root root 316 Jun 13 2013 50unload_alx
      -rwxr-xr-x 1 root root 267 Dec 7 2012 60_wpa_supplicant
      -rwxr-xr-x 1 root root 453 Jun 13 2013 75modules
      -rwxr-xr-x 1 root root 614 Jun 13 2013 90clock
      -rwxr-xr-x 1 root root 1098 Jun 13 2013 94cpufreq
      -rwxr-xr-x 1 root root 270 Dec 20 2012 95anacron
      lrwxrwxrwx 1 root root 23 Dec 3 2012 95hdparm-apm -> ../power.d/95hdparm-apm
      -rwxr-xr-x 1 root root 297 Jun 13 2013 95led
      drwxr-xr-x 2 root root 4096 Aug 17 2013 95packagekit
      -rwxr-xr-x 1 root root 14075 Jun 13 2013 98video-quirk-db-handler
      -rwxr-xr-x 1 root root 5867 Jun 13 2013 99video

      (taken from my desktop computer)

    • Sorry, I re-read your post, and since it has /usr/lib/pm-utils in the suspend log, now I think you did it in the correct directory. So that means that the location of 99samsung_fix_ec_events is not the issue.

      Have you put the compiled file in /usr/local/bin/samsung_fix_ec_event ?

      Or edited 99samsung_fix_ec_events to point it to the location of the compiled file?


      Juan Manuel Cabo

      • hi there,
        fingers crossed, it’ s been a few days and many suspend / resume on close lid without a flaw!
        apparently the very last reboot has fixed it all, thanks and thanks again and again.
        (I use to infuriate my students saying computer science is all but science:-)

        my next task is to try and decipher your instructions
        for booting thru the SSD.
        I don’t have ruindows from inception.
        now my ssd isn’t mounted at start up; I have to click on nautilus to bring it to life.
        it is listed as a
        16 GB Filesystem
        then mounted on something like

        the rest of what you wrote makes little sense to me,
        except that boot is thru hdd.

        # sudo grub-install /dev/sda

        Note: ‘sda’ is the HDD and ‘sdb’ is the SSD in my laptop.
        You only need to do that once. But you need to run it from a live usb, and having mounted the SSD partition, and using chroot so that grub uses the installed config files:

        $ sudo su
        # mkdir installedLinux
        # mount /dev/sdb installedLinux
        # chroot installedLinux
        # grub-install /dev/sda

        (from a live usb, after installing linux to the SSD).
        Restart after that, and you will be booting directly to the SSD from now on.

        • > fingers crossed, it’ s been a few days and many
          > suspend / resume on close lid without a flaw!


          > my next task is to try and decipher your instructions
          > for booting thru the SSD.

          My instructions were for once having linux installed directly to the SSD, then booting directly to the SSD partition. I personally do that. I have the “/” partition in the SSD and the “/home” partition in the HDD hard drive.

          Maybe I didn’t understand what you meant by “booting thru the SSD” ?

          –Juan Manuel Cabo

          • thanks again for your reply.
            the ssd in my samsung is not mounted automatically upon boot.
            the boot is a lot slower than before getting rid of ruinows because, I presume, it is done thru the hdd.
            so I’d need to know how to have the system
            look for ssd instead of hdd…
            certainly your steps will sound crystal clear to computer profs, allas, I’m but a math prof:-(
            which happens to like and use linux:-)

        • I see, I think that what you mean is use the SSD as a cache to speed up booting as Samsung does using ExpressCache in windows.

          This is not yet well supported in linux. I could point you to dm-cache but it was experimental. I don’t know of a way to use the SSD as boot speed up cache in linux.

          What I did was install linux directly to the SSD, and then boot straight there (no caching). For that, you would need to reinstall linux. (And follow my instructions after install).

    • Thank you!, the paypal arrived well. Very much appreciated!!

      I’ll try your linux new bios version check tonight on my NP530U3C, it is a great step towards not depending on windows.


      Juan Manuel Cabo

  11. Great work, Juan!
    It works on my gf 900x3c.
    The only thing that doesn’t work correct yet is the notification of the battery status in Linux Mint 16 cinnamon when you hover your mouse over the battery icon. It states either laptop battery or AC adapter, depending on the state the system booted with. It doesn’t change when the adapter is plugged in or out.
    The charging symbol does change correctly though..

    • > Great work, Juan!


      > The only thing that doesn’t work correct yet is the notification of
      > the battery status in Linux Mint 16 cinnamon [..]

      Maybe you didn’t set it up correctly to autorun on resume with the second file, the method might be different for a different distro (99samsung_fix_ec_events works for ubuntu/debian and others). Also, if while suspended the laptop runs out of battery, the program wouldn’t run on resume. In that case, you can run it manually, or set it to run on start editing “rc.local”.

      Try the following:

      sudo acpi_listen

      And unplug or plug the power. You should see that acpi_listen lists the following events as acpi_listen output:

      ac_adapter ADP1 00000080 00000000
      processor CPU0 00000081 00000000
      processor CPU1 00000081 00000000
      processor CPU2 00000081 00000000
      processor CPU3 00000081 00000000
      battery BAT1 00000080 00000001

      You can close acpi_listen with CTRL-C.
      If you don’t see the events when plugging/unplugging, you need to run the ‘samsung_fix_ec_events’ program again. If you do see the events but Linux Mint doesn’t change the status in the battery icon, then it is a problem with linux mint.

      Let me know if you have any questions.


      Juan Manuel Cabo

      • Thanks for your reply! (sorry for the late reaction 🙂 )
        All is working well, hibernate works, suspend works and if I plug in the AC the symbool for charging is shown in the taskbar.
        It is just the strange thing I noted above.

        If I try acpi_listen, I get:

        starting with AC plug in, now I plug it out:
        ac_adapter ACPI0003:00 00000080 00000000
        processor LNXCPU:00 00000081 00000000
        processor LNXCPU:01 00000081 00000000
        processor LNXCPU:02 00000081 00000000
        processor LNXCPU:03 00000081 00000000
        battery PNP0C0A:00 00000080 00000001

        plugging it back in:
        ac_adapter ACPI0003:00 00000080 00000001
        processor LNXCPU:00 00000081 00000000
        processor LNXCPU:01 00000081 00000000
        processor LNXCPU:02 00000081 00000000
        processor LNXCPU:03 00000081 00000000
        battery PNP0C0A:00 00000080 00000001

        ac switches from 0 to 1, but battery says in both cases 1.
        is that normal?

        • The acpi_listen output that you posted is the expected output, and it means that you don’t have a stuck embedded controller at the moment, otherwise, you wouldn’t see anything in acpi_listen.

          So I guess you should report a bug to Linux Mint maybe, for that last remaining thing.


          Juan Manuel Cabo

  12. Further:
    Batterylife is not good. Much shorter than in Windows.
    I installed Jupiter, but I’m not sure it helps much.
    Any advise?
    I’m on 3.13.6

    • I get comparable battery life, though just slightly less in linux.

      There are three very useful tools I recommend:

      1. upower -d
      2. powertop
      3. turbostat

      “upower -d” or “upower –monitor-detail” will tell you how many watts of power the system is consuming (when on battery). It can estimate this because the rate at which the battery is discharged is the power being consumed (roughly). It also tells you how much time estimated you have left on battery, at this level of power consumption. You can compare this to what windows tells you. Mind you, that if the screen had been off or on low brightness, the estimated time will be much higher. You can see how different things like changing screen brightness or wifi affect power consumption and time left on battery.

      “powertop” is very useful to diagnose programs, processes and hardware/drivers which are not letting the CPU go into low power states, and interrupt it constantly. Use the “TAB” key to go into each of its screens.

      “turbostat” tells you the power in watts consumed by the CPU package (as opposed to the whole laptop), and the average clock speed of each core and its temperature. You should see about 0.8GHz of speed when idle. If you don’t see that, or close to that, it means either that your laptop is not in “ondemand” or “powersave” mode, or that there is some program active all the time, forcing the CPU to max clock, and thus consuming more power.

      Also, if your laptop is always in “performance” mode, even when on battery, it might consume power quickly. Review your distro power configuration.


      Juan Manuel Cabo

  13. update:
    I just see this with the release of kernel 3.13.7:

    Kieran Clancy (1):
    ACPI / EC: Clear stale EC events on Samsung systems

    Great news!
    Does it mean when updating to this kernel I can delete the 2 files?

    • > Great news!


      > Does it mean when updating to this kernel I can delete the 2 files?

      Exactly! If you have 3.13.7 it means that you no longer need
      anything else.

  14. Just updated to 3.13.7 and deleted the 2 files and it works all fine!
    Big kudos to you and the others working on it!!!! 🙂

    The bug in Mint 16 Cinnamon is still there. I’m going to see if it also exists in Mint 16 Xfce which I have somewhere. I’ll file a bug report to them.

    Any ideas on battery savings?

  15. Pingback: Samsung Linux Battery State Issue + An Interesting Read | Insanity in a Nutshell

  16. Juan & all
    Un grand merci pour votre travail.
    Le bug est résolu et tout travail bien. J’ai résolu le problème en installant le nouveau kernel 3.13.7 (Debian 7.4). Merci d’avoir inclut le correctif dans le kernel car j’ai peu de connaissance pour patcher.


    dmidecode | grep Product
    Product Name: 530U3C/530U4C
    Product Name: SAMSUNG_NP1234567890

  17. Many thanks for your investigation on this issue:
    Battery state detection and suspend-on-lid-close works fine now since upgrading to Ubuntu 14.04.

    Donation is on its way.

  18. I’m running a stock Ubuntu 14.04 with the latest patches installed and the ATIV Book 9 NP900X3G (successor model of the NP900X3C) is not going into standby when I close the lid. So it looks like it is also affected. NP900X3C in contrast is suspending perfectly with the exact same Ubuntu version and patches (I have them sitting side by side).

    • Hi!

      Since that model is the new haswell generation It might be a different problem.

      The kernel fix gets activated only if it matches a Samsung laptop, so as not to cause trouble with other laptops. The way it does it, is by checking the DMI string to see if it matches “SAMSUNG ELECTRONICS CO., LTD.”. (As you can see in ec.c here: http://lxr.free-electrons.com/source/drivers/acpi/ec.c?v=3.14 )

      It may be that they changed the string in the new model? Please check by doing this:

      dmesg | grep -i dmi

      it should output something like:

      DMI: SAMSUNG ELECTRONICS CO., LTD. 530U3C/530U4C/SAMSUNG_NP1234567890, BIOS P14AAJ 04/15/2013

      Also, you could try running the little program in my post above. If it doesn’t work, then it might be a different problem or a problem with Ubuntu itself or its configuration.


      • Thanks for your response.

        Now that I’ve tested a bit more, it seems automatically suspending works just fine (I’ll have to watch it a bit more though since I executed your test application once). What is instead happening is that the laptop automatically resumes from suspend when you open the lid. This made me think it didn’t suspend at all.

        Fyi, the DMI data is:
        DMI: SAMSUNG ELECTRONICS CO., LTD. 900X3G/SAMSUNG_NP1234567890, BIOS P04ADU.023.140414.PS 04/14/2014

    • Hello!
      A slowdown with model NP535U3C when the power supply is plugged in, was also caused by a stuck EC (Embedded Controller). That was reported in that link you pasted https://bugzilla.kernel.org/show_bug.cgi?id=57271

      My fix is a small .c program that empties the EC queue so that it isn’t “stuck” anymore (in my case it affected LID close detection and charging detection, on my ultrabook model).
      My fix is included in this post above, and it is not that hard to run it.

      The fix was converted into a kernel patch and included in kernel 3.13, but we recently became aware that since kernel 3.16, some modification to the kernel is making the kernel patch not work.

      Please see the last comments in:

      What kernel version do you have?

      If you have a kernel version 3.16 or newer, you can run my program manually, included here in my blog post.

      Let me know if this was helpful.

      Juan Manuel Cabo

  19. Unfortunately the workaround seems to not be working either. Below, I’m closing the lid after the second command, waiting ten seconds, then opening it again:

    $ sudo ./samsung_fix_ec_events
    Using EC ports 0x66 and 0x62
    CommandQuery 0x84, status=0xa, data=0xffffff87
    CommandQuery 0x84, status=0xb, data=0x0
    EmbeddedController GPE events flushed. New events can be produced now.
    $ sleep 5; cat /proc/acpi/button/lid/LID0/state
    state: open
    $ dmesg | grep -i dmi
    [ 0.000000] DMI: SAMSUNG ELECTRONICS CO., LTD. 900X3C/900X3D/900X3E/900X4C/900X4D/NP900X3C-A05NL, BIOS P10ABK 11/01/2013
    $ uname -r

    • Hello!!
      I see that you indicated that you have kernel 3.17.
      There is a problem since 3.16, you can follow it here, and maybe test the patches proposed during this week:


      Otherwise, I recomend to downgrade to an older kernel.
      For instance, I’m still on Kubuntu 14.04.1 which has kernel 3.13. It is an LTS (long term support) version.
      I will not upgrade to Kubuntu 14.10 until they fix the problems introduced in the new kernels with samsung laptops.


      Juan Manuel Cabo

      • Hello, yes, I was commenting on “If you have a kernel version 3.16 or newer, you can run my program manually, included here in my blog post” which seemed to indicate that in a 3.16+ scenario the program works where the kernel patch doesn’t. It wasn’t the case for me.

        For now I’ve associated the power button to the suspend action, will keep an eye on bugzilla.

        (Incredible work hunting this bug down, by the way!)

        • > Hello, yes, I was commenting on “If you have a kernel version 3.16 or newer, you can run my program manually, included here in my blog post”

          Oh ok.

          Your comment is an interesting data point on the current problem then, you might want to make a comment on the bugzilla thread.

          I’m too busy with work these days, otherwise I would get involved in at least testing the newer kernels, and helping out with the new problem. For now, I’m just keeping an eye on the discussion.

          > (Incredible work hunting this bug down, by the way!)



          Juan Manuel Cabo

  20. Hello,
    i have the same problems with my ATIV Book 8. LID close is not recognized and plugging ac adaptor also.
    I use Kubuntu 14.04 and have installed the mainline kernel 3.13.7 because there is the samsung fix included.

    no change at all ? Any Idea ?

    greetings Peter

    [~]; dmesg | grep EC:
    [ 0.190954] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
    [ 0.194679] ACPI : EC: 8 stale EC events cleared
    [ 7426.311291] ACPI : EC: 8 stale EC events cleared
    [ 9442.381113] ACPI : EC: 7 stale EC events cleared

    [~]; dmesg | grep DMI:
    [ 0.000000] DMI: SAMSUNG ELECTRONICS CO., LTD. 870Z5G/880Z5F/NP870Z5G-X02DE, BIOS P05RCL.064.140612.QX 06/12/2014

    [~];sudo samsung_fix_ec_events
    Using EC ports 0x66 and 0x62
    CommandQuery 0x84, status=0xa, data=0x14
    CommandQuery 0x84, status=0xb, data=0x70
    CommandQuery 0x84, status=0xb, data=0x70
    CommandQuery 0x84, status=0xb, data=0x0
    EmbeddedController GPE events flushed. New events can be produced now.

    [~];uname -r

  21. Amazing i have tested aptosid livecd with a 3.9 kernel . When i boot from a live usbstick all acpi events are recognized acpi_listen shows every LID close and open are shown imediatly. What does it mean for me ?

  22. A big thanks. I saw used the utility, then saw Keiran’s patch and rejoiced. Sleep and resume are reliable, and have been for awhile. Yay!

    I’m now seeing a new issue (Boo.): Occasionally the laptop will resume from sleep with the lid closed. Luckily these ultrabooks don’t fry themselves with limited airflow.

    I also ruled out intel rapid restart as the cause, but it is a potential workaround. Setting IRST to dump to disk after a short 15min seems to prevent the magic wakes. There are a few others online with the same problem:

    • > A big thanks


      > Occasionally the laptop will resume from sleep with the lid closed

      When you want to resume the laptop, do you press the power button or is it setup to resume on lid open?
      Those options I think are accessible only through the windows samsung utility. Try disabling any “smart” options on the windows samsung programs, they interact with the bios directly. I don’t use inter rapid start and haven’t had the issue (in fact, my 24GB SSD holds the linux root partition, with /home mounted on the big HDD, so I don’t use intel rapid start which requires a dedicated partition in an SSD).


  23. Many many thanks.

    I faced the same problem of a non waking up Samsung NP900X4C laptop running Linux Mint 17 (well known for having an Ubuntu base).

    After implementing the good documented code and script and is now working as expected of resuming after opening the lid again.

    So much more fun now with my Linux Samsung box.

    Wishes and Greetings from Vienna / Austria 🙂

  24. The kernel fix has served me well for years, but they have broken it again! For some reason, the code added by the patch to ec.c that fixed the problem was taken out at 4.11 (acpi_ec_clear) was taken out. I am trying to find out why, but without much success.

    Your little samsung_fix_ec_events is working for me again!

    • Oh that’s sad! I hope you find the reason why they removed it.
      I’m still on kernel version 4.10 in that laptop.

      At least we’ll always have the samsung_fix_ec_events workaround, although it’s not as optimal for non power users as a fix right inside the kernel.


  25. Thanks for investigating the issue and for publishing your findings and fixes.

    Installing CentOS 7 in 2018 on an old NP900X3C: your fix is still needed.

    True, machine is getting old, and is not the top-priority target for RH. Still, your fix makes it run as it should 🙂


    • I’m glad my fix keeps your machine running as it should! 🙂

      Someone removed the kernel version of the fix from the kernel not too long ago. I’m not sure what was the reason.

      And I see that the kernel bugzilla entry has been reopened:

      If you want you can leave a comment there so that the kernel guys finally push the fix upstream again.

      As for me, I’m still using the laptop (but my primary machine is my desktop PC), it currently has my userspace fix applied, and it’s running Kubuntu 17.10.


Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.