unit suspends when AC adapter unplugged

[Bill Filler]

The unit suspends internittently when AC adapter is unplugged even though battery is fully charged. This issue has been reported in Ubuntu:
https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/139291

Sylvania is seeing this with there production units and they want a fix.

[Bill Filler (bfiller)]

attached is output from gnome-power-bugreport.sh

[Bill Filler (bfiller)]

attached is output of lshal -m command when doing the following:
1)initial state was unplugged
2)then plugged in battery
3)then unplugged battery (system suspended)
4)then resumed

[Bill Filler (bfiller)]

more debug output from hal-find-by-capability:
unr@ubuntu:~$ hal-find-by-capability --capability "battery"
/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0
unr@ubuntu:~$ hal-find-by-capability --capability "battery" | xargs -n 1 hal-device
udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0'
  battery.vendor = ' AMtek' (string)
  battery.reporting.current = 3197 (0xc7d) (int)
  battery.voltage.design = 7400 (0x1ce8) (int)
  battery.reporting.last_full = 4415 (0x113f) (int)
  linux.sysfs_path = '/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0' (string)
  battery.voltage.unit = 'mV' (string)
  battery.charge_level.current = 23657 (0x5c69) (int)
  info.subsystem = 'power_supply' (string)
  info.parent = '/org/freedesktop/Hal/devices/computer' (string)
  info.product = 'LC89 Battery 0' (string)
  battery.reporting.design = 4400 (0x1130) (int)
  battery.charge_level.last_full = 32671 (0x7f9f) (int)
  battery.reporting.unit = 'mAh' (string)
  battery.charge_level.design = 32560 (0x7f30) (int)
  info.udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0' (string)
  battery.present = true (bool)
  battery.charge_level.rate = 11566 (0x2d2e) (int)
  linux.hotplug_type = 2 (0x2) (int)
  info.category = 'battery' (string)
  battery.voltage.current = 7632 (0x1dd0) (int)
  battery.charge_level.percentage = 72 (0x48) (int)
  linux.subsystem = 'power_supply' (string)
  battery.type = 'primary' (string)
  battery.reporting.rate = 1563 (0x61b) (int)
  info.capabilities = { 'battery' } (string list)
  battery.remaining_time = 7363 (0x1cc3) (int)
  battery.reporting.technology = 'Li-ion' (string)
  battery.is_rechargeable = true (bool)
  battery.technology = 'lithium-ion' (string)
  battery.rechargeable.is_charging = false (bool)
  battery.model = 'LC89 Battery 0' (string)
  battery.rechargeable.is_discharging = true (bool)

unr@ubuntu:~$

[Bill Filler (bfiller)]

here is dbus-monitor information :
1)initial state was unplugged
2)then plugged in battery
3)then unplugged battery (system suspended)
4)then resumed

unr@ubuntu:~$ dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'"
signal sender=org.freedesktop.DBus -> dest=:1.31 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.31"

signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=OnBatteryChanged
   boolean false
signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=PowerSaveStatusChanged
   boolean false
signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=OnBatteryChanged
   boolean true
signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=PowerSaveStatusChanged
   boolean true
signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=OnBatteryChanged
   boolean false
signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=PowerSaveStatusChanged
   boolean false
signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=OnBatteryChanged
   boolean true
signal sender=:1.9 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=PowerSaveStatusChanged
   boolean true

unr@ubuntu:~$

[Bill Filler (bfiller)]

gpm gconf key dump attached

[Torsten Spindler (tspindler)]

Our current hypothesis is that something in gnome-power-manager is borked and causes the system to suspend upon battery power, no matter how much energy the battery has left.

What happens in the following scenario:

1) System supends when AC is disconnected
2) reconnect AC
3) kill gnome-power-manager (probably ctrl-alt-backspace)
4) disconnect AC

[Bill Filler (bfiller)]

here are the dbus-monitor logs on both session and system bus
1)unit unplugged
2)unit suspends
3)unit manually resumed

[Bill Filler (bfiller)]

I changed the power prefs to do nothing on lid close (instead of suspend) and this problem goes away. Somehow the ac unplugged is getting interpreted as a lid close event perhaps.

[Bill Filler (bfiller)]

after reverting these settings back to "suspend" on lid close, the problem does not occur. Bummer! I'll have to dig deeper into g-p-m.

Related bug upstream bug to note: http://bugzilla.gnome.org/show_bug.cgi?id=496818

[Bill Filler (bfiller)]

wrong about last comment, after waiting a few minutes after reverting the lid close settings to "suspend", the unit suspends again after unplugging the ac. I tried Torsten's suggestions:

