To be precise, it's not BNF ceasing t work per se, but bq27x00_battery kernel module (courtesy of Pali) ceasing to give proper info for one important parameter, making calculations fail. Mentalist suggested work around to at least determine if that happen and then throw some useful error.

If you're unsure, you can just "modprobe -r bq27x00_battery" as root, and try again with BNF. Without bq27x00_battery, BNF fall-back to raw i2c read (aka does, in user-space, exactly the same reading from chip that bq27x00_battery module does in kernel side), which doesn't fail.

There are exactly 0 reasons why bq27x00_battery stops giving full info when battery is not calibrated - its job is to report values from chip to sysnodes, not "censor" them, basing on module's own judgment if info is still useful. Hoever, Pali decided otherwise and can be quite stubborn on some things - I tried to convince him few times, to no avail, so I just ceased doing so.

For people interested in technical details - when battery is uncalibrated, value reported as max capacity resets to default 2048. Thus, if you see 2048 mAh (or something around it), you can be quite sure that you just need to re-calibrate. Hoever, Pali decided that giving default value is wrong, and sysnode entry giving that info just gets read error, if battery is uncalibrated (instead of, obediently, report what chip says, no matter if it's wrong or good). I don't see how error'ing read is better than giving default data, but we're stuck with it, unless someone forks that module (or kernel-power, making, for example, kernel-powernn_bq27x00_battery-fixed, for every release).

/Estel