acpi reports battery state incorrectly

[erikj]

I have a new Samsung 9-series laptop (NP900X3B) and the battery state is detected incorrectly. Basically the state what was at the time of boot stays active all the time - regardless of the ac-adapter state.

Here is output from "acpitool -a -b" in various situations:

When booted with charger connected and charger is still connected:
  Battery #1 : charging, 47.00%, 01:00:43
  AC adapter : on-line

When booted with charger connected and charger is now disconnected:
  Battery #1 : charging, 47.00%, 01:36:59
  AC adapter : off-line
[The battery couldn't possibly be charging when the AC adapter is offline!]

When booted with charger disconnected and charger is still disconnected:
  Battery #1 : discharging, 47.00%, 01:39:44
  AC adapter : off-line

When booted with charger disconnected and charger is now connected:
  Battery #1 : discharging, 47.00%, 00:53:43
  AC adapter : on-line
[The battery is actually charging as the AC adapter is online]

The percentage and time are correctly updated when the battery is actually charging or discharging - regardless of the reported state. So the state is the only thing that is incorrect. However a number of applications make their decisions based on this state (battery monitor, jupiter, etc.) and therefore behave incorrectly.

"lshal -m" doesn't report anything when I plug the charger in or out.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: acpi (not installed)
ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
Uname: Linux 3.2.0-21-generic x86_64
ApportVersion: 2.0-0ubuntu2
Architecture: amd64
Date: Sun Apr 1 22:50:35 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120328)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: acpi
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Josh Stafford (xbs9)]

This looks like a duplicate of the following bug:
https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/967161

I am having the same issue on a Samsung np530 (Series 5 Ultrabook) with i5 processor.

[Josh Stafford (xbs9)]

One thing I noticed: if I suspend and resume the machine after changing the battery state (plug-in or unplug), the state will be reported correctly after resume.

[Lori Holden (cppege4-email)]

I have this same issue on my Series 9 NP900x4b too.

One thing I noticed is that DIRECTLY after doing a "bios" update from windows... things started to work perfectly for a while in Linux. I ended up booting back into windows for a game at some point, and after coming back it has reverted back to working as stated above.

This makes me wonder if perhaps some sort of ACPI corruption is going on. Ive tried to reflash the firmware since then... but it won't let you flash the same version twice. I would love to compare a ACPI DSDT dump from just after flashing to after it has stopped working.

One can do so via:
cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

You can then dissasemble it with iasl
iasl -d dsdt.dat

[Lori Holden (cppege4-email)]

I forced a firmware update without any change... so much for that idea :(

[sherpa (sherpa-seb)]

Also affected by this bug with a NP900X3C laptop.
As Josh said, putting the laptop in suspend mode correct the reporting of the battery state.

[MarkS (mark-marksyms)]

If this really is a side-effect of the ACPI tables getting corrupted then that's quite serious. Any ACPI experts out there that could advise on how we determine if that is the case?

Concerned as I've just installed 12.04 on a brand new NP900X4C and I hope I haven't destroyed it in the process.

Mark.

[unwrecker (unwrecker)]

The same with Samsung 530U

[Tomer (tbrisker)]

Also experiencing this with Samsung NP530U3C.

[Dmitry Mikhaylov (anoxape)]

Related kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=44161

[Jarkko Torvinen (jarkkot)]

After bios update on NP530U3B-A02SE from 06XK to 08XK (07/11/2012) I'm not experiencing this anymore.

[Tomer (tbrisker)]

BIOS update on np530u3c-a01il also resolved the problem for me.

[Aviram Jenik (q-aviram)]

For many users (including me) BIOS update appears as if it solves the problem, but the bug 'comes back' a few days later. It's as if one of the ACPI functions (the suspend maybe?) causes the BIOS to misbehave again.

[Tomer (tbrisker)]

I can confirm Aviram's comment about the bug returning a few days after the bios upgrade.

[Jarkko Torvinen (jarkkot)]

Yeah, it came back, this time worked almost a week..

[Jarkko Torvinen (jarkkot)]

Shut down the computer and disconnected the battery and now problem seems to be fixed again

[Tim Edwards (tkedwards)]

I can confirm this bug on a Samsung NP530U3C ultrabook. I can also confirm the going into suspend and then waking the computer back up results in it being able to show the percentage of battery charge left.

[Erik Schindler (erik-schindler)]

I can confirm the same issue on my Samsung NP530U3C-A01DE with Ubuntu 12.04 x64 running Unity. It also appears using Xubuntu. BIOS update didn't change anything. It is annoying because a few days ago it already worked perfectly :(

[erikj (erik-jogi)]

The same problem still exists in 12.10 beta.

[Jon Cowell (info-synct)]

I have exactly the same issue with a Samsung NP530U3C-A01UK Ultrabook running Ubuntu 12.04 dual booting with Windows.

In addition I have noticed the following (possibly related) behaviour:
1) Occasionally Wireless networking cannot see any wireless networks when booting eitherinto Windows or Ubuntu.
2) Laptop no longer goes into suspend upon closing the lid - both Windows and Ubuntu exhibit this even though both are configured to suspend on lid closure.

All of this worked perfectly in both OSes for the first few days.

I am running BIOS version P02AAJ which is what came installed from the factory. I would try updating it if I could find the NP530U3C listed on Samsung's support pages :-(

[Erik Schindler (erik-schindler)]

@Jon: Try this: http://www.samsung.com/uk/support/model/NP530U3C-A01UK-downloads?downloadName=UM

[Jon Cowell (info-synct)]

Thanks for the link Erik. It seems that there are at least two ways of searching Samsung UK's web site and one of them (the one I used yesterday) does not admit to the existence of the NP530U3C.

Anyway, I updated the BIOS to P06AAJ from P02AAJ and all failing functionality detailed in my previous post seems to have now been restored. Given the previous comments in this forum it will be interesting to see how long it remains good.

Interestingly the BIOS update filename was ITEM_20120928_714_WIN_P06AAJ.exe so, assuming this means 28th September 2012, it is very new. Hopefully there might be some fixes in here.

[papadopc (papadopc)]

I can confirm the bug, for both wrong battery indicator and no suspend on lid close on a new series 9 samsung NP900X4C-A01US.
An added twist is failed boots on occasion.

[Jon Cowell (info-synct)]

After BIOS update all was well for 15hours only!

Yesterday, after updating the BIOS I tested power connect/disconnect recognition in both Windows and Ubuntu 12.04 and suspend on lid closure. Everything worked fine. Then, in Ubuntu 12.04, I suspended the system over night. Next morning, lid closurefails to be recognised by Ubuntu. Power connect/disconnect fails to be acted upon properly by Ubuntu. In Windows, lid closure still fails but power connect/disconnect still recognised - but it takes several seconds rather than being almost instantaneous when all was well the night before.

Very infuriating!... is this Ubuntu corrupting things in the BIOS or is the BIOS somehow corrupting itself with respect to ACPI.

[Marcello (pogliamarci)]

On 06/10/12 09:41, Jon Cowell wrote:
> After BIOS update all was well for 15hours only!

Also for me, things worked well (both lid and power status) during the
first weeks of life of the laptop (a Series 5 Ultrabook).

> Yesterday, after updating the BIOS I tested power connect/disconnect
> recognition in both Windows and Ubuntu 12.04 and suspend on lid closure.
> Everything worked fine. Then, in Ubuntu 12.04, I suspended the system
> over night. Next morning, lid closurefails to be recognised by Ubuntu.
> Power connect/disconnect fails to be acted upon properly by Ubuntu. In
> Windows, lid closure still fails but power connect/disconnect still
> recognised - but it takes several seconds rather than being almost
> instantaneous when all was well the night before.

I found that
 /sys/class/power_supply/ADP1/online
(the status of the power adapter) gets updated correctly, while the
battery status (charging/discharging), as found in
 /sys/class/power_supply/BAT1/status
is "frozen" in the status after power on / resume after suspend. So
MAYBE in Windows power connect/disconnect is triggered by power adapter
changing status instead than by battery. I worked around this problem by
applying an ugly patch to upowerd so that power status change is
triggered also by power adapter... and that works acceptably for now.

Lid closure, instead, is completely broken also if suspend works well.
Can't test in Windows as I wiped out the windows partition ;)

> Very infuriating!... is this Ubuntu corrupting things in the BIOS or is
> the BIOS somehow corrupting itself with respect to ACPI.

I noticed the problem after starting up erroneously the recovery
partition. This messed up with the MBR and Grub, so I had to recover
Grub booting from an USB disk, and from that moment I noticed the
problem... (not sure if before that the problem was present or not)

[Jon Cowell (info-synct)]

Now you mention it Marcello... I also erroneously started up the recovery partition and had to sort our the MBR and Grub afterwards. I don't recall having these issues before doing this. I'm not sure this caused the issue though since others posting here haven't mentioned it.

With hindsight, I wish I had only run windows for a few days (torture I know - it is only there for those rare occasions and runs LibreOffice, Firefox and Thunderbird) without booting into Ubuntu to see how things faired. Then I could have been a little more suspicious that Ubuntu somewhow causes the problem.

After updating the BIOS I noticed that the BIOS setting for only charging the battery to 80% had been disabled (it was enabled before). Maybe resetting the BIOS to default values mught re-instate normal behaviour for a period. I'm not in a position to try it right now.

[Jon Cowell (info-synct)]

Back to the Samsung NP530U3C Ultrabook in my previous posts... resetting the BIOS settimgs to their defaults has no effect.

[Erik Schindler (erik-schindler)]

Regarding post #27: Marcello, how did you apply your patch to upowerd? Maybe it can help other users, too.

Thanks in advance.

[j0lly (j0lly)]

> Maybe resetting the BIOS to default values mught re-instate normal
> behaviour for a period. I'm not in a position to try it right now.
>
> I can confirm you that if you push the reset button on bottom of the
laptop with a needle (laptop unpowered, than use the power cord to start
it otherwhise will not start) the next boot all the ACPI events are logged
perfectly; all is run wanderfully untill some events that screw up again
the ACPI/BIOS stuff.

I can't track the cause of the corruption right now, but i suspect is
triggered by the suspend itself (maybe when is suspend overnight) i have to
test, but can confirm the trick can solve the problem untill it occur again
(sometimes after few ours, sometimes it last for 3/4 days).

