false battery alarm with realtime app running (jackd)

[Thomas Orgis]

Binary package hint: gnome-power-manager

When I have the JACK daemon running with realtime priority on this MSI Wind U100 laptop and pull out the wall power, the system tells me that the battery is low and enters hibernation. The battery is full, though.
If JACK is not active, nothing happens (just the battery symbol goes gray, which is irritating, but intended, I guess).

This forced hibernation is particulary annoying as JACK really does not like going to sleep; it cannot be killed by an ordinary user after resume (meaning: stop it via the button in qjackctl); pkill -9 jackd is needed. But that's another bug in the JACK audio server that one could live with, wouldn't the system -- and I suspect it's called gnome-power-manager here -- force a suspend to disk.

I'll check again if it's really just an issue when JACK has realtime priority, after posting this initial report (don't wanna loose it as collateral damage). Even if it is, I suspect some nasty race condition that could occur any time, but is helped by the scheduling schism introduced by JACK.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: gnome-power-manager 2.32.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
Architecture: i386
Date: Sun Oct 24 09:43:17 2010
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GnomeSessionSuspendInhibited: No
MachineType: MICRO-STAR INTERNATIONAL CO., LTD U90/U100
ProcCmdLine: root=UUID=02bb04e6-69d6-4bd4-af6f-cf507b0a0d2d ro quiet splash
ProcEnviron:
 LANG=de_DE.utf8
 SHELL=/bin/bash
SourcePackage: gnome-power-manager
dmi.bios.date: 12/01/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.3
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: U90/U100
dmi.board.vendor: MICRO-STAR INTERNATIONAL CO., LTD
dmi.board.version: Ver.001
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 10
dmi.chassis.vendor: MICRO-STAR INTERNATIONAL CO., LTD
dmi.chassis.version: Ver.001
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.3:bd12/01/2009:svnMICRO-STARINTERNATIONALCO.,LTD:pnU90/U100:pvrVer.001:rvnMICRO-STARINTERNATIONALCO.,LTD:rnU90/U100:rvrVer.001:cvnMICRO-STARINTERNATIONALCO.,LTD:ct10:cvrVer.001:
dmi.product.name: U90/U100
dmi.product.version: Ver.001
dmi.sys.vendor: MICRO-STAR INTERNATIONAL CO., LTD

[Thomas Orgis (thomas-forum)]

OK, scrap the thing about JACK. It must have been luck before, but now I was able to get the forced hibernation without jackd running at all. The rather infurinating thing is that I get dialog that tells about the fact and offers "OK" and "Cancel" buttons... which have no effect on the action being taken. It might be nice if "Cancel" being pressed withing some time frame would cancel the hibernation process. I even triggered multiple hibernations in a row (unplug, plug, unplug). Causing the laptop to go to sleep again right after waking up.

Anyhow: When unplugging from wall power, I get this notification blended onto the desktop about battery state ... and it tells me about 0:02 of battery runtime, 99% .. which somewhat contradicts the information when clicking on the battery applet, there I get 99%, OK, but also the much more sensible estimated runtime of 1:59 or so.

Still, this seems to be a timing issue, perhaps the ACPI information doesn't change atomically, or there is just an error in the runtime calculation using an outdated value of whatnot. I suspect, that this might be worked around by waiting some seconds and then recomputing the remaining runtime -- and only triggering the emergency if the situation is confirmed.

I do wonder though, if nobody else can reproduce this. Is the MSI Wind U100 BIOS just broken? I'm remined of the strange issues with the webcam and USB, or the Bluetooth/WLAN switch not working correctly by chance (gladly, it works in the Maverick install, as opposed to the live system from USB).

[Thomas Orgis (thomas-forum)]

Oh, and I see this issue as rather more serious on observing that I cannot turn off this behaviour. I can only choose between shutdown/standby/hibernate. Nothing like "nothing" or "inform/ask user". Especially since this is not my machine ... so I have to instruct the user to only unplug the wall power when the machine is not running.

[Thomas Orgis (thomas-forum)]

Can't anyone shed some light on this? Isn't there a way to configure this power management frenzy? Seems like I'll have to pull Linux off my peer's machines, since it just behaves badly -- even if it's the machines behaving badly, but this does not count as long as they work in the preinstalled Windows. I don't want to insult people, but I am somewhat loosing my faith in non-geek Linux here.

[Thomas Orgis (thomas-forum)]

This seems to be a long-known issue in fedora: https://bugzilla.redhat.com/show_bug.cgi?id=509190

But also there, no solution for years. Would be interesting to know why this long-standing problem just started to appear in the recent ubuntu update.

[Thomas Orgis (thomas-forum)]

OK... I've seen those now: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/531190
and the actual https://bugs.freedesktop.org/show_bug.cgi?id=27399

Some how I have to agree with https://bugs.launchpad.net/ubuntu/+source/upower/+bug/531190/comments/55 ... we do a lot of noise on the ubuntu tracker without much information reaching the people who can actually do something about the issue.

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the stable release - Oneiric Ocelot. It would help us greatly if you could test with it so we can work on getting it fixed. You can find out more about it at http://www.ubuntu.com/download . Thanks again and we appreciate your help.