532h: battery status disappears

I'm posting from my daughter's place in Melbourne. She has cable Internet!

I brought the little Aspire One 532h with me, using it now.

There's an issue with the battery status applet, it dies after awhile. I found that the problem goes back to acpi itself. Early on, get this:



But after awhile, get this:



I'm using 2.6.33-rc8, so I guess I should try with an older kernel.

---

Comments

kacpid
Username: BarryK
There is a process, spawned by the kernel I think, kacpid: [i]# ps | grep 'acpid' 10 root 0:00 [kacpid][/i] ...if I kill it, the battery becomes "present" again, but only for a short while. That kacpid comes back.

noapic
Username: BarryK
"Interesting, the boot parameter "noapic" seems to have fixed the battery applet. I'm puzzled by this. Taking a very wild punt, it seems to be a problem in the kernel, as apic support seems to be tied into smp systems, whereas this kernel is configured for a uni-processor.

noapic, nolapic
Username: BarryK
"I "spoke too soon". the battery applet lasted for quite a long time (15-20 minutes, but then died. I have repeated this. Interesting, looking at the files in /proc/acpi after the battery applet has died, the battery shows as "present: yes". It would appear that momentarily the acpi is thinking the battery is not present, which kills the battery applet (asapm), but then "comes good" again. This page is interesting: http://evuraan.blogspot.com/2007_07_01_archive.html ...it lead me to wonder, and this is very speculative, that lapic, the timer in apic, is the cause of the trouble. Perhaps turning off apic entirely brings more problems, perhaps just turning off lapic (with boot parameter "nolapic") will fix the battery applet. So that's what I've done. The battery applet has been up for over half an hour... looking good. Just to clarify my reasoning with a bit more vague speculation, that reference explains that if the CPU goes to sleep, so does lapic, which makes it an unreliable clock source. As the Atom CPU is designed to minimise power consumption, it may have a mode change that causes lapic to falter. Note, by disabling lapic at bootup, the kernel uses hpet.

Battery monitor still weird
Username: BarryK
"Not out of the woods yet! Nice fresh day, it's 6.30am here, the battery monitor tray applet is working fine with that "nolapic" kernel boot parameter. Er, except for one small thing... suddenly the 100% charged battery dropped from 100% to 12%. The reason is this: [code]# cat /proc/acpi/battery/BAT0/info present: yes design capacity: 38929 mAh last full capacity: 16392 mAh battery technology: rechargeable design voltage: 12296 mV design capacity warning: 1945 mAh design capacity low: 1167 mAh capacity granularity 1: 264 mAh capacity granularity 2: 3780 mAh model number: UM09G3 serial number: battery type: Lion OEM info: COMPAL[/code] The design capacity showing as '38929' was previously '2200'. 2200 mah is the correct capacity of this battery. The 'remaining capacity' reading is still correct. I tested by turning off the mains power. Yep, remaining capacity is dropping as expected... now at 2070 mah. design capacity still stuck at 38929 mah.

Tail chasing?
Username: Sage
"There is, of course, no way to measure the correct remaining charge of [i]any[/i] battery. Voltage is no measure of this because the discharge curve of Li-ion cells is rather flat. It seems unlikely that a coulometer is incorporated - I've never seen one. So what are these programs trying to measure? Most likely it'll be total 'on-time' from which an interpolation based on a 'standard' algorithm leads to a guesstimate of 'q'? Not difficult for the x=0 and x^max values to be reset to some spurious figure leading to the above observations. Furthermore, it is especially difficult to control overcharge/overdischarge in most rechargeables - it has to be achieved by the internal electrochemistry, a severe challenge for any sealed unit; the only moderately satisfactory cells to achieve this are Pb-acid ones!! Frankly, it's amazing that such progress that has been made with Ni-Cd/Ni-MH/Li-ion as is evident, although we are all familiar with unexpected, not to say sudden/dramatic failure all these types, including the infamous Dell firebombs. For these reasons, battery condition, however displayed, needs to be viewed with considerable circumspection. The best guide to likely remaining battery capacity is the remaining time since last full charge based on the last full discharge cycle minus delta, where delta is hopefully a small value which decreases with time and cyclelife, bearing in mind that every cell is different in detail, however closely manufacturing tolerance are maintained. In other words, believe your eyes not some smart coding - keep a spare at hand for mission-critical applications. When electric vehicles finally arrive, the infrastructure must include an extremely lucrative trade in roadside swap-out batteries. Let's hope that the world's motor manufacturers will have signed battery standardisation agreements - in blood.

Powerapplet
Username: BarryK
"I'm back home. Did get much done while I was in Melbourne, but did play around with battery and CPU temp tray applet for my Aspire One 532h netbook. I was trying to work around the quirky acpi in this netbook, not entirely successfully. But then of course, it may be that by the time 2.6.33 final is released, acpi may be fixed for my hardware. So, I should not be trying too much right now to create a workaround. Actually, what I did was modify my 'freememapplet' as that is Xlib only and uses very few resources. Being an actual swallowed window is nice, as can display information without having to mouse-over or click-on. The GTK-based 'eggtray" and 'trayicon' applets only display icons. But of course not too many system trays can swallow a window. One of the good things about JWM. I'm playing with this 'powerapplet' but don't know if will stay with it. Jemimah's Vattery looks nice.

Tags: puppy