Im on Archlinux:

Linux 0x0000 3.5.5-1-ARCH #1 SMP PREEMPT Tue Oct 2 22:30:55 CEST 2012
> x86_64 GNU/Linux
>

BIOS Information
> Vendor: Phoenix Technologies Ltd.
> Version: P03AAJ
> Release Date: 06/20/2012
> Address: 0xE0000
> Runtime Size: 128 kB
> ROM Size: 3072 kB
> Characteristics:
> PCI is supported
> BIOS is upgradeable
> BIOS shadowing is allowed
> Boot from CD is supported
> Selectable boot is supported
> EDD is supported
> Print screen service is supported (int 5h)
> 8042 keyboard services are supported (int 9h)
> Serial services are supported (int 14h)
> Printer services are supported (int 17h)
> CGA/mono video services are supported (int 10h)
> NEC PC-98
>
                ACPI is supported
> USB legacy is supported
> BIOS boot specification is supported
> Function key-initiated network boot is supported
> Targeted content distribution is supported
> UEFI is supported
> BIOS Revision: 0.1
>

[Erik Schindler (erik-schindler)]

> I can confirm you that if you push the reset button on bottom of the
> laptop with a needle (laptop unpowered, than use the power cord to start
> it otherwhise will not start) the next boot all the ACPI events are logged
> perfectly; all is run wanderfully untill some events that screw up again
> the ACPI/BIOS stuff.

Is the installed OS affected by this workaround or only BIOS configuration?

[j0lly (j0lly)]

The OS kernel log all the events.
The first time also the LID (that generally need 10 sec to trigger the
status change when work) is logged almost instantly.
I can have log in dmesg and acpid.

2012/10/12 Erik Schindler <email address hidden>

> > I can confirm you that if you push the reset button on bottom of the
> > laptop with a needle (laptop unpowered, than use the power cord to start
> > it otherwhise will not start) the next boot all the ACPI events are
> logged
> > perfectly; all is run wanderfully untill some events that screw up again
> > the ACPI/BIOS stuff.
>
> Is the installed OS affected by this workaround or only BIOS
> configuration?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> Status in “acpi” package in Ubuntu:
> Confirmed
>
> Bug description:
> I have a new Samsung 9-series laptop (NP900X3B) and the battery state
> is detected incorrectly. Basically the state what was at the time of
> boot stays active all the time - regardless of the ac-adapter state.
>
> Here is output from "acpitool -a -b" in various situations:
>
> When booted with charger connected and charger is still connected:
> Battery #1 : charging, 47.00%, 01:00:43
> AC adapter : on-line
>
> When booted with charger connected and charger is now disconnected:
> Battery #1 : charging, 47.00%, 01:36:59
> AC adapter : off-line
> [The battery couldn't possibly be charging when the AC adapter is
> offline!]
>
> When booted with charger disconnected and charger is still disconnected:
> Battery #1 : discharging, 47.00%, 01:39:44
> AC adapter : off-line
>
> When booted with charger disconnected and charger is now connected:
> Battery #1 : discharging, 47.00%, 00:53:43
> AC adapter : on-line
> [The battery is actually charging as the AC adapter is online]
>
> The percentage and time are correctly updated when the battery is
> actually charging or discharging - regardless of the reported state.
> So the state is the only thing that is incorrect. However a number of
> applications make their decisions based on this state (battery
> monitor, jupiter, etc.) and therefore behave incorrectly.
>
> "lshal -m" doesn't report anything when I plug the charger in or out.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: acpi (not installed)
> ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
> Uname: Linux 3.2.0-21-generic x86_64
> ApportVersion: 2.0-0ubuntu2
> Architecture: amd64
> Date: Sun Apr 1 22:50:35 2012
> EcryptfsInUse: Yes
> InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64
> (20120328)
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: acpi
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061/+subscriptions
>

[Marcello (pogliamarci)]

Regarding post #30.
In the attachment you'll find my patch to upowerd (file to be patched is src/linux/up-device-supply.c). I applied the patch to upstream upowerd, recompiled, and disabled via apt updates to upowerd.

Basically, this detects battery status basing on the AC adapter status (if the status is not consistent, in the sense that the battery reports discharging and the AC is plugged in, I set the status to UNKNOWN so that the following code treat the status as discharging basing on AC status, and so on).

Moreover, I had to enable polling for AC adapter (I don't know why uevents are not reported nor how to enable them for AC status, I'm not a kernel\low leven stuff expert..). The drawback of this is that status changes are not recognized immediately, but at least are recognized...

[Erik Schindler (erik-schindler)]

I just used the reset button on the laptop bottom and I can also confirm that it helps bringing back correct acpi function. Now plugging and unplugging the power supply is logged "live". It's only some minutes ago, so I will place another comment when acpi falls back in malfunction again.

[Erik Schindler (erik-schindler)]

In addition to the previous post: closing the lid is also recongized correctly.

[j0lly (j0lly)]

Yes and I think is the suspension act that screw it again.. At least
overnight crackheads do it on mine maybe is a resume hook.. I tried the pm
and the systems functions and both do it
Il giorno 16/ott/2012 13:51, "Erik Schindler" <email address hidden> ha
scritto:

> In addition to the previous post: closing the lid is also recongized
> correctly.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> Status in “acpi” package in Ubuntu:
> Confirmed
>
> Bug description:
> I have a new Samsung 9-series laptop (NP900X3B) and the battery state
> is detected incorrectly. Basically the state what was at the time of
> boot stays active all the time - regardless of the ac-adapter state.
>
> Here is output from "acpitool -a -b" in various situations:
>
> When booted with charger connected and charger is still connected:
> Battery #1 : charging, 47.00%, 01:00:43
> AC adapter : on-line
>
> When booted with charger connected and charger is now disconnected:
> Battery #1 : charging, 47.00%, 01:36:59
> AC adapter : off-line
> [The battery couldn't possibly be charging when the AC adapter is
> offline!]
>
> When booted with charger disconnected and charger is still disconnected:
> Battery #1 : discharging, 47.00%, 01:39:44
> AC adapter : off-line
>
> When booted with charger disconnected and charger is now connected:
> Battery #1 : discharging, 47.00%, 00:53:43
> AC adapter : on-line
> [The battery is actually charging as the AC adapter is online]
>
> The percentage and time are correctly updated when the battery is
> actually charging or discharging - regardless of the reported state.
> So the state is the only thing that is incorrect. However a number of
> applications make their decisions based on this state (battery
> monitor, jupiter, etc.) and therefore behave incorrectly.
>
> "lshal -m" doesn't report anything when I plug the charger in or out.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: acpi (not installed)
> ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
> Uname: Linux 3.2.0-21-generic x86_64
> ApportVersion: 2.0-0ubuntu2
> Architecture: amd64
> Date: Sun Apr 1 22:50:35 2012
> EcryptfsInUse: Yes
> InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64
> (20120328)
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: acpi
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061/+subscriptions
>

[Erik Schindler (erik-schindler)]

Well, I sent the laptop into suspend mode last evening and since today in the morning acpi is not working correctly anymore. So, overnight suspension could be the problem. Maybe minimalistic year 2000 problem ;)

Is anybody from Canonical already involved in finding a solution?

[j0lly (j0lly)]

This is not only Ubuntu: i'm Arch at the problem is the same, i testetd
with at least 3 kernel from Arch and the problem persist so, i think, is
either the acpi module or, more probably, a Bios bug.
I also tried to pass Windows as OS to the BIOS with grub command: acpi_osi= at
actually broke the bootup..

2012/10/17 Erik Schindler <email address hidden>

> Well, I sent the laptop into suspend mode last evening and since today
> in the morning acpi is not working correctly anymore. So, overnight
> suspension could be the problem. Maybe minimalistic year 2000 problem ;)
>
> Is anybody from Canonical already involved in finding a solution?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> Status in “acpi” package in Ubuntu:
> Confirmed
>
> Bug description:
> I have a new Samsung 9-series laptop (NP900X3B) and the battery state
> is detected incorrectly. Basically the state what was at the time of
> boot stays active all the time - regardless of the ac-adapter state.
>
> Here is output from "acpitool -a -b" in various situations:
>
> When booted with charger connected and charger is still connected:
> Battery #1 : charging, 47.00%, 01:00:43
> AC adapter : on-line
>
> When booted with charger connected and charger is now disconnected:
> Battery #1 : charging, 47.00%, 01:36:59
> AC adapter : off-line
> [The battery couldn't possibly be charging when the AC adapter is
> offline!]
>
> When booted with charger disconnected and charger is still disconnected:
> Battery #1 : discharging, 47.00%, 01:39:44
> AC adapter : off-line
>
> When booted with charger disconnected and charger is now connected:
> Battery #1 : discharging, 47.00%, 00:53:43
> AC adapter : on-line
> [The battery is actually charging as the AC adapter is online]
>
> The percentage and time are correctly updated when the battery is
> actually charging or discharging - regardless of the reported state.
> So the state is the only thing that is incorrect. However a number of
> applications make their decisions based on this state (battery
> monitor, jupiter, etc.) and therefore behave incorrectly.
>
> "lshal -m" doesn't report anything when I plug the charger in or out.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: acpi (not installed)
> ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
> Uname: Linux 3.2.0-21-generic x86_64
> ApportVersion: 2.0-0ubuntu2
> Architecture: amd64
> Date: Sun Apr 1 22:50:35 2012
> EcryptfsInUse: Yes
> InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64
> (20120328)
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: acpi
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061/+subscriptions
>

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/971061

[Hnyk Daniel (hnykda)]

Xubuntu 12.10 same problem here.

I used my Samsung 530U three months only with windows - and it worked fine without any problem. Now I have this problem with recognizing of power supply - but only in Xubuntu.

[j0lly (j0lly)]

humm, seems there's no porgressions.
To summarize, the problem affect the ACPI module // Bios memory after a certains suspention cyrcle.
It looks like the suspend or resume process screw up the module that stop to log ACPI events to Kernel.
There's no other important news?

I thnk i'm not able to go deeper because i'm not expert in debug this kind of things. If someone knows the proper way to debug it, tell me and i'll plesured to help with this..

