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

[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