To follow up on this old post which I just solved today:<div><br></div><div>It turned out to be a BIOS issue.  This unit is the same as the Acer Aspire One 532H, so I grabbed the latest BIOS from Acer (1.25, it came with 1.10), and installed it with fingers crossed.  The issues seem to have gone away.  Hope someone else finds this useful.<br>
<br><div class="gmail_quote">On Mon, May 3, 2010 at 1:10 PM, Dan Nicholson <span dir="ltr">&lt;<a href="mailto:dbn.lists@gmail.com">dbn.lists@gmail.com</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I&#39;d suggest running &quot;udevadm monitor&quot; and watching dmesg while this is<br>
happening. If you can catch it when the battery goes away, that would<br>
be great, but you can probably look back through dmesg and deduce the<br>
messages from when that happened.<br>
<br>
Does the device show up in the udev output when you do &#39;cat<br>
/proc/acpi/battery/BAT0/state&#39;? If so, it certainly seems like the<br>
kernel is sending spurious uevents to remove the device. Either way,<br>
this would seem to be a kernel bug. I would get the dmesg output and<br>
either open a bug at <a href="http://bugzilla.kernel.org" target="_blank">bugzilla.kernel.org</a> assigned to the ACPI product<br>
or send a meesage to <a href="mailto:acpi-support@lists.sourceforge.net">acpi-support@lists.sourceforge.net</a>.<br>
<br>
Good luck.<br>
<br>
--<br>
<font color="#888888">Dan<br>
</font></blockquote></div><br></div>