[paolo.mgi (paolo-mgi)]

Does the tag "no longer affects:acpi (Arch Linux)" mean that the problem is solved on arch?

[j0lly (j0lly)]

No, I just mistaken with the button

2012/11/14 paolo.mgi <email address hidden>

> Does the tag "no longer affects:acpi (Arch Linux)" mean that the
> problem is solved on arch?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> Status in “acpi” package in Ubuntu:
> Confirmed
>
> Bug description:
> I have a new Samsung 9-series laptop (NP900X3B) and the battery state
> is detected incorrectly. Basically the state what was at the time of
> boot stays active all the time - regardless of the ac-adapter state.
>
> Here is output from "acpitool -a -b" in various situations:
>
> When booted with charger connected and charger is still connected:
> Battery #1 : charging, 47.00%, 01:00:43
> AC adapter : on-line
>
> When booted with charger connected and charger is now disconnected:
> Battery #1 : charging, 47.00%, 01:36:59
> AC adapter : off-line
> [The battery couldn't possibly be charging when the AC adapter is
> offline!]
>
> When booted with charger disconnected and charger is still disconnected:
> Battery #1 : discharging, 47.00%, 01:39:44
> AC adapter : off-line
>
> When booted with charger disconnected and charger is now connected:
> Battery #1 : discharging, 47.00%, 00:53:43
> AC adapter : on-line
> [The battery is actually charging as the AC adapter is online]
>
> The percentage and time are correctly updated when the battery is
> actually charging or discharging - regardless of the reported state.
> So the state is the only thing that is incorrect. However a number of
> applications make their decisions based on this state (battery
> monitor, jupiter, etc.) and therefore behave incorrectly.
>
> "lshal -m" doesn't report anything when I plug the charger in or out.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: acpi (not installed)
> ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
> Uname: Linux 3.2.0-21-generic x86_64
> ApportVersion: 2.0-0ubuntu2
> Architecture: amd64
> Date: Sun Apr 1 22:50:35 2012
> EcryptfsInUse: Yes
> InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64
> (20120328)
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: acpi
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061/+subscriptions
>

[paolo.mgi (paolo-mgi)]

I am running since a couple of days

Kernel 3.6.6-030606-generic #201211050512 SMP Mon Nov 5 10:12:53 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

from UpUbuntu.

It seems to me that up to now "acpitool -a -b" has always reported correctly the state of the AC adapter.

[Jason Robinson (jaywink)]

I went and upgraded to 3.6.7-030607-generic #201211171710 from the Ubuntu Kernel team PPA and still acpi shows discharging even though AC is plugged in. State of AC adapter is and has always been shown correctly - that just doesn't reflect to the charging/discharding status.

[paolo.mgi (paolo-mgi)]

To add more details to my previous entry: I am running 12.10 with BIOS P04AAC (v 1.0.0.3).
I confirm that as far as I could see AC adapter AND battery status are correctly reported by
acpitool -a -b

e.g. right now

  Battery #1 : Discharging, 99.26%, 06:45:30
  AC adapter : off-line

while I saw respectively "charging" and "on-line" few minutes ago before unplugging the AC adapter.

[Tim Edwards (tkedwards)]

Paolo can you give us the link where that firmware can be downloaded from? When did you update to that firmware?

When I go to the Samsung website the most recent firmware I see available is from May 2012. I tried with the 12.10 live CD on this system but also no luck.

[paolo.mgi (paolo-mgi)]

I downloaded the BIOS from here

http://www.samsung.com/uk/support/model/NP900X3C-A02UK-downloads

it dates back to last spring.

I am now in position to confirm that the kernel version (3.5 or 3.6) plays no role for the acpi problems
we are discussing.
Experimenting with 3.7 crashed and froze my laptop with a system error hinting to
acpi which arose when I plugged in the acpi adapter for re-charging. Unfortunately I reacted instinctively
and rebooted the laptop without recording the exact error message.

After that independently of the kernel I tried (3.5.19 3.6.6 or 3.6.10) I was experiencing

- broken charging/discharging state indicator
- broken lid state indicator
- broken keyboard backlit i.e.no backlit at all

To restore the previous behavior I followed the advice of comment #35
of https://bugzilla.kernel.org/show_bug.cgi?id=44161
i.e. I manually reset the battery/BIOS

Now I am running kernel v3.5.19 and everything works correctly again but only for a while I am afraid.
In conclusion, upstream seems to have an understanding of the problem but prospects are not encouraging.
Given the situation, at the moment I would not advice anybody to buy this laptop.

[Tim Edwards (tkedwards)]

Ok, you have a different model to mine which explains why I couldn't find the firmware version you mentioned :)

I have the NP530U3C and as it currently stands the best workaround for this problem for me is:
- shutdown the laptop
- insert a pin or staple into the little hole on the bottom of the laptop to shut off power from the battery
- Then plug the laptop into the power and re-start it

After that the ACPI detection of battery state and whether the AC adapter is plugged in or not works perfectly in Ubuntu, but eventually stops working again after a few suspend/resume cycles.

Really annoying but not enough to stop me using the laptop.

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

The workaround in the previous comment worked for me. I hope the problem will not come up very soon again.

[Mattia Guidi (matguidi)]

Yes, it works, but in my case, after three suspension/resume cycles, the acpi problem is there again. The laptop also fails to suspend when the lid is closed, even though it should do that with the adapter both plugged and unplugged.

[fringd (fringd)]

Is there some way to log the signals being sent to the battery? if so, i could reset the battery and mess with it until it breaks (suspend and resume a lot seem to be good starting places) and then mark when it fails. Anybody have any clues how to accomplish this?

[于越 (1456977544-0)]

My notebook is DELL N5110, it seems have the same problem.For a long time in the past,It has been normal,I do not know when it started, why start.so i can't find anyway to solve T_T

[Jason Robinson (jaywink)]

Events started working for me a few days ago, now power indicator reflects changes when I plug or unplug the AC. Weird since I didn't do any hardware/battery reset and did not even do any major kernel updates - or maybe I missed noticing the improvement after updating something. Something from daily updates? The bug is still open on the Linux kernel bugtracker and some have confirmed it even in 3.9.

My kernel: 3.8.8-030808-generic
Ubuntu 13.04 fully updated
acpi 1.6-1

[Ayberk Özgür (equilibriumtr)]

My personal experience regarding this bug and the lid closed detection bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986724) is as follows. I am using:

-Samsung NP900X4C
-Kubuntu 12.04.2
-Kernel 3.9.0-030900-generic (was recently using the stock 3.2.0-49-generic)
-BIOS P08ABK which is just a few days old (was recently using the shipped BIOS P07ABK)
-acpid-2.0.10

1) With my old configuration (kernel and BIOS), the lid closed and AC plug/unplug events were not detected as usual.
2) Updating the kernel to 3.9.0 didn't change anything.
3) Upon updating the BIOS to P08ABK and booting for the first time into Kubuntu, the plug in/out events were both detected correctly. To my surprise, the keyboard backlight started to automatically adjust itself according to the ambient light, which is a very cool feature :). However, the lid close event was still not detected.
4) After only one suspend/resume and then restart, all of the problems resume like nothing happened, this means no lid close detection, AC plug/unplug detection or keyboard backlight adjustment.
5) I boot into a win8 bootable USB where plug/unplug are detected but lid close is not detected similar to Kubuntu; there is no keyboard backlight adjustment as well (I deleted my win8 partition along with all other useless recovery/boot partitions that took up 30 GB standing idle).
6) Booting back into Kubuntu, everything is as usual, no lid/plug events detected and backlight stays off.

[Agustin Barto (abarto)]

The same happens to me with an NP550P5C. Usually removing the battery seems to solve the problem until you suspend and resume once.

[Agustin Barto (abarto)]

Using acpi_osi=Windows 2012 on grub's command line seems to help. I suspended and resumed a couple of times and the AC is detected correctly and so is the lid state (which now suspends the box).

[Mattia Guidi (matguidi)]

The solution proposed by Agustin seems to work for me - at least, I suspended and resumed twice and everything seems to work fine for the moment. But shouldn't the grub option be

acpi_osi='!Windows 2012'

instead of

acpi_osi=Windows 2012

?

[Agustin Barto (abarto)]

It didn't work in the end. After a long suspended period last night, the bug reappeared.

[Mattia Guidi (matguidi)]

I confirm that adding the option

acpi_osi='!Windows 2012'

to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub at least makes the lid close suspension behave correctly. It's been two weeks since I made that change, I suspended and rebooted several times, and still when I close the lid the suspension works fine.

Just to make it clear, and if you want to try it yourself, you should open /etc/default/grub with your text editor (and with sudo privileges) and replace the line starting with

GRUB_CMDLINE_LINUX_DEFAULT

with the following:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi='!Windows 2012'"

It would be nice to know if this solution works for other users as well.

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

Mattia, I've just tried and I confirm it works for me too. I don't like having the word "Windows" in my /etc/default/grub but I can survive. :) I hope this will also help to reduce the temperature, more than what TLP already does, but I guess this won't have any effect on this matter.

[Mattia Guidi (matguidi)]

I would say this option has no effect on the CPU temperature.

[Marcello (pogliamarci)]

On 24/08/2013 23:37, Mattia Guidi wrote:
> I confirm that adding the option
>
> acpi_osi='!Windows 2012'
>
> to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub at least makes the
> lid close suspension behave correctly.

For me it's not working.
Even changing my GRUB_CMDLINE_LINUX_DEFAULT line to "quiet
acpi_osi='!Windows 2012'", when closing the lid the action is not
detected (/proc/acpi/button/lid/LID0/state indicates the state as open,
and the suspension is not triggered)

[Ayberk Özgür (equilibriumtr)]

Adding acpi_osi='!Windows 2012' to GRUB_CMDLINE_LINUX_DEFAULT unfortunately does nothing on NP900X4C with kernel 3.10.4.

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

Marcello, Ayberk, just to be sure, did you guys do `sudo update-grub` and reboot after adding the parameter?

[Juan Pablo Carlino (jpcarlino)]

I can confirm acpi_osi='!Windows 2012' does NOT work netiher on my NP530U3C
with kernel 3.8.0

