After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 348201 - Incorrect remaining time when going off AC
Incorrect remaining time when going off AC
Status: RESOLVED FIXED
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.15.x
Other All
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-07-21 01:16 UTC by Pierre Ossman
Modified: 2007-09-19 05:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
g-p-m --no-daemon --verbose (79.04 KB, text/plain)
2006-07-21 11:01 UTC, Pierre Ossman
  Details
test patch (2.66 KB, patch)
2006-07-29 17:55 UTC, Richard Hughes
none Details | Review
lshal -m, unmodified hal 0.5.7 (4.00 KB, text/plain)
2006-07-30 19:07 UTC, Pierre Ossman
  Details
lshal -m, modified hal 0.5.7.1 (24.00 KB, text/plain)
2006-07-30 19:10 UTC, Pierre Ossman
  Details
hal patch to fix the issue (maybe) (676 bytes, patch)
2006-10-28 08:43 UTC, Richard Hughes
none Details | Review

Description Pierre Ossman 2006-07-21 01:16:38 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:
Comment 1 Richard Hughes 2006-07-21 07:33:06 UTC
Can you get a gnome-power-manager --no-daemon--verbose trace when this happens please. Thanks.
Comment 2 Pierre Ossman 2006-07-21 11:01:31 UTC
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.
Comment 3 Richard Hughes 2006-07-29 17:52:01 UTC
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.
Comment 4 Richard Hughes 2006-07-29 17:55:16 UTC
Created attachment 69887 [details] [review]
test patch

Also, can you try this HAL patch please.
Comment 5 Pierre Ossman 2006-07-30 19:07:42 UTC
Created attachment 69916 [details]
lshal -m, unmodified hal 0.5.7
Comment 6 Pierre Ossman 2006-07-30 19:10:13 UTC
Created attachment 69917 [details]
lshal -m, modified hal 0.5.7.1
Comment 7 Richard Hughes 2006-07-30 21:56:02 UTC
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.
Comment 8 Pierre Ossman 2006-08-04 20:08:37 UTC
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.
Comment 9 Richard Hughes 2006-08-04 20:44:31 UTC
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.
Comment 10 Richard Hughes 2006-10-18 17:02:42 UTC
Can you try cvs head now please, I'l got a "recalculating" delay when an event happens.
Comment 11 Pierre Ossman 2006-10-20 11:20:28 UTC
Head of what? Hal? I tried g-p-m and it still considers a fully charged battery to only contain 3 minutes worth.
Comment 12 Richard Hughes 2006-10-22 17:01:09 UTC
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.
Comment 13 Pierre Ossman 2006-10-22 19:08:33 UTC
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.
Comment 14 Richard Hughes 2006-10-24 17:20:57 UTC
if you do lshal -m and then pull the plug, can you post the output for the split sendond after the unplug. Thanks.
Comment 15 Pierre Ossman 2006-10-28 07:52:32 UTC
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)
Comment 16 Richard Hughes 2006-10-28 08:43:37 UTC
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.
Comment 17 Pierre Ossman 2006-10-28 09:17:47 UTC
I'll try it tonight (CEST), thanks. :)
Comment 18 Pierre Ossman 2006-10-28 21:18:44 UTC
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. :)
Comment 19 Richard Hughes 2006-10-28 21:48:51 UTC
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.
Comment 20 Scott Robinson 2007-09-19 05:17:44 UTC
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.