[HP Folio 13-1050ca Notebook PC] Power indicator fails to recognise unplug

Bug #994745 reported by Jack Lonsdale on 2012-05-04
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Fix Released
Won't Fix
linux (Debian)
Fix Released
linux (Ubuntu)
upower (Ubuntu)

Bug Description

Upon unplugging the power on HP Folio 13 running Precise the power indicator fails to recognise the unplug.
The charging laptop symbol remains. Power-statistics also becomes unresponsive/empty of data.

Powertop recognises the unplug, but Jupiter which I have installed does not.

If I suspend and resume or restart, the fact that I am on battery power is once again recognised.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: indicator-power 2.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-24.38-generic 3.2.16
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
Date: Fri May 4 11:00:11 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120301)
 PATH=(custom, user)
SourcePackage: indicator-power
UpgradeStatus: No upgrade log present (probably fresh install)

On my new Sony VAIO laptop UPower is not sending line_power_AC events. When the AC power is disconnected, I get events (monitored using upower -m) for the battery, but not for line_power_ac. This results in the system thinking it is still plugged in.

I tested on my other Linux system, and disconnecting/reconnecting the AC power supply results in line_power_ac events.

Interestingly, on_ac_power (from pm-utils) correctly reports the AC power status for both connected and disconnected states.

It would appear as though upowerd isn't updating the line AC power's online status, ever. Here's the (edited) output of upower -d:

Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path: /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC
  power supply: yes
  updated: Fri Jan 27 12:31:41 2012 (4590 seconds ago)
  has history: no
  has statistics: no
    online: yes

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
  vendor: Sony Corp.
  model: VGP-BPS26
  serial: 59
  power supply: yes
  updated: Fri Jan 27 13:42:36 2012 (335 seconds ago)

The "updated" value for line_power_AC is equal to my system's uptime; it hasn't been updated since it was first checked. The 335 seconds since the battery update roughly corresponds to the last time I unplugged the AC power supply.

Upon further investigation, it would appear that the kernel is not producing uevents for the AC power device, though the kernel is producing events for the battery. This is a kernel bug, it would appear.

However, I wonder if it would be possible to have upowerd explicitly check the line_power devices when a battery state change occurs, since the sysfs interface does correctly report the connected status of the AC adapter.

The end result of all this is that upowerd gets confused and never sets the "on battery" state.

However, if the system is booted from battery and AC is plugged in after upower is running, the system gets the state right. What's also interesting is that, if the system is booted from battery, the kernel sends backlight events, and it doesn't if the system is booted with AC connected. In either case (plugged or unplugged boot) the kernel doesn't appear to be sending AC supply events.

I have HP Pavilion dv6-6179er and it seems that I'm affected by this bug too.
However, I found a workaround:
I rebuilt kernel with ACPI_PROCFS_POWER=y ("Deprecated power /proc/acpi directories") and noticed that if I do "cat /proc/acpi/ac_adapter/AC/state" then state of the adapter becomes correct in kde, upower's output, etc.

I added a file to /etc/acpi/events/ with following contents:
action=cat /proc/acpi/ac_adapter/AC/state > /dev/null

After restarting acpid everything works. The only problem is that ACPI_PROCFS_POWER is deprecated. I hope this bug will be fixed before
the option will be removed.

Jack Lonsdale (jacklonsdale) wrote :
Charles Kerr (charlesk) wrote :

Jack, indicator-power gets its information from upower over DBus. Could you try unplugging while running "upower --monitor-detail" in a terminal and attach its output?

Changed in indicator-power:
status: New → Incomplete
Jack Lonsdale (jacklonsdale) wrote :

Upon unplugging only get:

Monitoring activity from the power daemon. Press Ctrl+C to cancel.

Left for a few minutes to see if it was slow but remained like this.

Launchpad Janitor (janitor) wrote :

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

Changed in indicator-power (Ubuntu):
status: New → Confirmed

acpi_listen does not recognize changes in power supply either, however changes are registered immediately in /sys/class/power_supply/ACAD/online.

12.04, 3.2.0-26-generic

On my Sony Vaio VPCS11V9E, i'm affected of this bug too. As mentioned before i can get the status of the ac-adapter correctly from sysfs by reading
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC/online or

The uevent-file looks good, so i don't think the kernel is missing to export this events. Although upower -d shows me the following:

Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC
  power supply: yes
  updated: Thu Feb 7 09:45:39 2013 (723 seconds ago)
  has history: no
  has statistics: no
    online: yes

The status isn't updated ever so the state of the ac-adapter is always the state it had on boot.
upower -m shows events for the Battery (charging/discharging) but not for the ac-adapter.
The workaround mentioned by Alexander Mezin doesn't work for me. /proc/acpi/ac_adapter/AC/state contains the correct state, but reading the file does not affect upower in any way.

I'm on ArchLinux using upower 0.9.19 with Kernel 3.7.6. If you need more information, just tell me.

Stefan Nagy (stefan-nagy) wrote :

I'm affected by this bug on Debian Wheezy and already reported it against UPower. I think this bug report should also be reassigned to Upower, since "indicator-power gets its information from upower over DBus" as Charles Kerr wrote (comment #2).

affects: indicator-power (Ubuntu) → upower (Ubuntu)
affects: indicator-power → upower
Changed in upower:
importance: Undecided → Unknown
status: Incomplete → Unknown

Multiple users of the HP Folio 13 ultrabook are affected by this bug on Ubuntu, I'm seeing it on Debian Wheezy. I'm adding the URLs to the downstream bug reports.