On Mon, Aug 26, 2013 at 11:31 AM, Ayberk Özgür <email address hidden>wrote:

> Adding acpi_osi='!Windows 2012' to GRUB_CMDLINE_LINUX_DEFAULT
> unfortunately does nothing on NP900X4C with kernel 3.10.4.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/acpi/+bug/971061/+subscriptions
>

[Ayberk Özgür (equilibriumtr)]

Andrea, yes I did indeed updated grub and rebooted. The problem still persists.

[Marcello (pogliamarci)]

On 26/08/2013 16:45, Andrea Lazzarotto (Lazza) wrote:
> Marcello, Ayberk, just to be sure, did you guys do `sudo update-grub`
> and reboot after adding the parameter?

Yes.

I also checked on the grub command line during the reboot, and the
parameter was indeed there.

[agonified (hakanakkan)]

I have an NP900X4C too and acpi_osi='!Windows 2012' has no effect on battery status indicator. It is still broken after the first sleep. I'm on whatever the latest kernel is in 13.04.

[Mattia Guidi (matguidi)]

It seems that suspension on lid close stopped working for me as well. It was working two days ago, now it doesn't. So, whatever the reason, changing that GRUB option doesn't help at the moment. Really frustrating.

[Vinícius Angiolucci Reis (angiolucci)]

Not working here.
Add acpi_osi='!Windows 2012' to GRUB_CMDLINE_LINUX_DEFAULT has to
effect.

--
  Vinícius Angiolucci Reis
  <email address hidden>

[John Cabezutto (john-cabezutto)]

Having both problems here too. Anyone managed to fix it?

Hopefully we can get a fix soon.

[Your Dudeness (yourdudeness)]

Same problem with Satellite L75D-A7280

[Ayberk Özgür (equilibriumtr)]

Just as a side note, adding

acpi_osi='!Windows 2012'

to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub seems to have fixed the battery charge/discharge state detection that most people are experiencing besides the lid close detection. The fix seems permanent; after about 10 reboots and 15 sleeps, the battery's charge/discharge states are still detected correctly. On top of that, the keyboard backlight started and is still working too :) It adjusts the brightness automatically according to the ambient light. Adjustment from keyboard (Fn+F9, Fn+F10) still has no effect though.

I am on the following configuration:

-Samsung NP900X4C
-Kubuntu 12.04.2
-Kernel 3.10.4-031004-generic
-BIOS P08ABK
-acpid-2.0.10

The lid close events are still not detected.

[Ayberk Özgür (equilibriumtr)]

Ignore my previous comment, after about 15 sleep/resumes, all of the errors came back.

[Žygimantas Beručka (zygis)]

I started having this on my SAMSUNG NP530U3c-A05EE machine this September (or at least I did not notice it before, although I had been using it with Quantal since June). Decided to upgrade to Saucy, however this did not fix the issue for me. No ACPI event is triggered after connecting/disconnecting the AC cable and/or closing the laptop lid.

Booted into Windows to see if there is a BIOS update avaible, as suggested by someone here, alas nothing has been provided by SAMSUNG so far. (And I do not believe it will be.)

[Paul Hannah (pkhannah)]

I've been living with this problem (on 2 900X3C's) and have just noticed something that might point to a solution.

I have all the problems/symptoms described above (no charge/drain recognition, no kb backlight, no lid-close notification, has magically appeared at times of OS install.)

But, htop (after going into the settings and displaying the battery state) correctly picks up the a/c cable insertion/removal, charging/discharging indication, and fully charged state.

So, htop is getting this information from somewhere that's spot on, but (in my case xfce4-power-manager, and I'm guessing upowerd) are looking elsewhere and not getting the correct information.

Not sure if it's going to help, but maybe it might point to a workaround at least.

[Marcello (pogliamarci)]

On 02/10/2013 06:11, Paul Hannah wrote:
> But, htop (after going into the settings and displaying the battery
> state) correctly picks up the a/c cable insertion/removal,
> charging/discharging indication, and fully charged state.

The same happens to me. htop has the right status, while upower is not
updated.

I don't know what htop is monitoring to display the battery status...
but /sys/class/power_supply/ADP1/online is updated correcty when
(un)plugging the power supply, while /sys/class/power_supply/BAT1/status
has the wrong value (the battery charge is correct, but the
charging\discharging status is the one that the battery had at boot time).

[Ayberk Özgür (equilibriumtr)]

@pkhannah: I confirm that htop is reporting AC plug/unplug states correctly, but this is also the case with acpid (acpitool -a -b reports AC plug/unplug state correctly but battery charging/discharging states incorrectly). Since most present software rely on battery charging/discharging rather than AC plugged/unplugged, this may only lead to a workaround as you said. This is probably what Windows drivers are doing.

[daniele3 (3daniele03)]

I am afraid Windows does much more than simply polling the status of the AC adapter (which I can confirm is correctly detected by linux as well).
Let me add the following information: the files

/sys/devices/system/cpu/cpu*/cpufreq/bios_limit

should reflect the AC plug status according to the bios settings. The contents of these files cannot be modified by the user. In my case, they are not modified when plugging/unplugging the AC adapter unless I suspend/resume the machine. This means that if I boot/resume while on-battery and after a while plug the AC cable, then my cpu's are not allowed to run at maximum speed until I suspend/reboot my machine...

I think that one of the main sources of trouble is that plugging/unplugging the AC cable does not produce an ACPI event. This is something related to the BIOS and I think that Samsung should get involved into this discussion (I do not know how...).

[Žygimantas Beručka (zygis)]

