Hi all !

I'm using KDE 4.9.1 on archlinux x86_64 and have been on IRC already to find a solution to these problems:

• The button's action "As lid is closed" (sorry for the translation not being accurate, but I'm using KDE in french) is set as "Suspend" and does not work.
• As unplugged from sector, the energy profile does not switch to "Off-line" (this topic)

I have a systemd init system (no hybrid with sysvinit) and therefore acpid is not installed (cf here)
acpi is installed and behaves strangely :
When I boot or resume and my computer is plugged to sector, the

Code: Select all

acpi -V

gives me the right output:

Code: Select all

Battery 0: Charging, 97%, 00:09:25 until charged
Battery 0:[...]
Adapter 0: on-line
Thermal 0[-1 ...]
Cooling 0[-10 ...]

And when the unplugged, I get this:

Code: Select all

Battery 0: Charging, 97%, 00:10:24 until charged
Battery 0:[...]
Adapter 0: off-line
[...]

which is obviously wrong.

But, when I boot or resume unplugged, I get the right output

Code: Select all

Battery 0: Discharging, 97%, 02:10:24 remaining
Battery 0:[...]
Adapter 0: off-line
[...]

and then, when I plug my computer, again, something wrong :

Code: Select all

Battery 0: Discharging, 97%, 02:10:24 remaining
Battery 0:[...]
Adapter 0: on-line
[...]

The battery plasmoid does neither shows the right status (ON-OFF line) whenever it changed since boot or resume.
I'd like to add to my KDE a script looking for the value of "Adaptater 0" and automatically switch to the good profile.

If it ever is a known bug, sorry for posting here, because I did not find a report about it.

Thanks for helping me !

Do you have UPower (version 1) installed?
Also, what version of KDE are you using - and is ConsoleKit installed and running?

-- Edit --
It turns out that the Linux support for this hardware is a touch lacking - detection of AC Power and the lid being closed doesn't function at the moment.

I'd try the 'upower --monitor' command, Lukas Tinkl gave me that advice on IRC. Once you've started that, see if closing the lid and/or removing the power plug gives any output. If not, this could be the same issue as I have with my NP900X3C, see my blog: http://blog.jospoortvliet.com/2012/09/linux-and-samsung-series-9-np900x3c.html

If so, it is a driver or bios problem and updates to Linux infrastructure (upower & friends) and the kernel itself will fix it - but not yet. The 3.6 kernel at least still has the problem and so does upower 0.9.18 (the latest version at time of writing). See my comments at the bottom of the blog.

In short, if this is the case I suggest you might have to wait until this is fixed (or go and chat up the kernel developers - there's a bug mentioned in my blog).

If you DO see output on upower --monitor, the problem might be with powerdevel and filing a bug might be a good next step. Include the output of upower --dump when the lid is closed and the power is attached and again with the lid open and the powerplug NOT attached.

TIP: how do you enter the command with the lid closed? use 'sleep' like this:

Code: Select all

sleep 10s && upower --dump > lidclosedpowerattached.txt

Hit enter, close the lid, wait more than 10 secons. You now have a lidclosedpowerattached.txt file with the output of upower --dump in it.

Obviously, do it with a different txt file name (eg lidopenpowernotattached.txt) and without the sleep to catch the data in the open/disconnected state.

Have fun

Thanks for the answers!

So, in the right order:

I use KDE 4.9.1, see first post, after 'Hi all!'

upower is intalled:

Code: Select all

% upower --version
UPower client version 0.9.18
UPower daemon version 0.9.18

Then, console-kit is up & running:

Code: Select all

console-kit-daemon.service - Console Manager
          Loaded: loaded (/usr/lib/systemd/system/console-kit-daemon.service; enabled)
          Active: active (running) since Thu, 27 Sep 2012 07:29:48 +0200; 18min ago
        Main PID: 290 (console-kit-dae)
          CGroup: name=systemd:/system/console-kit-daemon.service
                  └ 290 /usr/sbin/console-kit-daemon --no-daemon

Sep 27 07:29:48 psychopathy console-kit-daemon[290]: missing action

The monitoring does not give anything expect that:

Code: Select all

% upower --monitor
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[07:49:58.078]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:50:28.088]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:50:58.090]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:51:28.091]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:51:58.068]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:52:28.091]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:52:58.091]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:53:28.074]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:53:58.078]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:54:28.074]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:54:58.089]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:55:28.078]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:55:58.077]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:56:28.090]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:56:58.073]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:57:28.077]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:57:58.092]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:58:28.082]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:58:58.078]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1
[07:59:28.092]  device changed:     /org/freedesktop/UPower/devices/battery_BAT1

