GNOME Bugzilla – Bug 348201
Incorrect remaining time when going off AC
Last modified: 2007-09-19 05:17:44 UTC
Please describe the problem: When I yank the AC cable, it takes some time for a correct time estimate to stabilise. Unfortunately, g-p-m now and then miscalculates the time so badly that it decides to go to sleep. Very annoying when you have an almost full battery and just want to pick up your laptop and move a bit. Steps to reproduce: Actual results: Expected results: Does this happen every time? Miscalculation always happens. Incorrect suspend only now and then. Gets more likely the less charge you have. Other information:
Can you get a gnome-power-manager --no-daemon--verbose trace when this happens please. Thanks.
Created attachment 69318 [details] g-p-m --no-daemon --verbose Included. It starts off on battery. Then AC is hooked up and I wait for a bit for the rate to stabilise. Then I yank it again, upon which it goes to hibernation. It also seems to think the battery went missing when I plugged in AC. This is also something that happens now and then. If I restart g-p-m, it usually realises that the battery is actually there.
Sorry to trouble you yet again. Can you please start lshal -m, and then jank the ac, and then attach the output after a couple of minutes. Thanks. R.
Created attachment 69887 [details] [review] test patch Also, can you try this HAL patch please.
Created attachment 69916 [details] lshal -m, unmodified hal 0.5.7
Created attachment 69917 [details] lshal -m, modified hal 0.5.7.1
Committed to HEAD: 2006-07-30 Richard Hughes <richard@hughsie.com> * src/gpm-manager.c: Reset the action timer after an ac_adapter event has been recieved. This should fix #348201 Can you try with todays cvs again please. Thanks.
I don't know what the desired effect was, but what happens know is that when you yank AC it still miscalculates, but it doesn't decide to hibernate.
Yes, thats what I've done. I'm letting the time settle down before we apply policy. I'll work on a proper patch when I have some time this week.
Can you try cvs head now please, I'l got a "recalculating" delay when an event happens.
Head of what? Hal? I tried g-p-m and it still considers a fully charged battery to only contain 3 minutes worth.
HEAD of gnome-power-manager. 2006-10-11 Richard Hughes <richard@hughsie.com> * src/gpm-manager.c: * src/gpm-power.c: * src/gpm-power.h: Add GpmRefcount functionality so that the data is tainted for a few seconds after a power event. This means that we should not be shutting down or warning after just pulling the plug or starting up and waiting for HAL to update the battery charge values. This should fix #350374.
So what is the next step? Is it hal, acpi or g-p-m that is calculating these values? It seems like something needs to throw away some history on an AC event, but isn't.
if you do lshal -m and then pull the plug, can you post the output for the split sendond after the unplug. Thanks.
These lines show up the instant I yank the cable: acpi_C11F property battery.remaining_time = 160 (0xa0) (new) acpi_C11F property battery.charge_level.rate = 969918 (0xeccbe) acpi_C11F property battery.reporting.rate = 65535 (0xffff) acpi_C11F property battery.rechargeable.is_discharging = true acpi_C134 property ac_adapter.present = false Then these after a few more seconds: acpi_C11F property battery.charge_level.percentage = 99 (0x63) acpi_C11F property battery.remaining_time = 8139 (0x1fcb) acpi_C11F property battery.charge_level.rate = 19121 (0x4ab1) acpi_C11F property battery.charge_level.current = 43230 (0xa8de) acpi_C11F property battery.voltage.current = 16320 (0x3fc0) acpi_C11F property battery.reporting.rate = 1292 (0x50c) acpi_C11F property battery.reporting.current = 2921 (0xb69)
Created attachment 75557 [details] [review] hal patch to fix the issue (maybe) (In reply to comment #15) > acpi_C11F property battery.reporting.rate = 65535 (0xffff) That's the bug. 65535 or "Ones" as ACPI likes to call it, means that your BIOS doesn't know the value and sends this special value. HAL interprets this as 65A, and understandably, the time remaining goes down fast as you've only got 2921 mAh left in the battery. Can you try the attached HAL patch and see if it fixes things please. Thanks. Richard.
I'll try it tonight (CEST), thanks. :)
With patch: acpi_C11F property battery.reporting.rate = 65535 (0xffff) acpi_C11F property battery.rechargeable.is_discharging = true acpi_C134 property ac_adapter.present = false acpi_C11F property battery.charge_level.percentage = 99 (0x63) acpi_C11F property battery.remaining_time = 7865 (0x1eb9) (new) acpi_C11F property battery.charge_level.rate = 19758 (0x4d2e) acpi_C11F property battery.charge_level.current = 43171 (0xa8a3) acpi_C11F property battery.voltage.current = 16326 (0x3fc6) acpi_C11F property battery.reporting.rate = 1335 (0x537) acpi_C11F property battery.reporting.current = 2917 (0xb65) (The extra line breaks after the immediate output) Good work. :)
Brilliant, thanks for testing that so quick. I've emailed the patch to the HAL m/l and I'll hopefully commit the fix to HEAD tonight. Thanks for reporting this bug. Richard.
Now that this is fixed upstream in HAL, can the patch in gpm-manager.c be removed? That way, people can unplug and immediately close their laptop into suspend without the policy timeout causing to never suspend.