In the upstream bug report one user reported:
> I have a samsung series 9 np900x3c affected by the same issue.
> I've noticed a pattern in this bug's behavior and I would like to know if
> someone else can confirm the following:
>
> The bug triggers ONLY if a suspend/resume (hibernate/thaw) event happens
> while the laptop is connected to the charger. I've tested this for about 3
> weeks now; I always unplug the charger before suspending (heck, even before
> shutting down the system, although that's unlikely to cause any harm) and
> always plug it in (if needed) only after resume.
>
> Can anyone confirm that I haven't just hit a lucky streak?

I have been following this advice for the past week and it indeed seems to be the case. If I unplug it before suspending AND resume with it being unplugged (in fact, you can actually plug it in *after* suspending, just be sure to unplug it before resuming), the bug DOES NOT get triggered.

However, I should I forget to unplug it before suspending or resume while it is plugged in, the bug occurs and the only way to get rid of it is to press the reset button underneath the laptop.

In my case it is a SAMSUNG Series 5 Ultra NP530U3C-A05EE machine.

[christophe-marie (duquesnc)]

Samsung NP530U3B here. I can confirm what most people say:
- When I installed ubuntu 13.04 "raring ringtail", kernel 3.8.0-31-generic, everything was working perfectly:
  - lid state was detected correctly, and laptop was going to sleep automatically
  - batery state was also detected fine
- After a few cycles of suspend/reboot lid state and battery state are not detected correctly (although /sys/class/power_supply/ADP1/online _does_ report the correct value).
- Suspending the laptop triggers correct detection of the battery state (although it takes a while for gnome-power-manager to notice). However, the lid state is still incorrectly detected: acpi_listen does not print anything when the lid is open/closed (nor when the battery is plugged/unplugged, even when gnome-power-manager ends up detecting the right state)

[macko (erdosboti)]

I tried what was mentioned recently namely that if you unplug before suspending and only plugin after resuming, then the bug doesn't trigger, and for me it did not work. First I left it in a short suspending then it worked, but that seems to work anyway no matter if it is plugged in or not. Second time I left it in at least 12 hours of suspend state and the bug reappeared. I have a saumsung series 9 NP900X4C.

[Ivo Roghair (ivo-82)]

I have this problem with 13.04 on a Series 5 Samsung laptop, exactly as described by many others here. I just upgraded to 13.10, and I noticed that the battery charge percentage is now not reported correctly anymore (I'm stuck at 100%). This used to work fine with the 13.04 release. This only happened after a suspend cycle (a freshly booted system does not have this problem).

[casbon (casbon)]

This has affected me after upgrading to 13.10. Everything was working fine in 12.10 and 13.04. Samsung series 9 NP900X3C. The adapter state is reported correctly, but the battery is not.

Plugged in:

$ acpitool -a -b
  Battery #1 : Unknown, 80.00%
  AC adapter : online

Not plugged in:

$ acpitool -a -b
  Battery #1 : Charging, 80.00%, 01:18:26
  AC adapter : off-line

htop reports correctly.

[ZZambia (mario-vigliar)]

Same here on a NP900X4C.

With mains:
$ acpitool -a -b
  Battery #1 : Unknown, 98.00%
  AC adapter : online

Without:
$ acpitool -a -b
  Battery #1 : Charging, 98.00%
  AC adapter : off-line

Adapter state OK, Battery state never in "Discharging", percentage seems well calulated (decreasing with time). Time to full charge value is obviously impossible to be checked, and continously updated with increasing values, as expected.

[ZZambia (mario-vigliar)]

Forgot to mention that the first kernel after 13.10 from 13.04 update was working perfectly. The issue appeared after "3.11.0-13-generic" kernel update. Not sure if acpi package was updated in the same round.

[daniele3 (3daniele03)]

This is just to let you know that the trick of unplugging before suspending/hibernating does NOT work for me. After resetting the battery, the trick worked for a little bit more than two weeks (frequent suspend/resume cycles).

[Vinícius Angiolucci Reis (angiolucci)]

I compiled a 3.12.1 vanilla kernel, and set the INTEL_MEI and
INTEL_MEI_ME to be compiled into the kernel. I also pressed the "reset
power" button, under the laptop for 15 secs.

LID CLOSE working.
Switch to AC or Battery working.
LID OPEN not working properly (it's not detected).

It's still working now, 5 day after the above steps.

NOTE: If you change the LID CLOSE/OPEN settings in gnome-tweak-tool,
everything will stop to work, and you'll need to use the "reset power"
button again. That was the only issue I've noticed.

[macko (erdosboti)]

@angiolucci: I followed your instructions but after the first long suspend the bug appeared. So it basically behaves the same as before after a simple reset power. I would really appreciate if you could answer some of the questions below:
What is your exact model? (mine is NP900X4C-A02CH)
Did you have the most recent firmware before the process? (mine is P07ABK although according to https://help.ubuntu.com/community/SamsungBIOS there is a more recent version)

I followed http://www.tecmint.com/kernel-compilation-in-debian-linux/ for making a debian version of the kernel and I started from the already existed config file. I found the INTEL_MEI and INTEL_MEI_ME options acccording to https://bugzilla.kernel.org/show_bug.cgi?id=44161#c74 and changed them to be compiled into the kernel but changed NO other configuration options. I compiled the recent kernel 3.12.5. I found another interesting info https://bugzilla.kernel.org/show_bug.cgi?id=44161#c98 about the requirement that some service must run in the user-space, which I don't really know how to check or what config option is responsible for that, so I ignored it. (This was my first kernel compilation)

Can you spot any problems in the process? Or do you have any comments that may help me? Thanks in advance.

[Vinícius Angiolucci Reis (angiolucci)]

Hi @macko, I can tell you some info about my hardware. But
unfortunately, building the MEI stuff into the kernel has not fixed the
problem: after ~7 days of use, it came back, just as you said.

> What is your exact model? (mine is NP900X4C-A02CH)
The exactly model is NP530U3C-AD5-BR

> Did you have the most recent firmware before the process? (mine is P07ABK
> although according to https://help.ubuntu.com/community/SamsungBIOS there
> is a more recent version)
The firmware version is P09ABH. It was the most recent version at the
moment when I've installed Linux (about 5 months ago), and I can't check
for a newer version because I need the samsung update tool, that only
runs on Windows.

> Can you spot any problems in the process? Or do you have any comments
> that may help me? Thanks in advance.
I didn't find any problems in the process. But unfortunately building
MEI modules into the kernel is not a solution.

--
  Vinícius Angiolucci Reis
  <email address hidden>

[Guillaume LAURENT (laurent-guillaume)]

I have a NP900X3C-A01FR also affected since 13.10.

It was working like a charm on 13.04 (never notice the issue), but after a SSD remplacement and a full reinstall to 13.10 I'm also affected by this weard bug.

Adapter status is reported correctly, but not the battery status.

Currently on battery, but shown as charging.

~$ acpi -i -b -a
Battery 0: Charging, 68%, 01:27:39 until charged
Battery 0: design capacity 5440 mAh, last full capacity 5200 mAh = 95%
Adapter 0: off-line

xfce4-power-manager (1.2.0) is not refreshed (still shown charging, full 100% right now)

Waiting kernel path I guess... :(

[paolo.mgi (paolo-mgi)]

I have a NP900X3C-A02UK with BIOS P04AAC.

I used the laptop for about one year with 12.10, battery detection worked mostly correctly.
Mostly means that I needed to reset the battery a couple of times during that period.

I recently installed 13.10 with kernel 3.11.0-15-generic.
After the upgrade, battery detection did not work neither worked after downgrading the kernel
to 3.11.0-12 nor after upgrading to 3.12.6 (upubuntu).
I went back to kernel 3.11.0-15-generic and reset the battery twice. Battery detection now works!

My inference is that the bug does not have anything to do with the kernel version.

[mmalmeida (mmalmeida)]

I am not sure by @angiolucci 's comment #90 if the solution is related to that kernel or to some other issue.

Has anyone else tested that kernel? Could angiolucci provide us with some feedback on the current status of his laptop?

[Vinícius Angiolucci Reis (angiolucci)]

@mmalmeida: I'm currently on 3.12.9 kernel release and the problem
persists. Reset the battery power as I mentioned before is only a
temporary solution. The problem always come back.

Em Sex 7 fev. 2014, às 9:09, mmalmeida escreveu:
> I am not sure by @angiolucci 's comment #90 if the solution is related
> to that kernel or to some other issue.
>
> Has anyone else tested that kernel? Could angiolucci provide us with
> some feedback on the current status of his laptop?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> Status in Linux ACPI client:
> Incomplete
> Status in “acpi” package in Ubuntu:
> Confirmed
>
> Bug description:
> I have a new Samsung 9-series laptop (NP900X3B) and the battery state
> is detected incorrectly. Basically the state what was at the time of
> boot stays active all the time - regardless of the ac-adapter state.
>
> Here is output from "acpitool -a -b" in various situations:
>
> When booted with charger connected and charger is still connected:
> Battery #1 : charging, 47.00%, 01:00:43
> AC adapter : on-line
>
> When booted with charger connected and charger is now disconnected:
> Battery #1 : charging, 47.00%, 01:36:59
> AC adapter : off-line
> [The battery couldn't possibly be charging when the AC adapter is
> offline!]
>
> When booted with charger disconnected and charger is still
> disconnected:
> Battery #1 : discharging, 47.00%, 01:39:44
> AC adapter : off-line
>
> When booted with charger disconnected and charger is now connected:
> Battery #1 : discharging, 47.00%, 00:53:43
> AC adapter : on-line
> [The battery is actually charging as the AC adapter is online]
>
> The percentage and time are correctly updated when the battery is
> actually charging or discharging - regardless of the reported state.
> So the state is the only thing that is incorrect. However a number of
> applications make their decisions based on this state (battery
> monitor, jupiter, etc.) and therefore behave incorrectly.
>
> "lshal -m" doesn't report anything when I plug the charger in or out.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: acpi (not installed)
> ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
> Uname: Linux 3.2.0-21-generic x86_64
> ApportVersion: 2.0-0ubuntu2
> Architecture: amd64
> Date: Sun Apr 1 22:50:35 2012
> EcryptfsInUse: Yes
> InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64
> (20120328)
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: acpi
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/acpi/+bug/971061/+subscriptions

--
  Vinícius Angiolucci Reis
  <email address hidden>

[juanmanuel (rockerito99)]

Hello!! After reading all the comments, and many tests of my own, I can conclude the following:

1) Kernel version / linux distro doesn't affect the issue.

2) It is a problem specific to suspending. If you don't suspend, you don't loose power monitoring/lid close.

3) There are two temporary fixes (let me contribute (B) here):

       A) Unplug laptop, then hit reset button through small hole in the back, then re-plug power to the laptop.

       B) Or: Reflash BIOS, any version, even the same one over (see my post at http://forum.notebookreview.com/samsung/683727-where-lid-closure-sensor-series-5-ultra-np530u3c.html#post9455595 in particular, please observe the "/n" switch of the flash utility mentioned in my post).

The (B) method explains why the problem goes away with a new BIOS update (the flashing tool clears the bios internal options (see sflash.exe /n switch)

Either fix is temporary and will return with an unlucky suspend/resume from sleep.

4) It is a BIOS problem, triggered by suspending in linux (and it got triggered by suspending in windows twice too in my case). The bios stops sending certain events (power, lid), because its state is corrupted somehow. When the laptop is in this state, dual booting windows has symptoms too (no lid detection, and unplug/replug events are reflected in windows' tray icon many seconds later, instead of instantaneously, as if by polling). Turning it off and on has no effect. Draining the battery has no effect. Toggling all options in the bios screen has no effect. The only fix is to do as in (3).

Now, Samsung uses some technology to have a mixed sleep, with the capability to hibernate after a threshold (time? battery-low?).
It has to do with "Intel Rapid Start" and Samsung Optimized power plan mode.

After reading the comments, I theorize that it's related to the fact that samsung expects some kind of hook to be present for when the laptop decides to quit regular sleep and ask Samsung/Intel's windows drivers to enter a deeper pseudo hibernation. (See option "Samsung Optimized" power plan in "Samsung Easy Settings" in windows).

I guess that both linux devs and samsung devs should work together to either: provide the second sleep hook, or a new bios that doesn't corrupt itself when not present.

Will this never get fixed? Will the same behavior happen with next generation Samsung models? Or some other model/brand that has intel rapid start?

BTW, I have a NP530U3C and been dealing with this issue as all of you guys. I hope this gets fixed since it is a nice ultrabook at a nice price, and this is the only problem that keeps me from fully enjoying it.

[juanmanuel (rockerito99)]

(let me add that I think the reason that it also happened to me by suspending in windows too, is that I disabled/uninstalled samsung's optimized power plan and intel rapid start, as I usually disable or uninstall the "extras").

I think that there is something in the bios that expects to be able to go to deep sleep, and its state is corrupted somehow if it doesn't.

Here is some excerpt from some "Intel Rapid Start" literature:

--------
        Power Manager refers to Intel Rapid Start Technology as "30 Day Standby". The "30 Day Standby" uses a special Hibernation partition on the SSD to capture the contents of system memory.
        The benefit is a longer battery life (compared to standard Sleep mode) and shorter resume time (compared to standard Hibernate mode).
        To enable "30 Day Standby", the user will need to create a special Hibernation partition on the SSD and also to install Power Manager.
--------

I guess that the laptop first goes into normal sleep, keeping the RAM powered. And then wakes up briefly to serialize the RAM to an SSD partition if it was sleeping for a while, or with lower battery, to be able to remove power to the RAM.
Either that, or maybe it expects the OS to have serialized the RAM to the internal SSD to already have the RAM,, and a hook to wake up. IDK. It's my best guess.

PS: I dual boot win7 and Kubuntu 13.10. I have the Samsung NP530U3C running bios P14AAJ.

[juanmanuel (rockerito99)]

PS: My laptop has a 24GB SSD (alongside a 500GB HDD), in which there was originally two partitions (one used by Samsung ExpressCache, the other one I guess used by Intel Rapid Start).

and... I reformated the SSD partition to install linux there when I bought it. Lucky I kept the layout:

------------
   Device Boot Start End Blocks Id System
/dev/sdb1 2048 37457919 18727936 73 Unknown
/dev/sdb2 37457920 46895103 4718592 84 OS/2 hidden C: drive
------------

Maybe the BIOS/chipset expects an SSD partition with such and such id (84) to have suspend work properly??

(see https://communities.intel.com/message/175742 )

[juanmanuel (rockerito99)]

I made further tests, and can now RULE OUT completely Intel Rapid Start from being a factor. So please IGNORE my previous post.

But,
I found the cause of the problem!!!!!, (but not the solution... yet):

I found that the problem manifests when doing many things (16 or more) that would produce an ACPI event, while the laptop is suspended. If so, the motherboard's Embedded Controller stops sending events.

If, while in sleep, you unplug or plug the laptop 8 times, then the problem manifests.
Each time that you plug or unplug the laptop's PSU, a pair of ADP1 (AC power event) BAT1 (Battery event) events are produced (signals _Q51 or _Q52 (AC) and _Q53 and _Q54 (battery) of the DSDT are executed, which notify the devices ADP1, BAT1 and the CPUs). So that is two GPE events per plug or unplug, for a total of 16 if you plug/unplug 8 times.

Also, if the laptop is unplugged while suspended, an event is produced each time that the battery percentage changes (_Q53 and _Q54). So, if you leave it unplugged and suspended for 8 hours or more (assuming 2% battery drop per hour), the problem then manifests. If it was plugged, and it charges 16% or more of battery, the problem manifests.

LID close/open events count too.

The only way that you can ensure that the problem will not manifest, is by having the battery at 100% before suspending, and leaving it plugged in, and without opening/closing the lid too many times. In my tests, no matter how many days suspended, this never produced "the lid-not-detected-battery-not-detected-syndrome", which can only be gotten out of by turning the computer off, unplugging it, and hitting the reset button through the small hole in the back.

This is clearly a problem with the embedded controller trying to report AC/Battery/LID events while the computer is asleep, and having some kind of internal buffer get full (16 events).

REPRODUCING THE PROBLEM QUICKLY:
The easier way to reproduce the problem, is:
     1) Suspend the computer
     2) Unplug PSU, plug, unplug, plug, unplug, plug, unplug, plug (8 actions each produces 2 GPE events).
     3) Resume. Then, you can see that plugging or unplugging the PSU isn't detected, and LID close is ignored.

I ruled out the following things, which DON'T produce an effect:

     1) Battery Life Extension enabled or disabled. Crossing 80% battery charge while sleep. No effect.
     2) Intel Rapid Start. Enabled or disabled, partition or no partition. intel_irst module and wakeup_time and wakeup_events parameters don't have an effect.
     3) How many suspends without restarting doesn't have an effect.
     4) Wifi on or off. Downloading or not.
     5) FAN spinning with CPU temp above 70, no effect. (doesn't help nor make it worse).
     6) acpi_osi="!Windows 2012" acpi_osi="Windows 2009", etc. No effect.
     7) Changing /sys/module/acpi/parameters/ec_delay or ec_storm_threshold no effect (though interesting to research further, only tried 20ms and 2048 respectively; the defaults are 500ms and 8 respectively).

