Difference between revisions of "Ultrabay 2000 Battery"
(→Linux Support) |
(→Linux Support) |
||
| Line 22: | Line 22: | ||
=== Linux Support === | === Linux Support === | ||
| − | The second battery is correctly detected by either the APM or ACPI subsystem. However, the Linux ACPI subsystem only scans for batteries on boot. This means that the second battery must be present at boot time, or you will not be able to get any info for it. | + | The second battery is correctly detected by either the APM or ACPI subsystem. However, the Linux ACPI subsystem only scans for batteries on boot. This means that the second battery must be present at boot time, or you will not be able to get any info for it via {{path|/proc/acpi/battery/BAT1}}. |
With kernel 2.6.14.2 (possibly only with [[ibm-acpi]]) there is a sysfs file: {{path|/sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}}. There isn't one for BAT0, but {{cmdroot|cat /proc/acpi/battery/BAT0/*}} shows {{cmdresult|not present}} when there is no internal battery. | With kernel 2.6.14.2 (possibly only with [[ibm-acpi]]) there is a sysfs file: {{path|/sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}}. There isn't one for BAT0, but {{cmdroot|cat /proc/acpi/battery/BAT0/*}} shows {{cmdresult|not present}} when there is no internal battery. | ||
| Line 32: | Line 32: | ||
Also, if you compile the battery module of ACPI as a module, boot with the UltraBay battery present, remove the UltraBay battery (without doing the eject above), {{path|/proc/acpi/battery/BAT1}} is still there, while after {{cmdroot|rmmod battery && modprobe battery}} {{path|/proc/acpi/battery/BAT1}} is gone (BAT0 is back). Put the battery back in and {{path|/proc/acpi/battery/BAT1}} is still missing, do {{cmdroot|rmmod battery && modprobe battery}} and {{path|/proc/acpi/battery/BAT1}} is back. | Also, if you compile the battery module of ACPI as a module, boot with the UltraBay battery present, remove the UltraBay battery (without doing the eject above), {{path|/proc/acpi/battery/BAT1}} is still there, while after {{cmdroot|rmmod battery && modprobe battery}} {{path|/proc/acpi/battery/BAT1}} is gone (BAT0 is back). Put the battery back in and {{path|/proc/acpi/battery/BAT1}} is still missing, do {{cmdroot|rmmod battery && modprobe battery}} and {{path|/proc/acpi/battery/BAT1}} is back. | ||
| − | If you boot without the second battery {{path|/proc/ | + | If you boot without the second battery <tt>BAT1</tt> never appears in {{path|/proc}} or {{path|/sys}}. |
If you eject using the sysfs file above, <tt>BAT1</tt> disappears from both {{path|/proc}} and {{path|/sys}} and never comes back. | If you eject using the sysfs file above, <tt>BAT1</tt> disappears from both {{path|/proc}} and {{path|/sys}} and never comes back. | ||
| + | |||
| + | Fortunately, the battery status is accessible independently of the ACPI system. The [[SMAPI support for Linux|tp_smapi]] module gives battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT{0,1}}}. The BAT1 interface is always present, regardless of whether the battery is present, was present on boot, or was ejected using the sysfs interface above. | ||
| + | |||
| + | Unfortunately, all battery monitor scripts/applets currently use the ACPI interface to get battery status information. | ||
Test machine: T23. | Test machine: T23. | ||
| − | |||
| − | |||
=== Supported with === | === Supported with === | ||
Revision as of 15:00, 4 January 2006
UltraBay 2000 BatteryThis is a battery that slides into a supported UltraBay 2000. Features
|
|
IBM Partnumbers
- Marketing PN: 02K6646
- FRU PN: 02K6645
Linux Support
The second battery is correctly detected by either the APM or ACPI subsystem. However, the Linux ACPI subsystem only scans for batteries on boot. This means that the second battery must be present at boot time, or you will not be able to get any info for it via /proc/acpi/battery/BAT1.
With kernel 2.6.14.2 (possibly only with ibm-acpi) there is a sysfs file: /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject. There isn't one for BAT0, but # cat /proc/acpi/battery/BAT0/* shows not present when there is no internal battery.
For BAT1 all the states go to 0, critical, etc. .
# echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject will remove /proc/acpi/battery/BAT1 and turn off the UltraBay led. Interestingly the battery will still be discharging (charging not tested) until it is physically removed.
Also, if you compile the battery module of ACPI as a module, boot with the UltraBay battery present, remove the UltraBay battery (without doing the eject above), /proc/acpi/battery/BAT1 is still there, while after # rmmod battery && modprobe battery /proc/acpi/battery/BAT1 is gone (BAT0 is back). Put the battery back in and /proc/acpi/battery/BAT1 is still missing, do # rmmod battery && modprobe battery and /proc/acpi/battery/BAT1 is back.
If you boot without the second battery BAT1 never appears in /proc or /sys.
If you eject using the sysfs file above, BAT1 disappears from both /proc and /sys and never comes back.
Fortunately, the battery status is accessible independently of the ACPI system. The tp_smapi module gives battery status (and other features) via the sysfs interface in /sys/devices/platform/smapi/BAT{0,1}. The BAT1 interface is always present, regardless of whether the battery is present, was present on boot, or was ejected using the sysfs interface above.
Unfortunately, all battery monitor scripts/applets currently use the ACPI interface to get battery status information.
Test machine: T23.
