Seemingly random battery dissapearance

[Dan Nicholson]

On Fri, Apr 30, 2010 at 4:18 AM, Dave Flogeras <dflogeras2 at gmail.com> wrote:
> Hi all
> On my netbook I have noticed that occasionally when running on battery, it
> will attempt to suspend due to my battery level being critically low (using
> KDE 4.4/powerdevil for power management). By occasionally I mean, sometimes
> I can get an enture (dis)charge out of the battery without it happening,
> other times it might happen twice within a couple hours. Never more than
> that.
> The computer is a Gateway LT2102h netbook which I read is a rebranded Acer
> Aspire One 532.  It has an Insyde H20 BIOS, which gateway doesn't seem to
> have updates for (the netbook was only released a few months ago). I run
> Gentoo Linux, and I have tried several kernels (.31, .32, .33 and the
> .34-rc5). I have also tried the latest hal release 0.5.14 (currently
> Gentoo's stable is 0.5.13) all to no avail.
> I set up halevt to monitor my hal activity and when the problem happens I
> see this:
> Property
> /org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0:battery.remaining_time
> modified (removed: 1, added: 0)
> Also it seems from lshal that my battery is no longer there.
> I have built my kernel with the old /proc/acpi/battery/BAT0 interface, and
> if I run 'cat /proc/acpi/battery/BAT0/state' the battery comes back, and
> halevt reports that the "battery.remaining_time" has been added again.
> To me, it sounds like KDE nor HAL are at fault here. It would seem that it
> is either a kernel, bios/ACPI, or hardware problem. I can rule out hardware
> in a few days, as my friend has the same netbook which I will put my HDD in
> and test with.
> So I guess my question is, how can I drill deeper. Is there a userspace (or
> otherwise) tool I can use to see why HAL is being told the battery
> disappears? My ACPI knowledge is limited.  I tried enabling power management
> debugging and ACPI debugging in the kernel, but didn't see anything unusual
> (to my eyes).

I'd suggest running "udevadm monitor" and watching dmesg while this is
happening. If you can catch it when the battery goes away, that would
be great, but you can probably look back through dmesg and deduce the
messages from when that happened.

Does the device show up in the udev output when you do 'cat
/proc/acpi/battery/BAT0/state'? If so, it certainly seems like the
kernel is sending spurious uevents to remove the device. Either way,
this would seem to be a kernel bug. I would get the dmesg output and
either open a bug at bugzilla.kernel.org assigned to the ACPI product
or send a meesage to acpi-support at lists.sourceforge.net.

Good luck.

--
Dan