I still haven't found a workaround or solution. I studied the DSDT of my NP530U3C, looking for a way to disable or mask the EmbeddedController events (AC, battery, LID)...

[juanmanuel (rockerito99)]

Attached DSDT of a Samsung Series 5 NP530U3C ultrabook with the same problem. Bios version is latest: P14AAJ

[juanmanuel (rockerito99)]

FINALLY!! I found the exact problem _and_ a SOLUTION!!! (NOTE: see attached program)

The problem is that Samsung's embedded controller stops sending GPE events if it still is waiting for previous GPE events to be queried from it.

It will remain in that state until one hits the reset hole in the back of the latop, or flashes a bios, or queries the events.

---> But how will the OS query the events if the GPE interrupt isn't produced anymore? Classic chicken and egg. <----

So I made a small program that does just that -- it queries events from the EC until there are no more to query. AND IT WORKED!! This restores the normal behavior, and AC, Battery and LID events start to be produced again. One would ideally run it after resume from sleep. I based it after observing normal behavior in <linuxkernel>/drivers/acpi/ec.c, and afterwards behaviour with laptop in "problem state".

Following is the program (I will attach it too). You can either:

     1) Run it by hand after resume from sleep.

     2) Or Automatically run it from /usr/lib/pm-utils/sleep.d/99-your-script-here (you can use 95led as basis).

     3) Or Insert this code in the linux kernel at the beginning of the acpi_ec_unblock_transactions_early() function in "<linuxkernel>/drivers/acpi/ec.c" and recompile the kernel. The cmd and data ports are known in ec.c so they don't need to be hardcoded there.

PS: Other things that I already tried that didn't fix it:
    1) Please note that I already tried commenting "acpi_disable_all_gpes()" from "<linuxkernel>/drivers/acpi/sleep.c" and this didn't have an effect (I guess unreplied events were already accumulated in the EC prior to resume).
    2) I also tried reverting to calling acpi_enable() on sleep.c instead of setting the ACPI_BITREG_SCI_ENABLE. No effect, issue still resurfaced after some suspends.
    3) I also tried commenting out the call to acpi_ec_unblock_transactions_early() in sleep.c, but no effect.

PS2: Another way to force the embedded controller to be in a problem state that I discovered, is to:
      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

Following are the two files with fixes which I'll attach too:

NOTE: you must check that embedded controller ports are 0x62 and 0x66 looking in your DSDT. RUN AT YOUR OWN RISK!!!

---- samsung_fix_ec_events.c ------------------------------------------
#include <stdio.h>
#include <unistd.h>
#include <sys/io.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 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: */
    ACPI_EC_COMMAND_QUERY = 0x84,

    /* ATTENTION: PLEASE edit the following two according to your DSDT.
     * For "Samsung Series 5 NP530U3C", they are 0x62 and 0x66 respectively.
     * They seem to be...

[juanmanuel (rockerito99)]

This program "unstucks" the computer so that it can send LID and AC and Battery events again. (it queries the embedded controller queued events, thus unblocking the EC so that it can start sending them again).
Ideally run after resume from sleep, or at any other time.

[juanmanuel (rockerito99)]

99samsung_fix_ec_events

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "samsung_fix_ec_events.c" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Nuno Cardoso (nunopcardoso)]

It works like a charm on my laptop (NP530U3B).
Thank you so very much for finally solving this long lasting and annoying problem.

[Kieran Clancy (clancy-kieran+launchpad)]

Thank you so much jaunmanuel!

I can confirm this is working on my NP900X3F.

Also, an easy way to check the command/data codes is:

$ dmesg | grep EC:
[ 0.119227] ACPI: EC: Look up EC in DSDT
[ 0.586520] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62

So no changes are needed to your code for my laptop (0x66, 0x62).

Ultimately, it would be best to have this fixed in the kernel; I have posted the news in the kernel bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=44161

[Mattia Guidi (matguidi)]

The command "dmesg | grep EC" doesn't let me retrieve that information. I have a Samsung NP535U3C. How can I obtain those two values ("command/status" and "data")?

[Mattia Guidi (matguidi)]

Also: do I need a "hard reset" to make the script work? I've saved the script in /usr/lib/pm-utils/sleep.d, suspended, resumed, but closing the lid didn't trigger a suspension. So I was wondering if some other operation is needed to make it work. Thanks again to juanmanuel for the effort and the patience with this issue.

[Moræus (moraus)]

I can confirm this works on a Samsung NP900x4c.

The same EC port range in DSDT.

Great work! Thanks a lot.

Sent from my iPhone

> On 18 Feb 2014, at 18:49, juanmanuel <email address hidden> wrote:
>
> FINALLY!! I found the exact problem _and_ a SOLUTION!!! (NOTE: see
> attached program)
>
> The problem is that Samsung's embedded controller stops sending GPE
> events if it still is waiting for previous GPE events to be queried from
> it.
>
> It will remain in that state until one hits the reset hole in the back
> of the latop, or flashes a bios, or queries the events.
>
> ---> But how will the OS query the events if the GPE interrupt isn't
> produced anymore? Classic chicken and egg. <----
>
> So I made a small program that does just that -- it queries events from
> the EC until there are no more to query. AND IT WORKED!! This restores
> the normal behavior, and AC, Battery and LID events start to be produced
> again. One would ideally run it after resume from sleep. I based it
> after observing normal behavior in <linuxkernel>/drivers/acpi/ec.c, and
> afterwards behaviour with laptop in "problem state".
>
> Following is the program (I will attach it too). You can either:
>
> 1) Run it by hand after resume from sleep.
>
> 2) Or Automatically run it from /usr/lib/pm-utils/sleep.d/99-your-
> script-here (you can use 95led as basis).
>
> 3) Or Insert this code in the linux kernel at the beginning of the
> acpi_ec_unblock_transactions_early() function in
> "<linuxkernel>/drivers/acpi/ec.c" and recompile the kernel. The cmd and
> data ports are known in ec.c so they don't need to be hardcoded there.
>
> PS: Other things that I already tried that didn't fix it:
> 1) Please note that I already tried commenting "acpi_disable_all_gpes()" from "<linuxkernel>/drivers/acpi/sleep.c" and this didn't have an effect (I guess unreplied events were already accumulated in the EC prior to resume).
> 2) I also tried reverting to calling acpi_enable() on sleep.c instead of setting the ACPI_BITREG_SCI_ENABLE. No effect, issue still resurfaced after some suspends.
> 3) I also tried commenting out the call to acpi_ec_unblock_transactions_early() in sleep.c, but no effect.
>
> PS2: Another way to force the embedded controller to be in a problem state that I discovered, is to:
> 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
>
>
> Following are the two files with fixes which I'll attach too:
>
> NOTE: you must check that embedded controller ports are 0x62 and 0x66
> looking in your DSDT. RUN AT YOUR OWN RISK!!!
>
> ---- samsung_fix_ec_events.c ------------------------------------------
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/io.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 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/
> */
>
...

[Marcus Sundman (sundman)]

Mattia, you need the samsung_fix_ec_events program in addition to the script which calls that program. You can also run the program manually (after compiling it of course):

$ gcc -o samsung_fix_ec_events samsung_fix_ec_events.c
$ sudo ./samsung_fix_ec_events
EmbeddedController GPE events flushed. New events can be produced now.

[macko (erdosboti)]

Thank you juanmanuel very much. Works like a charm.

[Mattia Guidi (matguidi)]

Ok, I confirm the script works with a Samsung NP535U3C (no changes needed).

[Sergey Tryuber (stryuber)]

Also confirm it fixed the issue with NP900X3C (no changes needed). Kubuntu 12.04LTS. Thanks a lot!

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

Thanks for the script. :)

[Tim Edwards (tkedwards)]

Great work juanmanuel!