Changed in upower:
importance: Unknown → High
status: Unknown → Confirmed
Changed in upower (Debian):
status: Unknown → Confirmed

At least in my case the kernel doesn't produce any uevents for the battery or the ac adapter, so I filed a bug report against the kernel.

UPower seems to force an update of the battery status every 30 seconds, so the charging level reported by GNOME battery status applet corresponds to the one reported in /sys/class/power_supply/BAT1/uevent (POWER_SUPPLY_CAPACITY). 'upowerd --verbose' tells me: 'No updates on supply /org/freedesktop/UPower/devices/battery_BAT1 for 30 seconds; forcing update'.

However, UPower doesn't force an update of the ac adapter status (un/plugged), so that's why my notebook wouldn't go into hibernation when the time defined in /org/gnome/settings-daemon/plugins/power/time-action is reached.

Since UPower seems to expect the kernel to send uevents for the battery and the ac adapter, I filed a report against the kernel: https://bugzilla.kernel.org/show_bug.cgi?id=54621.

As I understand it all that remains here is the reqeust that UPower should force an update of the line_power device in case the kernel fails to send an uevent. If if this is correct it would make sense to change the title.

affects: upower (Debian) → linux (Debian)

UPower expects the the kernel to produce uevents for battery and ac adapter status updates but it won't do it on this device. While UPower forces an update for the battery every 30 seconds (UPowerd tells me: 'No updates on supply
/org/freedesktop/UPower/devices/battery_BAT1 for 30 seconds; forcing update') it doesn't force an update for the ac adapter.

This seems to be the reason why the charging level reported by the GNOME battery status applet corresponds to the reported value in /sys/class/power_supply/BAT1/uevent (POWER_SUPPLY_CAPACITY) but at the same time the notebook will not be sent into hibernation when battery status is critical – UPower thinks the notebook is still on ac power.

Since I don't see any power related uevents with 'udevadm monitor' I guess this is a kernel bug.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Incomplete

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

Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux:
status: Incomplete → Fix Released
Changed in linux:
status: Fix Released → Confirmed
Changed in linux:
status: Confirmed → Incomplete
Changed in linux:
status: Incomplete → In Progress

I don't have the power indicator problem on my HP Folio 13 with Ubuntu 13.04, but I have the problem of the two special keys for brightness +/- as well as the wireless adapter toggle not working.

It appears the patch provided in https://bugzilla.kernel.org/show_bug.cgi?id=54621 fixes all of those problems.

Is there any chance the patch will be backported to the Raring kernel in the near future?

Appending "acpi_osi=" to GRUB_CMDLINE_LINUX_DEFAULT in etc/default/grub fixed both the problem of the two special keys for brightness +/- and the wireless adapter toggle not working.

sudo gedit etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi="

sudo update-grub
sudo reboot

Stefan Nagy (stefan-nagy) wrote :

Hi Marco,

thanks for this – this is really a great workaround for as long as the fix isn't included in the kernel.

When I use this boot parameter (on a Folio 13-2000) UPower recognizes un/plugging of the ac adapter and the special keys (brightness +/- and wireless adapter toggle) are working.

Thanks again!

Jack Lonsdale (jacklonsdale) wrote :

The acpi_osi= workaround does not seem to work for me, but I can't work out why it should not? (I have Folio 13-1050)

Stefan Nagy (stefan-nagy) wrote :

@ Jack: Read "How to Add a Kernel Boot Parameter" (https://wiki.ubuntu.com/Kernel/KernelBootParameters) and make sure you added the boot parameter correctly.

As mentioned here (https://www.kernel.org/doc/Documentation/kernel-parameters.txt) the kernel boot parameter acpi_osi is ment to "Modify list of supported OS interface strings"; with acpi_osi= we disable all strings. Instead of disabling all strings I tried to remove single strings from the list and found out that acpi_osi="!Windows 2009" solves the problem for me.

As I understand it, the Linux kernel tells BIOS that its ACPI-implementation is compatible with the one of Windows 7, but this doesn't seem to be completely true (at least as long as the available patch isn't applied).

I don't know why this workaround shouldn't work for you (while it works for other submodels). BTW, does the patch provided in the upstream bug report solve the problem for you?

Jack Lonsdale (jacklonsdale) wrote :

@Stefan: Checked and it is added correctly, and tried the windows 2009 which also had no result.

I have not tried the patch in the upstream as I am not comfortable compiling and running a custom kernel

Stefan Nagy (stefan-nagy) wrote :

@ Jack: Seems like you'll have to wait for the fix to arrive in the Ubuntu kernel – I hope it will fix the problem for you too…

Changed in linux:
status: In Progress → Fix Released
Changed in linux (Debian):
status: Confirmed → Fix Released

Jack Lonsdale, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, 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 <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. 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:

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

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:

If the mainline kernel does not fix this bug, please add the following tags:

As well, please remove the tag:

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:

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: needs-kernel-logs needs-upstream-testing regression-potential
summary: - Power indicator fails to recognise unplug
+ [HP Folio 13-1050ca Notebook PC] Power indicator fails to recognise
+ unplug
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Jack Lonsdale (jacklonsdale) wrote :

I recently updated my BIOS which removed this issue. Is it neccessary to try the latest development release still? I use my laptop for work and so testing development builds and mainline kernels concerns me a little..

Jack Lonsdale, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/upower/+bug/994745/comments/25 regarding this being fixed with a BIOS update. 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.

Changed in linux (Ubuntu):
status: Incomplete → Invalid
Changed in upower (Ubuntu):
status: Confirmed → Invalid

Looks like the kernel bug got fixed, so closing this report.

Changed in upower:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.