Should shutdown gracefully on low battery

[cjb]

When OHM notices low battery (18% or something?) it should execute a graceful shutdown.

We can already tell the datastore to sync over dbus, I think. What we can't do is tell the activities to sync to the datastore. Should we implement that for Update.1?

[jg]

I thinks we should only deal with this for the datastore (if that)... The interactions are likely to be complex...

[tomeu]

I think it wouldn't be exceedingly hard to make the base Activity class to listen for a signal from OHM.

If OHM kills X and/or the session bus, the datastore will flush and exit cleanly. Of course, the DS could also listen for that shutdown signal.

[gnu]

18% sounds way too high to kick off the user and force a shutdown. I can recall many times fighting with DOS laptops that tried to kick me off just as I was racing to finish something before the battery *actually* ran out.

If the laptop is idle, it should be suspending and the battery shouldn't be dropping much. (Ohm could wake up from idle when it hits 2%, and do a clean shutdown.) If the laptop isn't idle, please don't suddenly shut it down out from under the user!

One thing we'll need to have clear is what the "N%" actually measures. I thought the EC was preventing us from even seeing the top 10% and bottom 10% of the battery capacity. (At least on NiMH; maybe or maybe not on LiFePO.) The EC will force a hard shutdown at real-10% (or maybe 0% for LiFePO)? Question is whether the kernel-readable N% includes that 10% margin -- or not. I argue the kernel should not report unavailable capacity; and that Ohm therefore should not assume a 10% offset from what the kernel is reporting. (Particularly if it differs based on battery types; we want that info centralized in the EC and not spread around the EC, kernel, and ohm.)

If suspend was smart, it would do a sync() sometime before or during a long-term suspend; in case the power never comes back, the filesystem at least would be in sync.

Activities should definitely be listening to dbus for global signals -- like "Out of memory, free some up!" as well as "sync your stuff up 'cause we're suspending for a long time" and "shutting down".

[sola]

LiFePo batteries should not be deep cycled either. I wouldn`t suggest to allow any lithium go below 10% normally.

If you want really good cycle life for the XO battery then:

-NiMh should be deep cycled once in 1 or 2 months because it does have a slowly building memory effect otherwise. Not as bad as NiCd but exists still.

-Even LiXX batteries should be deep cycled sometimes in order to correct state of charge (SOC) measurement sliding resulted by keeping the latop on the charger all the time.

-Generally, there should be a battery maintenance program which executes every months and checks the battery usage logs (there should be such a thing). It decides whether the battery requires maintenance (according to the chemistry) and if so, then executes it. There should be some feedback to the user that maintenance is on.(Even if he/she plugs it in, it will not charge until the forced deep cycling is over.

That said, I have never seen a battery maintenance program on any OS yet, even though this is the way it should work. Without periodic maintenance, batteries get half or worse cycles than factory specs. (for more info see batteryuniversity.com)

[pgf]

i'm changing this from "enhancement" to "defect". there is no reason that we should be letting this system simply crash on low power.

[AlbertCahalan]

Replying to pgf:

i'm changing this from "enhancement" to "defect". there is no reason that we should be letting this system simply crash on low power.

There is a reason: you can only force the user to stop if you treat him badly, cutting him off while he is trying to get a bit more done

Also, there is absolutely nothing wrong with "crash on low power". Getting rid of the "clean shut-down" code would improve reliability and maintainability. (when the user wants to shut down the laptop, you immediately tell the EC to cut power)

The one reasonable thing to do in a low-power situation is to gently alert the user. A warning chime might be tolerable. (could mess up audio tasks though) Dimming the backlight is probably good.

[pgf]

if the user is trying to "get a bit more done" and the system crashes, that's treating them far worse than performing a clean shutdown. similarly with your concern about messing up audio tasks -- the task is going to be "messed up" regardless.

while i agree that the optimum case would be a harmless power yank, i think we can all agree that we're pretty far from having that -- it goes against the grain of every caching and buffering technique that might help performance. the filesystem and the applications both want an indication that they should do some house-cleaning -- note the recent ECO to the firmware that was required partially because of this behavior.

maybe i could agree with forcibly suspending the laptop (instead of a shutdown), as long as there's a sync beforehand (is there a sync before suspend?) warnings, of course, are a given.