(I did close/open lid, as you told but this appears to happen every 30 seconds... no matter if on/off-line, after or before resume...)

Based on that I'd say the problem is indeed in either bios/firmware or drivers. Maybe, MAYBE in upower but I doubt that. In short - you'll have to look at bugzilla.kernel.org or yell at Samsung (that won't help, I suppose, but might make you feel better).

Good luck...

Well, I did go into the BIOS to take a look at options: nothing interesting....

Plus, I updated the BIOS with the .exe I downloaded @ Samsung's website.

Well then, I'll cry alone in my corner

Anyways, thank you for helping me

I found a SOLUTION !!!!!!!
I wrote it up first in: http://forum.notebookreview.com/samsung ... 30u3c.html
I'll put the solution here too:

TL;DR: "Force a reflash to the BIOS, even if you already have the newest BIOS, and you will be able to suspend on lid close and autodetect unplug/replug"


I bought my Samsung NP530U3C-AB1AR a week ago, and everything was working smoothly, until yesterday, when I noticed two things:

1. Closing the LID was not detected by either Windows or Linux, and it lost the capability to suspend by closing the lid.
   
2. Unplugging the power supply was not detected anymore by linux. And in windows it wasn't auto detected, though it detected it several seconds after unplugging, as if by polling.

It was obvious that this was a hardware/bios issue, since both OS's had the symptoms.

The lid sensor was working fine, so it wasn't a purely hardware issue (you could see the screen turn off when lowering it, and then ON again when opening the lid).

Clearly, the BIOS wasn't sending events such as power Unplugged/Replugged or LID closed/opened to the OS.

Of course, being familiar with the articles that described the bugginess of this laptop's BIOS, I wasn't surprised. I decided that it was a BIOS issue. I tried toggling all options I could find sensible to toggle in the BIOS, to see if the original behaviour was restored. It didn't, toggling options was useless.

I decided to reflash the BIOS so that its internal options would be reset to defaults. THIS FIXED ALL ISSUES.

But, but.. it wasn't that easy. This is because I already had the latest BIOS version, and the update tool refused to update the BIOS saying that I already had the "latest version or newer".
This didn't stop me.
I found a forum thread by searching for "samsung downgrade bios".
And then I did the following:

1) Open the BIOS update tool from Samsung (go to samsung.com, support, select your model, and look under Firmware). Click on 'Download' instead of 'Update'. It offered to save a file named "ITEM_20130423_1110_WIN_P14AAJ.exe". (My current BIOS version is "P14AAJ", so it is the same version).

2) Run the file "ITEM_20130423_1110_WIN_P14AAJ.exe". The program decompresses several files to "C:\Users\<myuser>\AppData\Local\Temp\__Samsung_Update" The program refuses to update the BIOS because it is the latest version, and then deletes the files.
I copy the files before closing the program. They contain the ROM and the SFlash64.exe utility, and some other files required for flashing.

3) I notice a file there, named "DebugAppLog.txt". That file is not deleted between runs. In it, it contains the log of the time I updated the BIOS the day I bought it, and most importantly, the full command line for the SFlash64.exe utility. Which is:



Bios command : SFlash64 /n /s /sa /ips /exit /file P14AAJ.rom

I try "SFlash64 -help" and see the meaning of the flags. I particularly liked "/n" which says that it clears bios internal options to factory default, which is what I need.

4) I close all the opened programs. With the task manager, I close Samsung's "Easy Settings" and all Samsung programs so that they don't interact with the BIOS while it is flashing.

5) Start a console right clicking and "Run as administrator". Go to the directory where I saved the uncompressed files and run:



SFlash64 /n /s /sa /ips /exit /file P14AAJ.rom

6) Shutdown windows. Start hitting the "F2" key until I get in the BIOS. Inside the BIOS screen, hit "F9" to load defaults. Fix options to my liking because they were all default now.

7) Start Windows. Test lid close, It works!!!!
Start Linux, Test lid close, It Works!!! Test unplug power cord:
It is detected!!! Also, when unplugging the power cord in windows
it now detects it instantly, instead of several seconds later.

PROBLEM SOLVED!

FINAL NOTES: What caused the issue? Will it happen again? I have a few guesses: 1) The bios might have gotten confused when changing states, and enabled some internal option to not inform the OS of power events, perhaps while plugging/unplugging power while in S3 at the wrong time, who knows, Or 2) Some Samsung software in Windows messed up some internal option in the BIOS (Samsung software does change bios options, for example, one can toggle "Battery Life Extension" from windows, and the option will appear respectively toggled in the BIOS screen.). I might uninstall all the Samsung software, I won't for the time being, to see if it happens again. If it happens again, I'll just reflash. Or 3) I read that these Samsung BIOSes have limited memory for variables (in Jakob Heinemann: blog), so maybe entering the BIOS screen and saving bios options too many times is what caused it, which is what one does the first days of setup, changing boot order, etc (maybe the BIOS stores a backup of changed options internally until it runs out of space, and things go wrong then, luckily, reflashing the BIOS seems to restore everything to factory).
I hope that it doesn't happen again, but I'll pay more attention to what I do, and try to remember what could have caused it.

I spent the whole saturday debugging this issue, and I'm happy that I can share the solution!
--
Juan Manuel

Hi Again!!

I found a much better workaround by reading this thread:

https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061?comments=all

The workaround consists of:

1. Turn off and unplug the laptop.
2. With a paper clip, push the button through the small hole in the back (it would be below the touchpad, in the back). Count to two.
3. Now plug the laptop, so that it can turn on.

After this, the LID close/open events are produced again. So do the AC plug/unplug events.

This is what they recommend to do to reset the "Embedded Controller" which is the motherboard component responsible of detecting LID close/open events, and plug/unplug events, and battery percentage drop/increase. Hitting that small reset button in the back has the same effect as removing the battery would have, in a laptop which has a removable battery.

This also explains why flashing the bios (any bios version), gets the computer out of the "problem state", because the Embedded Controller is reset while flashing any bios.

I also found out, after many, many tests, that the problem happens again when the laptop is suspended and no less than 16 Embedded Controller events would be produced. (% battery drop or increase is one event. Plugging or unplugging produces each two events (so you can unplug or replug 8 times at most, LID close or open is one event).

So, if I leave the laptop suspended with 100% battery, plugged to the wall, and without closing or openinng the lid, then the problem never happens.
If I never suspend the laptop, the problem never happens.

(by "problem state" I mean the state in which the laptop doesn't report LID events anymore, nor AC plug/unplug events, and this state is persistant between reboots and shutdowns).

My guess is that either some internal buffer of the Embedded Controller gets full when it cannot report events to the sleeping OS, or that Linux gets the system into a race condition trying to respond to too many events at a critical stage while the system is resuming from sleep.

If you think you got a fix, and want to try to see if it worked in preventing this issue, the quickest way to reproduce the problem is to:

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.

--
Juan Manuel