1) System supends when AC is disconnected
2) reconnect AC
3) kill gnome-power-manager (probably ctrl-alt-backspace)
4) disconnect AC

Unit does not suspend when g-p-m is not running. So the problem appears to be a g-p-m problem, or else it suspend when that was not running as well.

[Bill Filler (bfiller)]

Thanks to james-w who noticed this in the code in src/gpm-manager.c

 /* We do the lid close on battery action if the ac_adapter is removed
    when the laptop is closed and on battery. Fixes #331655 */
 gpm_conf_get_bool (manager->priv->conf, GPM_CONF_ACTIONS_SLEEP_WHEN_CLOSED, &event_when_closed);

 /* We keep track of the lid state so we can do the
    lid close on battery action if the ac_adapter is removed when the laptop
    is closed. Fixes #331655 */
 if (event_when_closed == TRUE &&
     on_ac == FALSE &&
     gpm_button_is_lid_closed (manager->priv->button)) {
  manager_policy_do (manager, GPM_CONF_BUTTON_LID_BATT,
       _("The lid has been closed, and the ac adapter "
         "removed (and gconf is okay)."));
 }

Could be the culprit here..

[James Westby (james-w)]

hal-find-by-property --key button.type --string lid | xargs -n 1 hal-device

that should give you information about the state of the lid as seen by hal.

I would be interested if you got the machine to a stable state then ran

  killall gnome-power-manager
  gnome-power-manager --verbose --no-daemon 2>&1 | tee gpm.debug.log.txt

and then tried to reproduce the bug, attaching the gpm.debug.log.txt file to the
bug after resuming when you get it to suspend.

If the problem doesn't seem to occur after restarting g-p-m then I wonder if opening
and closing the lid a few times slowly before unplugging ac will cause it to trigger.

I would check the state of the lid as seen by hal as soon after startup, and then
perhaps add a monitor on its state to see if it changes without the lid being closed.

Thanks,

James

[Torsten Spindler (tspindler)]

The problem seems to lie deeper. Try the following:

$ cat /proc/acpi/button/lid/LID0/state
state: open

Should read open.
Close the lid.
System suspends.
Open the lid, press power button.
System resumes.

$ cat /proc/acpi/button/lid/LID0/state
state: closed

I guess the problem is that the lid is opened while in suspend and hence the state becomes corrupt.

[Torsten Spindler (tspindler)]

A hotfix would be to change the gconf key '/apps/gnome-power-manager/general/lid_battery nothing'. Question is how such an update can be distributed to the Sylvania units, as they have no special configuration file. There is a /usr/share/gconf/defaults/40_sylvania file, but it is unpackaged.

[James Westby (james-w)]

On Fri, 2008-09-26 at 22:35 +0000, Torsten Spindler wrote:
> A hotfix would be to change the gconf key '/apps/gnome-power-
> manager/general/lid_battery nothing'. Question is how such an update can
> be distributed to the Sylvania units, as they have no special
> configuration file. There is a /usr/share/gconf/defaults/40_sylvania
> file, but it is unpackaged.
>

I'd talk to seb128 about the best way to do this.

Thanks,

James

[Torsten Spindler (tspindler)]

I believe this problem affects all our deals, so it report it on UNR as well.

[Bill Filler (bfiller)]

Good find Torsten and James. Re: the gconf key, what effect will "/apps/gnome-power-
> manager/general/lid_battery nothing" have? Will the system still suspend like we want it to on lid-close?

Couple other thoughts:
- I believe there is a bios setting to wake on lid open (can't remeber exact setting, but I noticed it the other day). Should this be the default? It wouldn't help us for the units in the field, but going forward might be nice.

- Might be better to actually fix/patch the g-p-m code that is incorrectly tracking the lid state. Or is it acpi that is not reporting it correctly? The real question is how does /proc/acpi/button/lid/LID0/state get set, and why is it not correctly set to open in the scenario Torsten describes above.

[James Westby (james-w)]

On Sat, 2008-09-27 at 01:00 +0000, Bill Filler wrote:
> Good find Torsten and James. Re: the gconf key, what effect will "/apps/gnome-power-
> > manager/general/lid_battery nothing" have? Will the system still suspend like we want it to on lid-close?

No, I believe it will disable that too.

> - Might be better to actually fix/patch the g-p-m code that is
> incorrectly tracking the lid state. Or is it acpi that is not reporting
> it correctly? The real question is how does
> /proc/acpi/button/lid/LID0/state get set, and why is it not correctly
> set to open in the scenario Torsten describes above.

I doubt it is g-p-m. It is hal, or probably lower, acpi would be my
guess as you suggest. I believe the fact it is not set correctly will
actually be a kernel issue, though it may be something to do with the
hardware or bios that means the kernel isn't setting the value
correctly.

Thanks,

James

[Torsten Spindler (tspindler)]

Discovered that it works fine on other systems. This might indicate a problem with the BIOS in the Sylvania unit.

[Torsten Spindler (tspindler)]

My current hypothesis is that the lid close or open state is not reported correctly by the BIOS.

The following tests on the Sylvania and other units may help to isolate this:

1) Start system to single user/recovery mode
2) cat /proc/acpi/button/lid/LID0/state
Expected result: open
3) sleep 3; cat /proc/acpi/button/lid/LID0/state (close lid)
Expected result: closed
4) wait for 5 seconds, open lid; cat /proc/acpi/button/lid/LID0/state
Expected result: open

