From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Either the ACPI bios is actually flawed and the check isn't cleaning things up afterward (since all subsequent executions fail), or the check itself is flawed. Version-Release number of selected component (if applicable): kernel-2.6.14-1.1637_FC4 How reproducible: Always Steps to Reproduce: cat /proc/acpi/battery/BAT[01]/info Actual Results: present: yes ERROR: Unable to read battery information and dmesg will log ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT1._BIF] (Node c14cf500), AE_AML_METHOD_LIMIT Expected Results: No error. Additional info: I recently replaced the battery on my Thinkpad T41. At that time, I added a second battery in place of the cdrom that I rarely use. At some point after booting the machine, the battery applet will claim no battery installed. At the same time, the behaviour indicated above will be present. This doesn't happen right away, but once it happens it happens every time. To me this suggests some sort of resource or counter leak. I'm not sure what other sort of information I can provide.
The problem doesn't appear in kernel-2.6.13-1.1532_FC4.
does booting with acpi_serialize "fix" it ?
Apparently. 2.6.14-1.1644_FC4 (which also displayed the problem) has been up for about two hours now without the problem appearing.
will be interested to hear if the 1650_FC4 kernel from http://people.redhat.com/davej/kernels/Fedora/FC4 fixes it too (without the serialize bootarg)
The 1651 kernel does in fact fix the problem.
cool, progress!