This suspend/resume problem was the last thing on this laptop not properly supported by Ubuntu and now it's fixed. Hopefully you can get the kernel developers to include a patch.

For anyone who can't get the command/data codes you need to reboot your laptop before running "dmesg | grep EC:" (the kernel ring buffer that dmesg reads only has a limited size so boot messages will eventually get overwritten)

[Lops (lops777)]

Can confirm that it works now on

Samsung Series 9 np900x3f
Ubuntu 13.10

Thanks alot juanmanuel!! Nice work..

[juanmanuel (rockerito99)]

I'm very glad!! You're welcome all of you!!!!!!!!!

Nothing beats the feeling of having the whole laptop work properly !!!

Can't believe this bug affected so many samsung models. So far I've seen:

        Samsung Series 5 (models NP530U3C, NP535U3C, NP530U3B)

        Samsung Series 9 (models NP900X3F, NP900X4B)

Does the NP900X4B work with the fix too?

I'm glad that my research was successful, It's like having a brand new laptop all over again (mine is the NP530U3C).
--
Juan Manuel

[juanmanuel (rockerito99)]

(Also confirmed in this thread Samsung NP900x4c )

[juanmanuel (rockerito99)]

Following the link:

      https://bugzilla.kernel.org/show_bug.cgi?id=44161

I read that someone noted that AC was reported correctly after suspend, even though the EC events were consumed by the little program on resume.

I'll reply here to that since I don't have an account there:

The reason is because the DSDT method called _WAK (short for "AWAKE"), is called when resuming from sleep. If you look at the code in the DSDT, you'll see that this method checks to see if AC, LID, and Battery have changed since suspend, and issues the corresponding Notify() calls, thus producing the relevant events, when waking up, independently of the EC.

--
Juan Manuel

[tristan_lefebure (tristanl)]

Bug also fixed for a NP530U4B

Thank you Juan

On Wed, Feb 19, 2014 at 7:05 PM, juanmanuel <email address hidden> wrote:

> (Also confirmed in this thread Samsung NP900x4c )
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (967161).
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/acpi/+bug/971061/+subscriptions
>

[Guillaume LAURENT (laurent-guillaume)]

I confirm the bug on NP900X3C too, will try samsung_fix_ec_events tonight.

[Marcus Sundman (sundman)]

I confirm that the fix also works for the NP900X4D.

[Mark Lewis (mark-fortressofgeekdom)]

I confirm that the fix also works without changes for NP900X3B

[juanmanuel (rockerito99)]

I want to give thanks to Kieran Clancy for commenting on the kernel bugzilla, lets hope that they incorporate the fix so that non-tech-saavy people can benefit too.

I just registered in the kernel bugzilla to post a summary of the problem.

           https://bugzilla.kernel.org/show_bug.cgi?id=44161

I guess the best place to incorporate a fix would be as I said previously, at the function acpi_ec_unblock_transactions_early() which is called at the right time in the resume process (and despit its name it doesn't unblock nothing currently).
THat function is in sleep.c which already incorporates quircks for different models and can judge whether to query the events (though it would be harmless to do the query on models without the problem, it is a standard query of events).

--
Juan Manuel

[Guillaume LAURENT (laurent-guillaume)]

Yes, it's do the trick on a np900x3c too.

$ dmesg|grep -i dmi
[ 0.000000] DMI: SAMSUNG ELECTRONICS CO., LTD. 900X3C/900X3D/900X4C/900X4D/SAMSUNG_NP1234567890, BIOS P06AAC 02/08/2013

$ dmesg | grep EC:
[ 0.148655] ACPI: EC: Look up EC in DSDT
[ 0.643731] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62

Xubuntu 13.10

Linux np900x3c 3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Can't believe that a so " simple " script do the trick for an almost 2 years issues...

Thanks a lot juanmanuel

[Gaston M. Tonietti (gaston-tonietti)]

It works like a charm on my ultra-book NP530U3C

Thank you so much Juan Manuel for fixing this annoying and old bug. I love you so much man (in an open source way).

[mmalmeida (mmalmeida)]

From what I can tell the program fixed the issue in my NP900X4C!

Now the only thing missing from having the perfect ubuntu experience is the keyboard backlight working properly (not working at all right now). :)

[daniele3 (3daniele03)]

Keyboard backlight works perfectly for me with Gentoo (series 9).
I can switch it on/off with the appropriate keys and the light sensor is working fine.

[Kieran Clancy (clancy-kieran+launchpad)]

For me this also leaves just the keyboard backlight, which doesn't work.

I believe that's a UEFI bug though, since Samsung's special hardware features are disabled in UEFI mode.

If the backlight is working for you, this probably means you're not using UEFI - although if you have your backlight working under UEFI, I'd be interested to hear.

[daniele3 (3daniele03)]

I am not using UEFI, indeed

[juanmanuel (rockerito99)]

The keyboard backlight issue is separate from this issue, and is not a hardware problem.

Rather, that the linux devs decided to disable the samsung-laptop.c module in the kernel when you boot with UEFI, as a preventive measure when it still wasn't clear how linux interacted with that famous samsung uefi bug.
Looking in:

         http://lxr.free-electrons.com/source/drivers/platform/x86/samsung-laptop.c

I see that the following lines prevent the module from being initialized when you use UEFI, and so keyboard backlighting isn't enabled:

             1548 if (efi_enabled(EFI_BOOT))
             1549 return -ENODEV;

If those two lines were introduced as a preventive measure or as a real fix for the famous samsung UEFI bug, I don't know. I have a series 5 NP530U3C which doesn't have backlighting. DO NOT uncomment those lines and recompile the kernel, unless some expert on that old famous UEFI bug says its ok to do so.

But again, it is a separate issue and it's clear that the lack of keyboard backlighting is a software thing and not related to the bugs fixed here by my workaround, by unblocking the EC embedded controller.

The workaround fix I posted in posts #101 through #103 fixes the "problem state" that the laptop gets into from a "bad" suspend/resume, in which LID close events are not generated, and AC plugged in status is ignored, and battery charge changed events are not generated (and maybe some temperature alert / changed issues too). And of which one could only got out by hitting the reset button through the hole in the back while turned off.

Cheers!
--
Juan Manuel Cabo

[daniele3 (3daniele03)]

I am not quite sure that the keyboard backlight sensor is independent from this bug. In my case (without UEFI) the sensor does not work when the the laptop cannot detect the AC plugged status. After the fix (or after resetting the battery) the sensor works correctly (the keyboard gets illuminated when the ambient is dark). Manually inserting 0 or 8 in /sys/devices/platform/samsung/leds/samsung::kbd_backlight/brightness on the other hand always works.

[juanmanuel (rockerito99)]

Yes! you're right! Looking at the DSDT I see that there are two fields, LUXH and LUXL declared in the EC operation region, which I can only guess by their name are for an ambient light sensor -- in the models that have it (mine doesn't have it). Maybe some light sensor change event wasn't produced in the problem state.

So, one more thing added to the list of fixes!

Thanks for illuminating us!!! ;-)

--
Juan Manuel Cabo

[penalvch (penalvch)]

This is not a bug in acpi (Ubuntu) as this is just a software package that displays information. Instead, this would be a bug in the linux kernel (ex. samsung-laptop.c) for not handling the laptop lid logic correctly.

[mmalmeida (mmalmeida)]

FYI, the backlight sensor problem was reported here - https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1203592

[juanmanuel (rockerito99)]

> This is not a bug in acpi (Ubuntu) as this is just a software package that displays
> information. Instead, this would be a bug in the linux kernel (ex. samsung-laptop.c)
> for not handling the laptop lid logic correctly.

No, you are confounding two issues.

This is a buggy behaviour in samsung's EC embedded controller when going to sleep and resuming, that can
only be fixed in linux kernel ACPI handling of it ( <linuxkernel>/drivers/acpi/ec.c ).
There is a patch ready in the kernel bugzilla, that adds a few lines to "acpi/ec.c", that I personally
tested and confirmed that does the same as my userspace workaround (unstuck the samsung
ACPI embedded controller):

      https://bugzilla.kernel.org/show_bug.cgi?id=44161 (comments 133 and 135)

samsung-laptop.c has nothing to do with ACPI or the LID detection or this bug.
samsung-laptop.c uses a SABI interface.
The reason samsung-laptop.c came up, was because that file disables keyboard backlight under certain
conditions, and some people said that now that the LID and AC status works with my fix, that
now keyboard backlight was the only thing missing for linux compatibility. I just brought up
samsung-laptop.c to point to how to fix that last, separate, independant remaining problem
of keyboard backlight.

LID detection and AC status detection, is handled by standard ACPI drivers in these laptops.

