Bugzilla – Bug 130725
Add/removing battery to ultra bay causes issues
Last modified: 2008-06-25 09:52:59 UTC
On a thinkpad T42p if I insert my battery into the ultra bay while linux is running, hal does not see it (hal-device-manager does not report it). If I boot my machine with the battery inserted and then remove it, the machine does not notice the removal, but unlike bug 130722, it does not lock up.
Created attachment 55515 [details] hwinfo output of my machine
Danny, do we have such a battery, that fits into the cd-drive bay and we can test this?
Not sure. I take next week a look at this problem. @JP See you any event, if you monitor this issure with udevmonitor? Is there any change in /proc/acpi/battery/*/* ? Or any other message in /var/log/messages?
Nothing with udevmonitor, no changes in /proc/acpi/battery. In /var/log/messages for each insertion or removal i get: Oct 31 11:29:15 knight kernel: ACPI-0077: *** Warning: No context for object [dffe86c0]
In this case this is IMO a kernel/ACPI bug. I reassign the bug
Probably ... an ugly one ... Please attach acpidmp output and full dmesg (best after inserting and removing the battery one time). Stefan do we have a similar system with two batteries where this also could happen?
@thomas: I already asked Stefan. We don't have such machine.
@thomas: there is also an other bug for this, maybe the same basic problem: #130722
The only machine required should be a Thinkpad T4x and an ultra bay battery which can be ordered separately.
Could you please provide the stuff I mentioned in comment #6. If we are lucky it is some obvious DSDT bug. Otherwise I doubt I could solve this without debugging on the machine itself.
No comment for more than a month -> closing. Please reopen if you are still interested in fixing this, especially if you still have this problem with NLD10/SLES10 previews.
Reopening to attach requested data.
Created attachment 61913 [details] Acpi dump after boot with empty bay
Created attachment 61914 [details] dmesg dump after boot with empty bay
Created attachment 61915 [details] Acpi dump after inserting bay battery
Created attachment 61916 [details] dmesg after insertion
If you still have a free partition you should try the latest SLES10/NLD preview. If the problem still exists there it would raise the severity of the bug, if not it would make it easier to find the problem. Rereading a bit deeper in the DSDT, ACPI spec and kernel sources I think I could have found it: I expect the battery to throw an 0x1 (Device Check) and/or possibly a 0x3 (Eject Request) ACPI event. However for battery only 0x80 (status) and 0x81 (notify) events are handled. Unfortunately all other events are printed with a debug filter parameter that is not compiled into our kernel. So I should first compile you a kernel that prints out the events. If we know the events, I think it should be easy to add them and fix the problem. However, we should start with this with the latest SLES10/NLD10 or OpenSuse 10.1 distribution. It is easier to add things to that kernel. If you don't have a free partition or it's not possible for you to install, please let me know and I try to provide a 10.0 kernel. BTW: Is it possible for you to access SUSE employee's home directories? Or do you know some other fast disk I could place the kernel rpm for you to download/install? If not I will put it in my ftp home, but that may take a while until it is synced (better check the private button if you answer this). If the kernel is installed please do: 1)Boot with both batteries insterted. 2)Then you should see two lines instead of this one line: ACPI: Battery Slot [BAT0] (battery present) and another battery slot (BAT1) should have been exported, correct? You can check the values of each battery by cat /proc/acpi/battery/BATX/* Those values are always used to calc the battery stats. 3)Now stop the powersave, hal and acpid: "rcpowersave stop" "rchal stop" "rcacpid stop" 4)Do: cat /proc/acpi/event The command should block. If you remove the battery from the slot, does there appear a new line at the std output of the blocking command's console? If you add it again, does there appear a new line at the std output of the blocking command's console? If yes please copy the output of the lines and paste them here. 5)Please check the last lines of /var/log/messages (e.g. tail -n30 /var/log/messages) and post them. Please tell me if you can work on SLES10/NLD10 or OpenSuse 10.1 and where I should place the kernel rpm.
I'm already using the latest NLD 10 preview. The debugging data attached was from that. I have a suse network account so you can place the kernel there.
Doesn't fix it. However there is now output in dmesg.
Created attachment 62043 [details] dmesg after battery insert/remove with test kernel
Have you booted with the battery inserted? If not, please do so. Does ls /proc/acpi/battery show you two Battery devices/directories then? If yes then try: Stop powersave, hal, acpid services. Do: cat /proc/acpi/event If you now remove and reinsert the battery, does there appear lines? Also check /var/log/messages whether these suspicious ACPI warnings "no context for object" do appear/grow when you insert/eject the battery. If no, the second battery is not recognised at all... Please also have a look for newer BIOS or possible related BIOS settings (bay/battery).
Yes, two batteries are listed if I boot with the battery already in. After stopping powersave, hal, acpid nothing shows up in the /proc/acip/event when I remove and reinsert the battery. In fact I don't even get the warnings now.
After rebooting and inserting/removing the battery, the ACPI warnings grow on insert and removal. Note that when booting with the battery in the drive, gnome-power-manager (which relies on hal) saw both batteries fine and was able to report their status.
Well, hal as well as all other battery-display-programs rely on the values in /proc/acpi/battery/ . I understand the above as "When booting with device, the correct entries for both batteries are created, when booting with one and adding the other this is not the case". (Sidenote, which I cannot resist: kpowersave shows both, too, but not the separate but aggregated values - this is planned to be fixed for NLD10.) Thomas: I have (since today) a slim battery for Thinkpads, I think this will help you to fix this without JPR testing. I'll give it to you during the day.
Stefan, your statement about booting is correct.
You have to boot with the bay device you want to use. Exchanging needs rebooting at the moment. Especially the disk bays would not work at the moment anyways. However booting with the right device inserted should work. Will change this to later/remind...
*** Bug 150388 has been marked as a duplicate of this bug. ***
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(