Created attachment 20999 [details] dmesg output Distribution: ArchLinux Hardware Environment: HP dv6540el (BIOS vers.: F.09) Summary: Hal/DeviceKit cannot recognize AC/DC unplugging due to *not* generated ACPI event. This implies battery is always reported on-charge and, for example, gnome-power-manager does not start updating statistics as remaining charge. When AC adapter is plugged, it's correctly reported on /sys and /proc: $ cat /sys/class/power_supply/ACAD/online 1 $ cat /proc/acpi/ac_adapter/ACAD/state state: on-line $ cat /sys/firmware/acpi/interrupts/gpe17 4280 enabled On unpluggin' just ACPI battery event is generated: $ acpi_listen battery BAT0 00000080 00000001 So Hal/DeviceKit could not recognize AC adapter unplug event and do not update AC state. AC is still reported online (by Hal/DevKit) even if /sys and /proc are coherent to hardware: $ cat /sys/class/power_supply/ACAD/online 0 $ cat /proc/acpi/ac_adapter/ACAD/state state: off-line $ cat /sys/firmware/acpi/interrupts/gpe17 4365 enabled Plugging-in AC adapter again, various ACPI events are generated, among them ac_adapter ACAD one: $ acpi_listen battery BAT0 00000081 00000001 ac_adapter ACAD 00000080 00000001 battery BAT0 00000080 00000001 battery BAT0 00000080 00000001 So Hal/DeviceKit can recognize plug event, only.
no AC event when unplugging AC? please attach the acpidump output using the latest pmtools at http://www.lesswatts.org/projects/acpi/utilities.php
will you please also attach the output of lspci -vxxx? Thanks.
Created attachment 21008 [details] acpidump output (pmtools vers.:20071116)
Created attachment 21009 [details] lspci -vxxx output
(In reply to comment #1) > no AC event when unplugging AC? Yes, right. By the way running kernel with neither acpi_apci_instance=0 or =2 correct this behavior.
Method (_Q20, 0, NotSerialized) { GBAS () If (And (0x40, BATF)) { Notify (BAT0, 0x81) } If (And (0x02, BATF)) { Notify (\_PR.CPU0, 0x80) Notify (ACAD, 0x80) } Notify (BAT0, 0x80) BPOL (0x05) } From the acpidump, we can see that whether to send an AC notification or not is controlled by BATF, while the BATF is set by both MBTS and SW2S in the EC address space. So this is an firmware problem to me. In order to verify this, please try the customized DSDT attached below and see 1. if _Q20 is invoked when unplugging AC 2. if BATF=0 when invoking _Q20
Created attachment 21021 [details] customized DSDT please set CONFIG_ACPI_DEBUG and rebuild your kernel with this customized DSDT. please boot with acpi.debug_level=0x07, unplug the AC and attach the dmesg output.
Created attachment 21036 [details] dmesg output (custom DSDT, acpi.debug_level=0x07, acpi.debug_layer=0xF0) AC unplug, line 7054: Execute Method: [\_SB_.PCI0.LPCB.EC0_._Q20] (Node f7019048) [ACPI Debug] String [0x04] "BATF" [ACPI Debug] Integer 0x00000040
then this is a Firmware problem to me. In order to get the AC events upon unplugging AC, BATF needs to be set 0x42. This is true only if SW2S in EC address space is set after boot, but in this laptop, SW2S is cleared and BATF is 0x40 as a result. I'll close this bug as we can not fix/workaround it in Linux kernel. Anyway, I'll attach a customized DSDT later, which doesn't check the SW2S flag upon unplugging AC, so that you can use receive the AC unplug events.
Created attachment 21048 [details] customized DSDT: don't check SW2S upon unplugging AC BTW: you can attach the dmesg output like the previous one to verify the problem.
(In reply to comment #10) > BTW: you can attach the dmesg output like the previous one to verify the > problem. "to verify the problem", here I mean to "confirm my conclusion in comment #9".
Lastest custom DSDT works, it generates ACPI AC_adapter event on AC unplug. However same problem has been found on other HP series 6000, also equiped with different hardware.
Created attachment 21066 [details] dmesg output (new custom DSDT, acpi.debug_level=0x07) dmesg output confirms conclusion (from line 7051): Execute Method: [\_SB_.PCI0.LPCB.EC0_._Q20] (Node f7019048) [ACPI Debug] String [0x04] "SW2S" [ACPI Debug] Integer 0x00000000 [ACPI Debug] String [0x04] "BATF" [ACPI Debug] Integer 0x00000040
Does this function work on Windows? If yes, then we should figure out why Windows has set SW2S differently than Linux.
ping Matteo
>On unpluggin' just ACPI battery event is generated: >$ acpi_listen >battery BAT0 00000080 00000001 I thought this could be workaround in HAL. When battery info is received, userspace can check battery status. If battery is discharging, then AC adaptor is offlined.
(In reply to comment #15) > ping Matteo Sorry for delay, but I wasn't dual-booting my machine, so it took me some extra time. (In reply to comment #14) > Does this function work on Windows? Apparently, by observing AC status icon on SysTray, all work as expected on AC unplug. However is there a better way to analyze that? An event viewer, a ACPI logger, or something else, obviously for Windows. Is there? (In reply to comment #16) > >battery BAT0 00000080 00000001 > I thought this could be workaround in HAL. When battery info is received, > userspace can check battery status. If battery is discharging, then AC > adaptor > is offlined. It's the exact same thing I've done in bash. Through ACPId I gather the event, then it checks on /sys/... real AC state and finally apply right policies for backlight, cpu governor, wi-fi power, etc. But, as you said, it's a workaround.
By the way, using custom DSDT, I noticed a strange DeviceKit/HAL behaviour (that made improvements void). On AC unplug, AC event is generated, but also additional BATT events: battery BAT0 00000081 00000001 ac_adapter ACAD 00000080 00000000 battery BAT0 00000080 00000001 Then, a manual check reports the battery in discharging status: $ cat /sys/class/power_supply/BAT0/status Discharging But DeviceKit/Hal report it as "unknown": $ devkit-power --monitor-detail device changed: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0 [...] state: unknown (I'm going to investigate how DeviceKit works...) I wonder if multiple BATT events (0x81 0x01 - 0x80 0x01) could be the disturbance. What do you think about? Are these BAT events a normal thing?
(In reply to comment #18) > I wonder if multiple BATT events (0x81 0x01 - 0x80 0x01) could be the > disturbance. well, there ARE always multiple battery events when unplugging AC. please make sure the problem still happens without the customized DSDT. > What do you think about? Are these BAT events a normal thing? yes. Because the battery sysfs I/F is reporting the correct state, I think this is a user space problem, maybe the DeviceKit you mentioned above. (In reply to comment #17) > (In reply to comment #14) > > Does this function work on Windows? > > Apparently, by observing AC status icon on SysTray, > all work as expected on AC unplug. > this doesn't mean anything, because we can also make Linux always reporting the correct state, via the suggestion in comment #16. > However is there a better way to analyze that? > An event viewer, a ACPI logger, or something else, obviously for Windows. > Is there? > I'm afraid no. we are not able to do that in Windows. > (In reply to comment #16) > > >battery BAT0 00000080 00000001 > > I thought this could be workaround in HAL. When battery info is received, > > userspace can check battery status. If battery is discharging, then AC > adaptor > > is offlined. > > It's the exact same thing I've done in bash. > > Through ACPId I gather the event, then it checks on /sys/... real AC state > and finally apply right policies for backlight, cpu governor, wi-fi power, > etc. > > But, as you said, it's a workaround. sounds that this is all we can do for now. :)
we could not verify if it works on windows or not. because this could be workaround by userspace, either in Linux or Windows.