So, this _is_ a bug that is fixed by patching ACPI's drivers/acpi/ec.c.
(or by my userspace program that pokes two EC ports, post #103).

Cheers
--
Juan Manuel Cabo

[juanmanuel (rockerito99)]

I'm sorry, yes, its not a bug in the userspace acpi program,
rather a problem that can be fixed by the kernel ACPI or a userspace workaround (post #103).
Cheers
--
Juan Manuel Cabo

[penalvch (penalvch)]

erikj, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux 971061

If reproducible, could you also please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-3.14-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[erikj (erik-jogi)]

Hi,

What do you mean by "there hasn't been any activity in it recently"? Have
you checked the comments? One person actually found a workaround after
almost 2 years. There has been a ton of happy comments on that.

But for myself - I am not using the laptop nor Ubuntu anymore, so I cannot
confirm anything about it.

But if you check the comments then it is quite obvious that the problem is
still there and there is a small program that you can use for a workaround.

Regards,
Erik

On Sat, Feb 22, 2014 at 1:07 PM, Christopher M. Penalver <
<email address hidden>> wrote:

> erikj, this bug was reported a while ago and there hasn't been any
> activity in it recently. We were wondering if this is still an issue? If
> so, could you please test for this with the latest development release
> of Ubuntu? ISO images are available from http://cdimage.ubuntu.com
> /daily-live/current/ .
>
> If it remains an issue, could you please run the following command in
> the development release from a Terminal
> (Applications->Accessories->Terminal), as it will automatically gather
> and attach updated debug information to this report:
>
> apport-collect -p linux 971061
>
> If reproducible, could you also please test the latest upstream kernel
> available (not the daily folder) following
> https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional
> upstream developers to examine the issue. Once you've tested the upstream
> kernel, please comment on which kernel version specifically you tested. If
> this bug is fixed in the mainline kernel, please add the following tags:
> kernel-fixed-upstream
> kernel-fixed-upstream-VERSION-NUMBER
>
> where VERSION-NUMBER is the version number of the kernel you tested. For
> example:
> kernel-fixed-upstream-3.14-rc3
>
> This can be done by clicking on the yellow circle with a black pencil icon
> next to the word Tags located at the bottom of the bug description. As
> well, please remove the tag:
> needs-upstream-testing
>
> If the mainline kernel does not fix this bug, please add the following
> tags:
> kernel-bug-exists-upstream
> kernel-bug-exists-upstream-VERSION-NUMBER
>
> As well, please remove the tag:
> needs-upstream-testing
>
> Once testing of the upstream kernel is complete, please mark this bug's
> Status as Confirmed. Please let us know your results. Thank you for your
> understanding.
>
> ** Tags added: quantal
>
> ** Tags removed: acpi battery
> ** Tags added: needs-kernel-logs needs-upstream-testing
>
> ** Changed in: linux (Ubuntu)
> Importance: Undecided => Medium
>
> ** Changed in: linux (Ubuntu)
> Status: Confirmed => Incomplete
>
> ** Project changed: acpi => linux
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/971061
>
> Title:
> acpi reports battery state incorrectly
>
> Status in The Linux Kernel:
> Incomplete
> Status in "linux" package in Ubuntu:
> Incomplete
>
> Bug description:
> I have a new Samsung 9-series laptop (NP900X3B) and the battery state
> is detected incorrectly. Basically the state what was at the time of
> boot stays active all the time - regardless of the ac-adapt...

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

I find it quite *outrageous* that the bug is not considered "confirmed" anymore. I am confirming it again since it affects multiple users.

[penalvch (penalvch)]

erikj, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971061/comments/140 regarding you no longer use the hardware originally reported against. 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.

Andrea Lazzarotto, given linux (Ubuntu) bugs are treated on a per hardware, and per original reporter basis, this wouldn't ever be considered confirmed. If you have a bug in Ubuntu, and so your hardware and problem may be tracked, please feel free to file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

We were talking about a bug which affects >100 users of Ubuntu Saucy (using the same Samsung hardware), and you decided to mark it as regarding Quantal in order to say it's invalid. Well, your abuse of power is quite remarkable, if not offensive.

If this is how you (I mean you, not the Ubuntu team in general) deal with bugs, you can well imagine I am not going to perform any more bug submissions here.

[Ayberk Özgür (equilibriumtr)]

I too can confirm that everything is resolved including lid close, ac plug/unplug and keyboard backlight on NP900X4C.

[penalvch (penalvch)]

Ayberk Özgür, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Tomer (tbrisker)]

Hello Christopher M. Penalver,
I am amazed by your actions in this bug.
The Ubuntu bug triage team should work on making sure bugs are fixed, not on closing bugs that affect hundreds of users because of technicalities.
juanmanuel found a solution for this bug after almost a year without any action on part of the ubuntu team, and your response, instead of making sure the fix gets incorporated into Ubuntu, is to close the bug report???
I simply cannot see the logic of your actions - other then wanting to show a large number of bug reports "closed", no matter what.
I am reopening the bug and I am sure everyone here who are affected would agree that juanmanuels fix (which works so far for everyone involved) should be used rather then filing more useless bug reports for the bug that already has a fix.

[penalvch (penalvch)]

Tomer, please do not toggle the Status of this report. The policies are set in place as per the Ubuntu Kernel Team. If you are having a problem in Ubuntu, you are welcome to file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[mmalmeida (mmalmeida)]

Christopher - this is beyond silly!

Why on earth would you want to scatter the information around 100 individual bugs when it affects MULTIPLE USERS as you MAY HAVE NOTICED if you have read this thread at all.

On behalf of the 106 people who this issue affects, kindly let us know:

- How should we proceed in order to have A SINGLE BUG the 106 users can subscribe to? We don't want to subscribe to 106 bugs and, as I am sure you can imagine, juanmanuel, who was kind enough to find solution, will definitely not want to post the same solution to 106 bug reports.

[Tomer (tbrisker)]

Christopher,
You are abusing your power as member of the bug control team.
This bug has no reason being closed, other then taking two years to be noticed by the ubuntu team, during which the original reporter changed his hardware.
However, the bug has been confirmed by multiple other users over the time, and a fix has been found and confirmed to be working by many of the people affected (myself included).
Why on earth would you want to close this bug instead of making sure the fix makes it to the kernel team???

[Marcello (pogliamarci)]

Hello,
   I am affected by this bug since, a couple of years (same laptop here,
530U). I have personally experienced it on my laptop on multiple Linux
distributions (including Debian and Arch).

I perfectly understand your policies, but I do not really see the
rationale behind closing the bug with WONTFIX and asking a lot of people
to open a lot of new bugs to signal the very same thing.

For me, the bug is indeed solved by the juanmanuel's userspace program
(thanks a lot!!!!!!!!!) I've been running that program since it was
posted on this thread, and it works like a charm.

The bug is also clearly described upstream on the kernel Bugzilla, where
juanmanuel's solution is being turned into a kernel patch, so an
upstream fix is likely to be on the way.

I hope you'll find a way to put in evidence the relevant information,
especially when there will be 100 opened issues for this SINGLE problem
(or 100 issues immediately closed as duplicates???): this is clearly a
SINGLE bug with a SINGLE reference to a SINGLE upstream issue.

>From my side, I am *not* going to open another bug just to increase the
Internet entropy (and reduce the likelihood for someone searching about
the problem to find the workaround)...

[erikj (erik-jogi)]

As the original reporter I want to apologise to all of the affected people here - I was not aware that my comment that I don't own the hardware anymore will result in the bug being closed as "won't fix".

Hopefully the patch will make it to the kernel and the fix will reach Ubuntu anyway.

If not then I can offer this: If anyone with the NP900X3B laptop is willing to test actually the latest builds mentioned in Christopher M. Penalver comment #139 then I can claim to the Ubuntu folks that I reclaimed my laptop from my daughter and confirm the bug again. ;-)

Regards,
Erik

[juanmanuel (rockerito99)]

> If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

I downloaded trusty-desktop-amd64.iso from that link, and tested with my Series 5 NP530U3C, and the issue still persist in the latest ubuntu. So, latest ubuntu is the same.

Here is what I did:
     1) Downloaded ISO image
     2) Put it in a 2GB pendrive using 'unetbootin' to transfer it there.
     3) Booted up, selected "Try ubuntu without installing".
     4) Started acpi_listen, I see that plugging and unplugging are recognized as events.
     5) Suspended the laptop by closing the lid.
     6) Unplugged, plugged, unplugged..... (8 actions or more) while suspended.
     7) Resumed from sleep.
     8) ----> Now events are NOT produced anymore and the laptop got into "problem state". <----
          Closing the lid doesn't suspend the laptop. The battery icon says charging even though the ultrabook is unplugged from the wall.

No surprise there. Still UNFIXED in latest ubuntu (the ISO file has a date of 2014-02-22 in that download site).

Another way to get the laptop into "problem state" would be to let it discharge or charge by 16% while suspended in S3 sleep.

Christopher:
Should I file a new bug report?
--
Juan Manuel Cabo

[penalvch (penalvch)]

Juan Manuel Cabo, yes.

[juanmanuel (rockerito99)]

Christopher: I created the new issue here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1283589
--
Juan Manuel Cabo

[juanmanuel (rockerito99)]

I also wanted to put all the info in one place, so I made this blog here:

           http://www.zenstep.com.ar/samsung-linux

Cheers
--
Juan Manuel Cabo

[paolo.mgi (paolo-mgi)]

I am on an NP900X3C-A02UK with Ubuntu Gnome 13.10. The patch works for me out of the box. Battery status report and suspend on lid closed work now correctly. De todo corazón muchas gracias, juan manuel!

[Mattia Guidi (matguidi)]

And please, to all those who are affected by this bug, go to the new bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1283589) that Juan Manuel opened and let the Ubuntu guys know that it affects you.

[juanmanuel (rockerito99)]

UPDATED v2: Safer because it obtains the EC ports automatically from /proc/ioports, and it micro-pauses between queries, so that the EC returns each event only once. This replaces the little program in #3.
________
This is the program I made, that "unstucks" the computer so that it can send LID and AC and Battery events again. (it queries the embedded controller queued events, thus unblocking the EC so that it can start sending them again).

Ideally run after resume from sleep, or at any other time.

[juanmanuel (rockerito99)]

Breaking News!

A fix in the form of a kernel patch has now been posted to the linux-acpi and linux-kernel mailing list:

        "[PATCH v2] ACPI / EC: Clear stale EC events on Samsung systems"
        http://marc.info/?l=linux-acpi&m=139359680828880&w=2

That kernel patch was made by Kieran Clancy and tested by me and others.

--
Juan Manuel Cabo
http://zenstep.com.ar/samsung-linux

[svenmeier (sven-meiers)]

Works fine with 14.04 on my 900x3c

[Kira (kirasglimmer)]

This happens for me.

Linux 4.15.0-34-generic #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

I'm running Linux Mint 19 Cinnamon 3.8.9. If I disconnect power, remove the back cover, disconnect both the main battery and the backup battery, I am able to get power status updates (e.g. battery will show as charging/charged when plugged in, or just regular battery when not). Once I sleep, I have to repeat this process if I want the battery status to work again.

`acpi -p` correctly shows the charging state, but `tlp-stat -b` does not.

`acpitool -ab` shows when unplugged,
  Battery #1 : Charging, 100.0%, 00:00:00
  AC adapter : off-line

and when plugged in:
  Battery #1 : Charging, 100.0%, 00:00:00
  AC adapter : online

Note: Battery charge percentage does work.

[Gioele Barabucci (gioele)]

Matthew, this is the original bug report, fixed in 2012 and now closed.

I have opened another bug for the regression in 4.15 with your description of the problem (that is similar to what I am experiencing): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1792672