Description of problem: No display/monitoring of battery status on an Acer Aspire 3003 notebook Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
With which tool? The component acpid is only for the user land daemon, so if you can't find the /proc/sys entries to check battery status this would be a kernel problem. If some GUI tool doesn't display the batter status anymore this will more likely be a problem of that tool as acpid doesn't provide any of that information (as there are as far as i know no ACPI events if the battery runs lower on power). Read ya, Phil
What should I be looking for in /proc/sys? I see nothing with regard to the battery. I have found info on the web, mostly about fedora core, that kernel 2.6.13 resolve this problem with net_burst=1. Is there any fix for kernel 2.6.9 which is the current Enterprise 4 kernel?
Are you running the current kernel-2.6.9-22.EL for Red Hat Enterprise Linux 4? If yes, please post the output of the following commands here: cat /proc/acpi/battery/BAT0/info cat /proc/acpi/battery/BAT1/info If neither does exists then the laptop either doesn't support ACPI or the kernel can't find the battery properly. Thats why i think this might be a kernel related problem. Thanks, Read ya, Phil
The cat for BAT0 does not exist, but the cat for BAT1 was: present: yes design capacity: 2000 mAh last full capacity: 1632 mAh battery technology: rechargeable design voltage: 14400 mV design capacity warning: 200 mAh design capacity low: 65 mAh capacity granularity 1: 32 mAh capacity granularity 2: 32 mAh model number: 11ZL serial number: 1877 battery type: LION OEM info: SIMPLO KLaptop says there is no battery...
Forgot in last comment, I am running kernel-2.6.9-22.EL. The BAT1 info is correct for the internal battery, there should not be a BAT1 Thanks, Ray
Just updated to kernel-2.6.9-34.EL, situation still the same. Thanks, Ray
OK, this is clearly a problem of the kernel reporting your battery as BAT1 instead of BAT0 (which KLaptop probably tries to use). I'll reassign this bug to our kernel team. Read ya, Phil
I have seen a lot on the web about defective DSDT's in laptops and ways to fix them. Is there a way to use a fixed DSDT in Enterprise 4? Thanks, Ray
Acer laptops start battery annumeration (for the primary battery) at BAT1 not BAT0 as some vendors do. This info is pulled directly from BIOS and is not a kernel issue. The kernel is pulling this info directly from ACPI (BIOS): Device(BAT1) { Name(_HID, 0x0a0cd041) Name(_UID, 0x1) Method(VTOB, 1) { Store(0x1, Local0) ShiftLeft(Local0, Arg0, Local0) Return(Local0) } the kernel is doing what it should... annumerating battery based on its label in BIOS in light of this, the userspace battery monitor app should monitor all batteries, not just BAT0 this should likely be filed as a klaptop bug?
changing component to kdeutils .. klaptop is included in that package
Just some more information, cat /proc/acpi/battery/BAT1/state returns, present: yes ERROR: Unable to read battery status I have found a lot of information on the web about bad DSDT's on laptops as the cause for no battery status. They all say that a newer kernel 2.6.13 or higher with a patch to allow initrd to use a corrected DSDT.aml file. Thanks, Ray
It is definetly a kernel problem. I installed and booted form the latest kernel from kernel.org, 2.6.16.9 and the battery status displays and works fine now. No errors form cat /proc/acpi/battery/BAT1/state.
Just updated to kernel-2.6.9-34.0.1.EL, situation still the same.
Ray, Regarding Comment #13, Did you have to patch the kernel (to use a corrected DSDT.aml file)? Or can we assume its already included in the 2.6.16.9 kernel? The main issue is that RedHat doesnt have this exact hardware in house so we cant easily debug this issue. The newer upstream kernel has very different ACPI code (compared to the RHEL4 kernel), so its not completly apparent what has changed that resolved this issue upstream (too many changes). I was unable to locate a specific patch that might have been posted to resolve this single issue. So whats needed now if this is to be resolved is some help in debugging to get to the bottom of this. So I can get this fixed quickly if you are willing to help with some testing. What do I need? I would need you to try testing kernels. So the newest kernel works, but we need to figure out the oldest kernel that worked. If you start trying older and older kernels until this stops working, I can narrow things down a bit... what I need to know is what kernel this got fixed in. So for example if you can say that this worked in 2.6.12 but not 2.6.11, I can look at the differences between the kernels (which should be small) and backport the change to RHEL4. I cant see any quicker way to fix this. Otherwise I would have to make lots of educated guesses, backporting all sort patches and having you test each one for me.
I used 2.6.16.9 just as it was, no need to patch it. I did try other older kernels, but they are on my other laptop, I will let you know which others did not work so we can narrow it down a bit I know 2.6.14... did not work. I am currently using the 2.6.16.9 but HAL does not work properly with it, no /media devices... Ray
I tried 2.6.15 and the battery monitor does not work. Ray
I tried 2.6.15.7, last version 15, it did not work. Tried 2.6.16.1, first 16 version it did work, therefore the fix was in 2.6.16.1. Ray
Regarding Comment #19, just to clarify, 2.6.16 didnt work but 2.6.16.1 did?
There was no 2.6.16 kernel on kernel.org only 2.6.16.1. The only kernel prior to 2.6.16.1 was 2.6.15.7. Ray
There is a 2.6.16 kernel: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.tar.gz The reason I ask is because the Changelog for 2.6.16 (from 2.6.15.7) is very large and has a very large number of changes. The changelog for 2.6.16.1 (from 2.6.16) is much smaller and there are less differences to explore. The smaller the haystack the easier to find the needle.
Kernel 2.6.16 works, good battery status. The fix is in 2.6.16.
So I looked at the ACPI changes for patch-2.6.16... there are literally hundreds of changes to ACPI (and nothing obvious like changes to battery.c, etc). I need a little debug info here to try and narrow down what part of the code is breaking. Can you gather some debug info? (1) Rebuild the broken kernel with ACPI debugging enabled (set CONFIG_ACPI_DEBUG = y in the kernel config file), install the kernel and reboot (2) echo '0xffffffff' > /proc/acpi/debug_level (3) echo '0xffffffff' > /proc/acpi/debug_layer (4) cat /proc/acpi/battery/BAT1/state You can then turn ACPI debugging off by writing '0x0' to the same /proc/acpi/debug_* files in steps 2&3 attach a copy of /var/log/dmesg to this BugZilla as well as the /var/log/message output obtained after debugging was turned on and after the "cat /proc/acpi/battery/BAT1/state". Lots of debug info will get written to /var/log/messages You can use the test kernel I posted for testing if you like: http://people.redhat.com/bmaly/ Alternatly, you can use a pre 2.6.16 kernel (where the breakage still exists) if its easier. thanks again
Will try to test it as soon as I can. I am traveling a lot right now and am not sure when I will get to try this. Ray
Created attachment 137188 [details] dmesg file
Created attachment 137190 [details] /var/log/messages output
I have a new kernel that needs testing: http://people.redhat.com/bmaly/linux-2.6.9-acer-batt-fix.tar.gz This kernel includes a patch to fix ACPI parsing breakage due to invalid vendor-resource-length. I made an educated guess that this might be the patch to fix this issue, based on the fact that that your getting ACPI parsing breakage in the logs for Comment #26 & #27. If this doesnt resolve the issue, I will have to dig a little deeper into the ACPI changes....
This Bug seems to be identical to a kernel.org bug: http://bugzilla.kernel.org/show_bug.cgi?id=6980 Booting with "acpi_serialize" as a boot arg reportedly resolves this issue. Can this be tested? I would like to determine if this is the exact same bug or not.
Tried "acpi_serialize" with latest 2.6.9EL kernel and 2.6.16-rc1, did not work with either one.
Is anything more being done with this problem? Whenever I use my computer on battery I boot it to the 2.6.16.9 kernel and the battery status works fine. I assume that Red Hat Enterprise 5 resolves this problem, but I need to stay with 4 to maintain compatibility with other systems. I know other users with smart battery laptops must be having this problem.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.