[Bill Filler (bfiller)]

This is most definitely a BIOS issue. The lid open event is never being sent by the bios. The steps are very reproducible:

1) reboot unit
2) cat /proc/acpi/button/lid/LID0/state
result = open
3) close the lid, the unit suspends
4) open the lid, nothing happens
5) press power button to resume
6) cat /proc/acpi/button/lid/LID0/state
expected results = open
real result = closed
This is the problem. Now when ac is unplugged, g-p-m suspends because it thinks the lid is closed.
7) pull A/C cord
expected result = screen brigthness change
real result = unit suspends

The other side effect of this bug is unit won't suspend anymore when you close the lid (because it think's it's already closed). Do the following to verify:
- Follow steps 1-6 from above
- Close lid:
expected result = suspend
real result = unit stays running

I don't know how we can work around this problem without a bios fix. I guess we could try to disable suspend on lid close by default, but that causes problems of it's own. User expects a suspend on lid close and if it doesn't, the battery will run out. Thoughts?

[chriss999 (chriss)]

Bill,
Can you give me a quick call. I would just like to better understand this
issue and our options. I won't take more than 10 minutes.

Thanks,
Chris Stefanescu

Levin Consulting
Phone: [phone] ext. 129
Mobile: [phone]

On Mon, Sep 29, 2008 at 11:52 AM, Bill Filler <email address hidden>wrote:

> This is most definitely a BIOS issue. The lid open event is never being
> sent by the bios. The steps are very reproducible:
>
> 1) reboot unit
> 2) cat /proc/acpi/button/lid/LID0/state
> result = open
> 3) close the lid, the unit suspends
> 4) open the lid, nothing happens
> 5) press power button to resume
> 6) cat /proc/acpi/button/lid/LID0/state
> expected results = open
> real result = closed
> This is the problem. Now when ac is unplugged, g-p-m suspends because it
> thinks the lid is closed.
> 7) pull A/C cord
> expected result = screen brigthness change
> real result = unit suspends
>
> The other side effect of this bug is unit won't suspend anymore when you
> close the lid (because it think's it's already closed). Do the following to
> verify:
> - Follow steps 1-6 from above
> - Close lid:
> expected result = suspend
> real result = unit stays running
>
> I don't know how we can work around this problem without a bios fix. I
> guess we could try to disable suspend on lid close by default, but that
> causes problems of it's own. User expects a suspend on lid close and if
> it doesn't, the battery will run out. Thoughts?
>
> --
> unit suspends when AC adapter unplugged
> https://bugs.launchpad.net/bugs/274938
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[David Chen (david.chen)]

Latest BIOS to fix lid status issue.

[Jouston Huang (jouston-huang)]

Seems like new BIOS fixed this issue.

[Jouston Huang (jouston-huang)]

    * LC89R018_SVN.zip (891.5 KiB, application/zip)
Still can not resume by open lid. But lid status is correct after use power button to resume.

[Jouston Huang (jouston-huang)]

Update EC code

[David Chen (david.chen)]

According to Crano,
"Open lid to resume system" feature was removed because of bug report from their DQA.

New EC fix following items:

1. Battery charging and status
2. BIOS recovery - CRISIS function
3. BIOS take control of Fn+F2

[Bill Filler (bfiller)]

Guys,
I have two questions about rolling out these fixes:
1) What is the plan for getting the new bios and EC code on Sylvania units that have not yet shipped?
2) How do existing users upgrade?

Bill

[Crano (crano-tan)]

We have provided Sylvania those fixes and we're waiting for the confirmation. Once
Sylvania confirm, we will initiate ECR to tell factory to use new fixes for manufacture.
For those who have bought devices, Sylvania can put fixes on their web site and let
users download the fixes. Update tools are also included in fixes.