Hi Joey! Am 01.03.2010 21:03, schrieb Joey Hess: > Michael Biebl wrote: >> could you please monitor the sysfs value directly after the unplug and send >> me >> that log. I'd be interested if it is the kernel resp. hardware reporting >> bogus >> values. > > I looked at that and ran the acpi command also. energy_now, voltage_now and > power_now only had small fluctuations, but current_now and power_now > varied by up to 2 orders of magnitude! (I'll just show current_now; > power_now values seem to be the same.) > > On power: > > current_now: 48019000 > > Battery 0: Charging, 27%, 00:24:37 until charged > > Immediatly after power is unplugged, in the few seconds before g-p-m > forced a suspend: > > current_now: 969327000 > > Battery 0: Discharging, 27%, 00:00:29 remaining > > After a suspend/resume cycle, while still on battery: > > current_now: 4096000 > > Battery 0: Discharging, 27%, 00:54:35 remaining > > Interesting that gnome-power-manager did not panic seeing this > before, when it used hal. Does hal have a quirk mode that > avoids the problem?
Sorry that it took so long to get back to you. I had forwarded this bug upstream in the meantime, where we discussed if we should employ some heuristics which handle cases like this where current_now is ridiculuously high directly after unplug. We haven't figured out yet, if it is just buggy hardware reporting incorrect values, or if there is a bug in the kernel. That said, upstream is not particularly happy to add such a quirk mode to upower, but this seems to be a more common problem, so we need a solution for this. In the mean time, you can apply a workaround, which won't use remaining-time as indicator for when to suspend/hibernate, but the remaining percentage. For that run: gconftool-2 -s /apps/gnome-power-manager/general/use_time_for_policy -t bool false or use gconf-editor. Cheers, Michael
signature.asc
Description: OpenPGP digital signature
