ThinkWiki - User contributions [en]

User:SystemParadox

2009-08-15T01:34:23Z

SystemParadox:

My primary laptop is a {{T23}}. I also have a {{570}} which I use as a serial terminal/log watcher for my server.

Previously owned {{600}}, {{600X}} and {{T20}}.
Also have much experience with {{T22}}, {{600E}} and {{760EL}}.

My site: [http://www.systemparadox.co.uk The System Paradox (http://www.systemparadox.co.uk)]

CS4299

2007-05-12T13:08:32Z

SystemParadox:

__NOTOC__
{| width="100%"
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
=== CS4299 ===
This is a Cirrus Logic AC'97 Audio controller

This chip is sometimes incorrectly called CS4229 in IBM documentation
=== Features ===
* Chipset: CS4299
* Interface: AC'97 2.1
</div>
|style="vertical-align:top" |
|}

=== Linux OSS driver ===
This sound chip is supported by the i810_audio kernel module.

=== Linux ALSA driver ===
This sound chip is supported by the snd-intel8x0 kernel module.

=== T23 Fast Sound ===
On at least one t23 (mine) the ALSA intel8x0 driver plays sound too fast. The following {{path|/etc/asound.conf}} restores normal operation:

pcm.intel8x0-hw {
type hw
card 0
}

pcm.!default {
type plug
slave.pcm "intel8x0"
}

pcm.intel8x0 {
type dmix
ipc_key 1234
slave {
pcm "hw:0,0"
period_time 0
period_size 512
buffer_size 4096
rate 44100
}
}

ctl.intel8x0-hw {
type hw
card 0
}

=== Dmixing ===
The CS4299 is not capable of hardware mixing. This means that only one sound stream can be played at any time.
You must get the software to do the mixing for it (this will load your CPU).
The ALSA implementation of this is called DMIX. You can also run sound servers like ESD or ArtsD, but not all applications will use them.
Recent ALSA distributions have dmixing setup and enabled by default.

Otherwise just add the following to {{path|/etc/asound.conf}} :
pcm.dsp0 {
type plug
slave.pcm dmix
}
# mixer0 can stay unchanged, because
# it isn't used anyway, I guess ;)
ctl.mixer0 {
type hw
card 0
}

Now the only problem is how to tell applications to use the DMIX channel instead of dsp0. Most applications work by specifying "dmix" as the device. For command line apps use "aoss".

Hint: XMMS does not work well with dmix and the intel8x0. You will probably need to patch and recompile.

See: [http://bugs.xmms.org/show_bug.cgi?id=1716 XMMS bug 1716], [http://bugs.xmms.org/show_bug.cgi?id=2009 XMMS bug 2009] and [http://bugs.xmms.org/show_bug.cgi?id=1991 XMMS bug 1991]

You also need to disable mmap and increase the buffer and period time in the advanced options.

=== No sound after suspending to RAM ===
Fortunately it is not necessary to remove and reinsert the snd-intel8x0 module. Simply mute and unmute all the mixer controls using alsamixer or amixer. You might want to create the following script and run it after your suspend commands:
#!/bin/bash
mixers="Master PCM CD"
for mixer in $mixers ; do
amixer sset $mixer mute
amixer sset $mixer unmute
done

Other mixers you might want to add are Line (Line in on the laptop) and Aux (Line in on the docking station).
Note that the case of the mixer names is important ("Master" not "master").

=== ThinkPads this chip may be found in ===
* {{A21e}}, {{A22e}}
* {{A30}}, {{A30p}}
* {{T23}}
* {{X22}}, {{X23}}, {{X24}}
* {{i1200}}, {{i1210}}, {{i1230}}, {{i1250}}, {{i1260}}
* {{i1300}}, {{i1330}}, {{i1370}}

[[Category:Components]]

Savage

2007-02-27T20:43:15Z

SystemParadox:

== Xorg S3 Savage Driver ==

Your X11 driver of choice if you have a Thinkpad with a [[S3 Savage IX8|Savage IX]] or [[S3 SuperSavage IX/C|SuperSavage]] chip. 
It is based on [http://www.probo.com/timr/savage40.html Tim Roberts savage driver for X], which didn't improve for a long time.

=== Features ===
*supports Xinerama, DuoView and DRI.
*MergedFB is not supported. Alex Deucher's MergedFB driver (http://www.botchco.com/alex/new-savage/html/) worked, but had issues which were never fixed. The MergedFB version of his driver was never added to Xorg, and is now out of date. It will require hacking to get it to work with a newer version of Xorg.

=== Project Homepage / Availability ===
*Homepage: http://www.x.org/
*DRI capable driver included in Xorg since version 7.

=== Packages ===
Binary snapshots (DDX, DRI, DRM) are available [http://dri.freedesktop.org/snapshots/ here].

'''Note: Binary snapshots are not up-to-date anymore because of Xorg7 modular design. You should not need them with Xorg7.'''

=== CVS ===
See this page for [http://dri.freedesktop.org/wiki/Building instructions] on building from cvs.

=== Status ===
*in development, usable, secure.
*3D is supported in Xorg7 (but usable modes are limited by video RAM; with 8MB of video RAM, the DRI 3D drivers don't support 1400x1050 32-bit mode).
*with older Xorg you might want to build 3D drivers from DRI [http://dri.freedesktop.org/wiki/Building CVS]

=== Interesting links related to this project ===

*[http://www.botchco.com/alex/new-savage/html/ Alex Deucher's driver]
*[http://www.probo.com/timr/savage40.html Tim Roberts savage driver for X]
*[http://dri.sourceforge.net/cgi-bin/moin.cgi/S3Savage DRI OpenGL driver for savage chipsets]
*[http://utah-glx.sourceforge.net/ Utah GLX OpenGL Driver for Savage chipsets]

[[Category:Drivers]] [[Category:T20]] [[Category:T21]] [[Category:T22]] [[Category:T23]] [[Category:A22e]]

User:SystemParadox

2006-10-10T11:47:23Z

SystemParadox:

I own a {{T23}} running Slackware 9.1, LFS 6.0 (Both with kernels 2.4.22, 2.6.8.1 and 2.6.14.2) Arch 0.7.1 (kernel 2.6.15-arch) and WinXP Pro.
Made extensive modification to the KThinkbat applet to enable displaying dual batteries separately (and more)(though these changes were not merged into the official version, as the author added most of the features at the same time).

Previously owned {{600}}, {{600X}} and {{T20}}.
Also have much experience with {{760EL}} and {{560}}.

My site: [http://www.systemparadox.no-ip.org The System Paradox (http://www.systemparadox.no-ip.org)]

User:SystemParadox

2006-10-10T11:41:57Z

SystemParadox:

Intel Mobile Pentium III-M

2006-09-21T21:05:38Z

SystemParadox:

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
===Intel Mobile Pentium III-M===
Featuring the Tualatin core the Mobile Pentium III-M is a lot more powerful than the [[Intel Mobile Pentium III|Mobile Pentium III]]. This is proven in it's rebirth as [[Intel Pentium M (Banias)|Pentium M]].

===Features===
*700-1200 MHz tact
*133 MHz FSB (100 on some of the lv and ulv models)
*44 Million Transistors
*0.13µm fabrication process
*0.07µm gates
*1.40/1.15 VCore
*2x 16 KB L1-Cache
*512 KB L2-Cache
*[[SpeedStep|Enhanced SpeedStep]], QuickStart, Deeper Sleep
*[[SIMD|MMX]], [[SIMD|SSE]] instruction sets
</div>
|}

==Available Types and ThinkPads featuring them==
{| border=1 cellspacing=0 cellpadding=2
|- style="background:#ffdead;"
! colspan=2 | Frequency (MHz) || Bus Speed (MHz)|| colspan=2 | core Voltage (V) || colspan=2 | TDP (W) || ThinkPad Models
|- style="background:#ffdead;"
!max. !! min. !! !! high !! low !! high !! low !!
|- style="background:#efefef;"
! colspan=8 | Mobile Pentium III-M
|-
| 1333 || 800 || 133 || 1.40 || 1.15 || 22.0 || 9.8 ||
|-
| 1266 || 800 || 133 || 1.40 || 1.15 || 22.0 || 9.8 ||
|-
| 1200 || 800 || 133 || 1.40 || 1.15 || 22.0 || 9.8 || {{A30p}}, {{T23}}, {{X30}}
|-
| 1133 || 733 || 133 || 1.40 || 1.15 || 21.8 || 9.3 || {{A30}}, {{R31}}, {{T23}}, {{X24}}
|-
| 1066 || 733 || 133 || 1.40 || 1.15 || 21.0 || 9.3 || {{X30}}
|-
| 1000 || 733 || 133 || 1.40 || 1.15 || 20.5 || 9.3 || {{A30}}, {{R31}}, {{T23}}
|-
| 933 || 733 || 133 || 1.40 || 1.15 || 20.1 || 9.3 || {{A30}}
|-
| 866 || 667 || 133 || 1.40 || 1.15 || 19.5 || 8.9 || {{T23}}
|- style="background:#efefef;"
! colspan=8 | Mobile Pentium III-M (Low Voltage)
|-
| 1000 || 533 || 133 || 1.15 || 1.05 || 10.9 || 6.1 ||
|-
| 933 || 533 || 133 || 1.15 || 1.05 || 10.5 || 6.1 ||
|-
| 866 || 533 || 133 || 1.15 || 1.05 || 10.1 || 6.1 || {{X23}}?
|-
| 850 || 500 || 100 || 1.15 || 1.05 || 10.0 || 5.9 ||
|-
| 800 || 533 || 133 || 1.15 || 1.05 || 9.8 || 5.9 || {{X22}}?, {{X23}}?
|-
| 750 || 450 || 100 || 1.15 || 1.05 || 9.4 || 5.7 ||
|-
| 733 || 466 || 133 || 1.15 || 1.05 || 9.3 || 5.8 || {{X22}}?
|- style="background:#efefef;"
! colspan=8 | Mobile Pentium III-M (Ultra Low Voltage)
|-
| 866 || 400 || 133 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 850 || 400 || 100 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 800 || 400 || 100 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 750 || 350 || 100 || 1.10 || 0.95 || 7 || 3.1 ||
|-
| 733 || 400 || 133 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 700 || 300 || 100 || 1.10 || 0.95 || 7 || 3.0 ||
|}

==Thermal Specifications==

==Speedstepping==
TODO: Which kernel module is needed to enable speedstepping control? Commands to use? Automatic speedstepping?

==GCC Optimization Flags==
You should use the following if you have a Mobile Pentium III-M:
-Os -march=pentium3 -fomit-frame-pointer -pipe

"-Os" means optimise for size. "-O2" is usually the default and is probably more prefferable. If you're feeling brave you could try using "-O3", but many programs fail to compile with this (attempting to compile binutils, gcc or any other core tools with "-O3" is not recommended)

[[Category:Components]]

Intel Mobile Pentium III-M

2006-09-21T21:04:17Z

SystemParadox: /* GCC Optimization Flags */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
===Intel Mobile Pentium III-M===
Featuring the Tualatin core the Mobile Pentium III-M is a lot more powerful than the [[Intel Mobile Pentium III|Mobile Pentium III]]. This is proven in it's rebirth as [[Intel Pentium M (Banias)|Pentium M]].

===Features===
*700-1200 MHz tact
*133 MHz FSB (100 on some of the lv and ulv models)
*44 Million Transistors
*0.13µm fabrication process
*0.07µm gates
*1.40/1.15 VCore
*2x 16 KB L1-Cache
*512 KB L2-Cache
*[[SpeedStep|Enhanced SpeedStep]], QuickStart, Deeper Sleep
*[[SIMD|MMX]], [[SIMD|SSE]] instruction sets
</div>
|}

==Available Types and ThinkPads featuring them==
{| border=1 cellspacing=0 cellpadding=2
|- style="background:#ffdead;"
! colspan=2 | Frequency (MHz) || Bus Speed (MHz)|| colspan=2 | core Voltage (V) || colspan=2 | TDP (W) || ThinkPad Models
|- style="background:#ffdead;"
!max. !! min. !! !! high !! low !! high !! low !!
|- style="background:#efefef;"
! colspan=8 | Mobile Pentium III-M
|-
| 1333 || 800 || 133 || 1.40 || 1.15 || 22.0 || 9.8 ||
|-
| 1266 || 800 || 133 || 1.40 || 1.15 || 22.0 || 9.8 ||
|-
| 1200 || 800 || 133 || 1.40 || 1.15 || 22.0 || 9.8 || {{A30p}}, {{T23}}, {{X30}}
|-
| 1133 || 733 || 133 || 1.40 || 1.15 || 21.8 || 9.3 || {{A30}}, {{R31}}, {{T23}}, {{X24}}
|-
| 1066 || 733 || 133 || 1.40 || 1.15 || 21.0 || 9.3 || {{X30}}
|-
| 1000 || 733 || 133 || 1.40 || 1.15 || 20.5 || 9.3 || {{A30}}, {{R31}}, {{T23}}
|-
| 933 || 733 || 133 || 1.40 || 1.15 || 20.1 || 9.3 || {{A30}}
|-
| 866 || 667 || 133 || 1.40 || 1.15 || 19.5 || 8.9 || {{T23}}
|- style="background:#efefef;"
! colspan=8 | Mobile Pentium III-M (Low Voltage)
|-
| 1000 || 533 || 133 || 1.15 || 1.05 || 10.9 || 6.1 ||
|-
| 933 || 533 || 133 || 1.15 || 1.05 || 10.5 || 6.1 ||
|-
| 866 || 533 || 133 || 1.15 || 1.05 || 10.1 || 6.1 || {{X23}}?
|-
| 850 || 500 || 100 || 1.15 || 1.05 || 10.0 || 5.9 ||
|-
| 800 || 533 || 133 || 1.15 || 1.05 || 9.8 || 5.9 || {{X22}}?, {{X23}}?
|-
| 750 || 450 || 100 || 1.15 || 1.05 || 9.4 || 5.7 ||
|-
| 733 || 466 || 133 || 1.15 || 1.05 || 9.3 || 5.8 || {{X22}}?
|- style="background:#efefef;"
! colspan=8 | Mobile Pentium III-M (Ultra Low Voltage)
|-
| 866 || 400 || 133 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 850 || 400 || 100 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 800 || 400 || 100 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 750 || 350 || 100 || 1.10 || 0.95 || 7 || 3.1 ||
|-
| 733 || 400 || 133 || 1.10 || 0.95 || 7 || 3.4 ||
|-
| 700 || 300 || 100 || 1.10 || 0.95 || 7 || 3.0 ||
|}

==Thermal Specifications==

==GCC Optimization Flags==
You should use the following if you have a Mobile Pentium III-M:
-Os -march=pentium3 -fomit-frame-pointer -pipe

"-Os" means optimise for size. "-O2" is usually the default and is probably more prefferable. If you're feeling brave you could try using "-O3", but many programs fail to compile with this (attempting to compile binutils, gcc or any other core tools with "-O3" is not recommended)

[[Category:Components]]

How to use UltraBay batteries

2006-09-18T21:03:36Z

SystemParadox:

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charge/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is almost instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device (requires [[ibm-acpi]]). See [[How to hotswap UltraBay devices]].

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. However, if you change a full main battery for an empty one, the system will finish charging the ultrabay battery before charging the second main battery.

When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see below).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is discharged (via <tt>force_discharge</tt>) or charged (via <tt>inhibit_charge_minutes</tt> on the other battery). This only works on some ThinkPad models - see the [[tp_smapi#Model-specific_status|tp_smapi model-specific status]].

===UltraBay eject lever===
It seems that you don't have to completely remove the UltraBay battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. While the BIOS can switch to the UltraBay battery when the main battery runs out, it cannot switch fast enough when the main battery is pulled. Make sure you push the eject lever in before swapping the main battery or the system will loose power. Likewise, if you have the ultrabay lever pushed in: while the system can switch to the main battery when the ultrabay battery is empty, it cannot switch to the main battery fast enough if the ultrabay battery slips out of the bay without the lever being released- the system will loose power.

The order of charging is not affected by the state of the eject lever. Test machine: T23. May or may not work on other models.

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

Please note, that applications, like Gnome Power Manager (don't know about others) automatically sums both battery capacities and display the status together

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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.

For a GUI interface, you can use the [[KThinkBat]] applet or [[Gkrellm-ThinkBat]] plug-in.

How to make ACPI work on a ThinkPad T23

2006-08-30T16:24:09Z

SystemParadox: /* UltraBay LED stays lid */

This page deals with installing and running {{Gentoo}} Linux (2005.1) on a ThinkPad {{T23}}, Model 2647-4MG.

==Basic installation==
The default kernel (2.6.12-r6) boots OK, and recognises all the devices (modem not tested).

==ACPI==
Getting software suspend working requires some tweaking.

First of all, [[BIOS Upgrade|update to the latest BIOS and Embedded Controller Program]].

{{cmdroot|dmesg}} will probably tell you that ACPI isn't enabled in the BIOS, because the T23 BIOS has no mention of ACPI. Just add {{bootparm|lapic|}} to the kernel
arguments in {{path|/etc/lilo.conf}} or {{path|/boot/grub/menu.lst}}.

After that, you will probably get a lot of ACPI error messages, generally of the form <tt>AE_NOT_EXIST</tt>. Those can be fixed by recompiling your DSTD. To do just that, get the Intel iasl compiler source from [http://developer.intel.com/technology/iapc/acpi/downloads.htm their site] and compile it. It should build without troubles. De- and re-compile the DSDT. If it gives errors or remarks, try fixing them as best as you can. Then load the new DSDT on boot with the kernel's "Custom DSDT" option.

Now {{cmdroot|dmesg}} should show that the ACPI had found the ECDT and enabled the interpreter and you should find a full set of ACPI entries under {{path|/proc}}.

Done that, verify that the [[ibm-acpi]] driver is enabled by issuing {{cmdroot|ls /proc/acpi/ibm/*}}. If you see files in this directory, everything is alright. If the directory couldn't be found, you will have to enable [[ibm-acpi]] in your kernel config (as builtin or module) and recompile your kernel.

The next step is [[How to configure acpid|configuring acpid]], which handles the ACPI buttons through scripts in {{path|/etc/acpi}}.

To try if suspend to ram workd, press {{key|Fn}}{{key|F4}} or issue a {{cmdroot|echo -n mem >/sys/power/state}}.

===Resume problem===
If your system doesn't resume from sleep after that, use the power button to switch it off and restart. To solve the issue, try disabling S3 framebuffer support in your kernel config and recompile your kernel. Should that not be enough, try unloading suspicious drivers such as USB in your suspend script and reloading them on resume.

If all that doesn't help, build a monolithic kernel having everything you need builtin and only minimal options enabled. If it works with that kernel, start reenabling other options step by step.

===Button events===
By default, ACPI seems to handle three button events only - the Power button, the Suspend key ({{key|Fn}}{{key|F4}}) and the lid event. {{key|Fn}}{{key|F3}} (Screen blank) will need [[How to make ACPI work#Screen blanking (Standby)|extra configuration]], as well as {{key|Fn}}{{key|F12}} (Suspend to disk) (look [[How to make ACPI work#Suspend to disk (Hibernate)|here]]). {{key|Fn}}{{key|F7}}, (Switch to
video) at least blanks the LCD.

{{key|Fn}}{{key|Home}} (LED brighter), {{key|Fn}}{{key|End}} (LED dimmer), {{key|Fn}}{{key|PgUp}}
(Screen light) will work without any further effords, since they are not handled by the ACPI subsystem.

When the machine is running, the lid switch blanks the screen when
pressed and restores on release, but if the machine is suspended
pressing the switch does nothing and releasing it brings the machine out
of suspend mode.

Commands echoed to eg: {{path|/proc/acpi/ibm/light}} can be mixed with the appropriate keypresses (here,
{{key|Fn}}{{key|PgUp}}) without problems.

===Frequency Scaling===
The CPU (Pentium III-M) has power management and
throttling; use the '''acpi-cpufreq''' module instead of the '''speedstep-ich''' module to change speed automatically. The CPU has
only two speeds, and with the '''cpufreq_ondemand''' & '''cpufreq_conservative''' modules, dynamic scaling will be achieved. Alternatively, with the '''speedstep-ich''' module, you can use a shell script to flip between the performance and powersave kernel governors; everything needed can be found in the {{path|/sys/devices/system/cpu/cpu0/cpufreq}} directory.

===UltraBay LED stays lit===
The Bay LED wrongly stays lit even when in suspend to ram mode, but the most recent (1.1) [[ibm-acpi]] module provides an ACPI LED device which controls most of the LEDs (the Bay LED
is 4), so you can switch it off in your suspend script.
{{WARN|The UltraBay LED should stay lit when suspended to RAM. Any ThinkPads newer than the 600X have hot-swappable UltraBays, not warm-swappable ones. Attempting to remove or insert an UltraBay device when suspended will cause it to wake up and try to handle the request, but with Linux this usually causes lockups.}}

===Resume===
With the CPU on low speed (if it matters) and the LED off the power consumption in Suspend mode is around 580mW.

It looks as if the software to control full ACPI functionality has
only stabilised within the middle of 2005, so if you
have problems, try upgrading to IBM's latest BIOS and EBIOS, and a
kernel >=2.12. With luck, the next version or so of the S3 driver will
be free of its hang problem.

Help:Editing

2006-06-11T12:22:47Z

SystemParadox: /* use semantic formatting */

==general help==

For general help in editing please read [[Wikipedia:How_to_edit_a_page | Wikipedias "How to edit a page" page]].

==ThinkWiki editing policies==

===write with other users in your mind===
When you write an article, keep the following things in mind...
*Respect others. Try sticking to a [http://en.wikipedia.org/wiki/Npov neutral point of view]. Respect the work of other writers. Respect your (potential) readers.
*ThinkWiki is not only about the newest models. Try to write in a way that is open for older, newer and future models. This especially regards the structuring of the information you provide.
*ThinkWiki is not only about your Distro. Try to make clear if something you write is valid only for your specific linux distribution.
*Even though the article is written by you, it is a piece of information others might work on later. Try to avoid personal remarks in your articles.

===naming policies for new pages===
If you create a new page, please consider the following page naming policies. This is important to keep a persistent page naming scheme and hence to ensure that ThinkWiki still works well when it has grown more complex.

Page names (the links you create to point to the page) are used as the page Title. Considering these policies has the following advantages:
*the pages will have self-explaining titles
*in Category views like the Model view the links to the pages are expressively labeled and similar pages are sorted together
*the pages are more easily found in search engines like google

====general policies====
*It is allowed and in fact wanted that you use spaces within your page titles.
*The name you choose for the page should be as specific as its content will be. In other words...it should not be possible to write another page with more general content about the topic that your page title indicates.

====specific kinds of pages====
To sort similar pages together in the Model views, we start specific pages in defined ways.
The following table shows the naming schemes for several kinds of pages...
{| border="1" cellspacing="0" cellpadding="2"
|+page naming schemes
! page type !! naming scheme !! example
|-
| Installation instructions overview for a model || Installation instructions for the <model> || Installation instructions for the ThinkPad T41p
|-
| Installation instructions for a specific distro on a model || Installing <distro> on a <model> || Installing Gentoo on a ThinkPad T41p
|-
| other HowTos || How to ... || How to get special keys to work
|-
| Problem descriptions || Problem with ... || Problem with lm-sensors
|-
| Drivers and Tools pages || <name of driver/tool> || ibm-acpi
|-
| Patches || Patch ... || Patch disabling ACPI C3
|-
| Components || <name of component as used by IBM> || IBM 11a/b/g Wireless LAN Mini PCI Adapter II
|-
| Distro pages || Category:<distro> || Category:SUSE
|-
| ThinkPad Models || Category:<Model without "ThinkPad"> || Category:T41p
|-
| Specifications || <type number-model number> || 2373-GHG
|-
|}

=== use semantic formatting ===
Please prefer semantic formatting over beauty. To help maintaining a formatting standard, you can use the following templates.
{{NOTE|
Unfortunately, nesting templates is not possible. I.e. you can't put a cmd template inside a NOTE template.
}}
 
{| border="1" cellspacing="0" cellpadding="2"
! syntax !! resulting output
|- style="vertical-align:top;"
| <nowiki>{{cmduser|command}}</nowiki> || {{cmduser|command}}
|- style="vertical-align:top;"
| <nowiki>{{cmdroot|command}}</nowiki> || {{cmdroot|command}}
|- style="vertical-align:top;"
| <nowiki>{{cmdgrub|command}}</nowiki> || {{cmdgrub|command}}
|- style="vertical-align:top;"
| <nowiki>{{cmdresult|shell output}}</nowiki> || {{cmdresult|shell output}}
|- style="vertical-align:top;"
| <nowiki>{{cmd|command|prefix>}}</nowiki> || {{cmd|command|prefix>}}
|- style="vertical-align:top;"
| <nowiki>{{bootparm|parameter|value}}</nowiki> || {{bootparm|parameter|value}}
|- style="vertical-align:top;"
| <nowiki>{{path|/etc/config.cfg}}</nowiki> || {{path|/etc/config.cfg}}
|-
|
#<nowiki>{{kernelconf|CONFIG_SCSI|[M]|SCSI device support|SCSI device support|Device Drivers||}}</nowiki>
#<nowiki>{{kernelconf|CONFIG_SCSI|[M]|SCSI device support||||}}</nowiki>
#<nowiki>{{kernelconf|CONFIG_SCSI|[M]|||||}}</nowiki>
#<nowiki>{{kernelconf|CONFIG_SCSI||||||}}</nowiki>
#<nowiki>{{kernelconf||[M]|SCSI device support||||}}</nowiki>

''specify the menuconfig path in reverse order and fill with empty parameters to at least a total of seven''
|
#{{kernelconf|CONFIG_SCSI|[M]|SCSI device support|SCSI device support|Device Drivers||}}
#{{kernelconf|CONFIG_SCSI|[M]|SCSI device support||||}}
#{{kernelconf|CONFIG_SCSI|[M]|||||}}
#{{kernelconf|CONFIG_SCSI||||||}}
#{{kernelconf||[M]|SCSI device support||||}}
|-
| <nowiki>{{HINT|A suggestion.}}</nowiki> || {{HINT|A suggestion.}}
|- style="vertical-align:top;"
| <nowiki>{{NOTE|Take notice!}}</nowiki> || {{NOTE|Take notice!}}
|- style="vertical-align:top;"
| <nowiki>{{WARN|Be careful!}}</nowiki> || {{WARN|Be careful!}}
|- style="vertical-align:top;"
| <nowiki>{{HELP|Request for help}}</nowiki> || {{HELP|Request for help}}
|-
|<nowiki>{{key|Fn}}{{key|F4}}</nowiki> || {{key|Fn}}{{key|F4}}
|-
|<nowiki>{{ibmkey|Access IBM|#495988}} = {{ibmkey|ThinkPad|#494949}}</nowiki> || {{ibmkey|Access IBM|#495988}} = {{ibmkey|ThinkPad|#494949}}
|-
|<nowiki>to be commented{{footnote|1}}</nowiki> || to be commented{{footnote|1}}
|-
|<nowiki>{{footnotes|</nowiki> 
<nowiki>#first footnote</nowiki> 
<nowiki>#second footnote</nowiki> 
<nowiki>}}</nowiki>
|| {{footnotes|
#first footnote
#second footnote
}}
|}

=== use our Link&Categorization Templates===
To ease editing and to provide a standardized way of linking to a category and categorizing the page at the same time in that category, we introduced the following Templates. So far there are two types of these:
*Model Templates. Just write the model number surrounded by winged brackets, like i.e. <nowiki>{{T40}}</nowiki>. This will be equivalent to <nowiki>[[:Category:T40|T40]] [[Category:T40]]</nowiki>. Hence the result will be a link like this: [[:Category:T40|T40]], but at the same time, the page will be categorized under that category.
*Distribution Templates. They work the same way as Model Templates, except that for them you need to specify the Distribution name (simplest, shortest variant of it). It will create a link to that distributions category page and also categorize the page you used the template on under that category.

=== use our Editorial Templates===
{| border="1" cellspacing="0" cellpadding="2"
! syntax !! resulting output
|-
|<nowiki>{{Stub}}</nowiki> (Use only at the beginning of pages!)||{{Stub}}
|-
|<nowiki>{{Todo|needs editing}}</nowiki>||{{Todo|needs editing}}
|-
|<nowiki>{{Fixme|preliminary information}}</nowiki>||{{Fixme|preliminary information}}
|-
|<nowiki>{{Usage|do this and that}}</nowiki> (Use only at the beginning of pages!)||{{Usage|Do this and that}}
|}
'''Have fun editing!'''

User:SystemParadox

2006-06-08T23:10:57Z

SystemParadox:

User:SystemParadox

2006-06-08T23:08:12Z

SystemParadox:

Talk:How to make use of IrDA

2006-05-18T12:50:29Z

SystemParadox: /* T23 IrDA silent? */

The "wrong chip version ff" is a real issue, and having it mentioned makes sure that google searches turn it up with a solution.
[[User:Tonko|Tonko]] 01:41, 8 Oct 2005 (CEST)

----
The present text confused me (as you now have noticed). Maybe it should better reflect that the error is incorrect ("wrong chip version ff" instead of "FIR mode not enabled" or whatever). Would that be acceptable?

[[User:Pebolle|Paul Bolle]] 02:05, 8 Oct 2005 (CEST)
----
If you think you can explain it better, go right ahead. The IrDA document could use some major cleaning.

As long as we still point out that the only error in syslog is "Wrong chip version ff" when trying to load the FIR module without first activating the PnP device. It would be nice if the ISA-PNP patch to the nsc-ircc driver got accepted upstream, so we dont have to do these hacks anymore.
[[User:Tonko|Tonko]] 03:58, 8 Oct 2005 (CEST)
----
Tonko,

Is there a reason why you deleted the TODO entry for linux 2.6 kernel config for SIR? I would like to readd it, but like to hear your reason to remove it first.

[[User:Pebolle|Paul Bolle]] 10:23, 14 Oct 2005 (CEST)

== T23 debianized kernel with probs ==

Found another crazy thing here. T23 2648-2GG, with 2.6.13 and 2.6.14 (Debianized Source). Clear init of nsc-ircc and dongle, but the dongle stays offline (dark and blind). Booted with Knoppix or Bart-PE Windows give correct function of the whole device, viewed with a digicam shows some blinks at init. But not with plain 2.6.13 an 2.6.14 from Debian.
Eric

== setpnp ==

Hello,

since the nsc-ircc patch isn't in 2.6.15, I tried to go the setpnp route, but I don't even get to see {{path|/proc/bus/pnp}} even though I enabled the support for it in the kernel config (once I found out that I need to enable ISA support to even get the option). Has anyone successfully used setpnp to enable the IRDA port or is that just some sort of urban legend? ;)

--[[User:Spiney|spiney]] 19:12, 4 Jan 2006 (CET)
----

Make sure you enable pnp-bios support specifically when compiling the kernel, just enabling pnp support is not enough.
I must however admit that I have not done this, since my ancient TP 770 running a 2.4 kernel, which was at least 5 years ago.

I just looked at a 2.6 menuconfig myself, and could not find the option, but looking at my .config file I can see the CONFIG_PNPBIOS option, so you might just want to edit the config file directly, enable the PNPBIOS option, and run make oldconfig.

--[[User:Tonko|Tonko]] 19:38, 4 Jan 2006 (CET)
----

I do have the pnp-bios support enabled (the option is depending on ISA among others, checked the Kconfig file in the source tree to find it), and also the proc-Interface option, but still no go... maybe it's not compatible with CONFIG_PNPACPI? Oh well, nevermind, going back to the patch, that works with less hassles, I just hope it'll end up in the vanilla kernel eventually. Still thanks for the help.

--[[User:Spiney|spiney]] 20:22, 4 Jan 2006 (CET)
----

Ok, on further investigation (not giving up that easily ;) it really seems that CONFIG_PNPACPI is disabling PnPBIOS, at least dmesg showed something along the lines of "PnPBIOS: disabled by PnPACPI". But, after recompiling without PnPACPI, I still can't get it to work. I can use {{cmd|setpnp|}} and {{cmd|lspnp|}} just fine, but the nsc-ircc module won't load:

<pre>
t43p:~# lspnp 12
12 IBM0071 IBM Thinkpad infrared port
t43p:~# setpnp 12 io 0x2f8 irq 3
t43p:~# lspnp -v 12
12 IBM0071 IBM Thinkpad infrared port
dma 3
io 0x02f8-0x02ff
irq 3
t43p:~# modprobe nsc-ircc io=0x2f8 irq=3 dongle_id=0x09
FATAL: Error inserting nsc_ircc (/lib/modules/2.6.15/kernel/drivers/net/irda/nsc-ircc.ko): No such device
</pre>

Hmm, I'm getting somewhat annoyed... any ideas?

--[[User:Spiney|spiney]] 20:58, 4 Jan 2006 (CET)
----

have you tried just doing {{cmd|setpnp 12 on|}}

--[[User:Tonko|Tonko]] 21:05, 4 Jan 2006 (CET)
----

Yes, that was the first thing I tried, didn't help. BTW, I just fiddled around with lirc a bit (never tried it before), and the lirc_sir module works just fine:

<pre>
lirc_sir: I/O port 0x02f8, IRQ 3.
lirc_sir: Installed.
</pre>

and I was able to get it to control xmms.

{{cmd|setserial|}} doesn't claim the device either:

<pre>
t43p:~# setserial -ag /dev/ttyS0
/dev/ttyS0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 921600, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test
</pre>

I'm really out of ideas.

--[[User:Spiney|spiney]] 21:20, 4 Jan 2006 (CET)
----

Hmm, it should not be ttyS0, but ttyS1 which might be stepping on the resources
ttyS0 is IO 0x3f8 and IRQ 4, while ttyS1 is IO 0x2f8 and IRQ 3.

ttyS0 is your integrated serial port, which even ThinkPads without physical serial port have.

--[[User:Tonko|Tonko]] 21:29, 4 Jan 2006 (CET)
----
Sorry, I cut'n'paste the wrong device since I checked them both, the output for ttyS1 is identical (apart from "/dev/ttyS1, Line 1" of course).

--[[User:Spiney|spiney]] 21:36, 4 Jan 2006 (CET)
----
No idea what might be wrong, perhaps it does not work on more recent machines, or kernels.

As I said, it worked for me a long time ago on my 770X with ''something'' like this:

/bin/setserial /dev/ttyS1 uart none port 0 irq 0
setpnp 12 io 0x2f8 irq 3
setpnp 12 on
modprobe nsc-ircc dongle_id=0x09 io=0x2f8 irq=3

What is the error you get from nsc-ircc in syslog? the "Wrong chip version ff" error?

--[[User:Tonko|Tonko]] 22:22, 4 Jan 2006 (CET)
----

No errors are recorded at all (dmesg, syslog), just the message above on stderr from {{cmd|modprobe|}}.

--[[User:Spiney|spiney]] 09:27, 5 Jan 2006 (CET)
----

BTW, is it just me or does the nsc-ircc patch only work if CONFIG_PNPACPI is set in the kernel config? Otherwise the module loads fine, (but without stating in the kernel log that it found the dongle) and using IRDA does not work, irattach returns "irattach: ioctl(SIOCGIFFLAGS): No such device".

--[[User:Spiney|spiney]] 14:37, 12 Jan 2006 (CET)
----

== Not even SIR working on R52 ==

I don't want/need FIR right now, so i thought i wouldn't have to mess with it.
I don't have /proc/bus/pnp, but i'm pretty sure infrared should work without it as well.
I do not have a kernel patch and am using the current Ubuntu Breezy 2.6.12-10 kernel.
Problem is, that when starting
irattach /dev/ttyS1 -s
It complains in syslog: no such device
On ttyS0 it works fine, but well does not find any packets.

# setserial -ag /dev/ttyS1
/dev/ttyS1, Line 1, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 921600, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

# cat /dev/ttyS1
cat: /dev/ttyS1: input-/outputerror

So i tried:
sudo setserial /dev/ttyS1 uart 16550A port 0x02f8 irq 3

Well ''now'' irattach will attach to ttyS1, irdadump will show me the packets '''sent''' by my computer,
but won't receive my cellphone's packets (Nokia 6210). In Windows, everything works fine.

== T23 IrDA silent? ==

Hi.
I got SIR working pretty easily on my T20. I cannot get anything to work on my T23. I can get the nsc-ircc module to load, and now irattach works (both with and without nsc-ircc), and I've checked the relevant info in /proc/sys/net/irda, but nothing shows up in /proc/net/irda/discovery, and irdadump gives nothing at all. No errors in dmesg or the log. The red LED never lights. It flashes constantly in Windows.

Any suggestions much appreciated
--[[User:SystemParadox|SystemParadox]] 16:58, 1 May 2006 (CEST)

S3 SuperSavage IX/C

2006-05-18T12:46:55Z

SystemParadox: /* Linux kernel Framebuffer driver */

__NOTOC__
{| width="100%"
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
=== S3 SuperSavage IX/C ===
This is a S3 video adapter 
S3 is now owned by Via Technologies

=== Features ===
* Chipset: S3
* PCI ID: 5333:8c2e
* AGP 4X
* 16MB SDRAM video memory
</div>
|style="vertical-align:top" |
|}

=== Linux X.Org driver ===
This chip is supported by the '[[savage]]' driver as part of the X.Org distribution

==== ThinkPad LCD ====
Display on the internal LCD works as long as you set the monitor settings correct.

==== External VGA port ====
Works without trouble, even as Dualhead with xinerama. For swtching on/off use [[s3switch]] (also works for TVout).

==== SVideo port ====
works.

=== Linux kernel Framebuffer driver ===
This chip will work with either the 'vesa' or 'savagefb' driver as part of any recent 2.4 or 2.6 kernel.

Suspend-to-RAM however does not work properly if the framebuffer is enabled. Suspending with X running is fine, so long as the framebuffer is disabled and X is using its own savage driver. With vesafb the screen is frozen on resume (but the system is still running fine behind it). With savagefb it won't even try to wake up.
[http://dev.gentoo.org/~spock/projects/vesafb-tng/ vesafb-tng] allows the use of a modular framebuffer, which might fix this- if you can find a way of removing the framebuffer module once inserted.

=== ThinkPads this chip may be found in ===
* {{T23}}

[[Category:Components]]

CS4299

2006-05-18T12:44:52Z

SystemParadox: /* Dmixing */

CS4299

2006-05-18T12:43:52Z

SystemParadox: /* Dmixing */

Talk:How to make use of IrDA

2006-05-01T14:58:34Z

SystemParadox: /* T23 IrDA silent? */

The "wrong chip version ff" is a real issue, and having it mentioned makes sure that google searches turn it up with a solution.
[[User:Tonko|Tonko]] 01:41, 8 Oct 2005 (CEST)

----
The present text confused me (as you now have noticed). Maybe it should better reflect that the error is incorrect ("wrong chip version ff" instead of "FIR mode not enabled" or whatever). Would that be acceptable?

[[User:Pebolle|Paul Bolle]] 02:05, 8 Oct 2005 (CEST)
----
If you think you can explain it better, go right ahead. The IrDA document could use some major cleaning.

As long as we still point out that the only error in syslog is "Wrong chip version ff" when trying to load the FIR module without first activating the PnP device. It would be nice if the ISA-PNP patch to the nsc-ircc driver got accepted upstream, so we dont have to do these hacks anymore.
[[User:Tonko|Tonko]] 03:58, 8 Oct 2005 (CEST)
----
Tonko,

Is there a reason why you deleted the TODO entry for linux 2.6 kernel config for SIR? I would like to readd it, but like to hear your reason to remove it first.

[[User:Pebolle|Paul Bolle]] 10:23, 14 Oct 2005 (CEST)

== T23 debianized kernel with probs ==

Found another crazy thing here. T23 2648-2GG, with 2.6.13 and 2.6.14 (Debianized Source). Clear init of nsc-ircc and dongle, but the dongle stays offline (dark and blind). Booted with Knoppix or Bart-PE Windows give correct function of the whole device, viewed with a digicam shows some blinks at init. But not with plain 2.6.13 an 2.6.14 from Debian.
Eric

== setpnp ==

Hello,

since the nsc-ircc patch isn't in 2.6.15, I tried to go the setpnp route, but I don't even get to see {{path|/proc/bus/pnp}} even though I enabled the support for it in the kernel config (once I found out that I need to enable ISA support to even get the option). Has anyone successfully used setpnp to enable the IRDA port or is that just some sort of urban legend? ;)

--[[User:Spiney|spiney]] 19:12, 4 Jan 2006 (CET)
----

Make sure you enable pnp-bios support specifically when compiling the kernel, just enabling pnp support is not enough.
I must however admit that I have not done this, since my ancient TP 770 running a 2.4 kernel, which was at least 5 years ago.

I just looked at a 2.6 menuconfig myself, and could not find the option, but looking at my .config file I can see the CONFIG_PNPBIOS option, so you might just want to edit the config file directly, enable the PNPBIOS option, and run make oldconfig.

--[[User:Tonko|Tonko]] 19:38, 4 Jan 2006 (CET)
----

I do have the pnp-bios support enabled (the option is depending on ISA among others, checked the Kconfig file in the source tree to find it), and also the proc-Interface option, but still no go... maybe it's not compatible with CONFIG_PNPACPI? Oh well, nevermind, going back to the patch, that works with less hassles, I just hope it'll end up in the vanilla kernel eventually. Still thanks for the help.

--[[User:Spiney|spiney]] 20:22, 4 Jan 2006 (CET)
----

Ok, on further investigation (not giving up that easily ;) it really seems that CONFIG_PNPACPI is disabling PnPBIOS, at least dmesg showed something along the lines of "PnPBIOS: disabled by PnPACPI". But, after recompiling without PnPACPI, I still can't get it to work. I can use {{cmd|setpnp|}} and {{cmd|lspnp|}} just fine, but the nsc-ircc module won't load:

<pre>
t43p:~# lspnp 12
12 IBM0071 IBM Thinkpad infrared port
t43p:~# setpnp 12 io 0x2f8 irq 3
t43p:~# lspnp -v 12
12 IBM0071 IBM Thinkpad infrared port
dma 3
io 0x02f8-0x02ff
irq 3
t43p:~# modprobe nsc-ircc io=0x2f8 irq=3 dongle_id=0x09
FATAL: Error inserting nsc_ircc (/lib/modules/2.6.15/kernel/drivers/net/irda/nsc-ircc.ko): No such device
</pre>

Hmm, I'm getting somewhat annoyed... any ideas?

--[[User:Spiney|spiney]] 20:58, 4 Jan 2006 (CET)
----

have you tried just doing {{cmd|setpnp 12 on|}}

--[[User:Tonko|Tonko]] 21:05, 4 Jan 2006 (CET)
----

Yes, that was the first thing I tried, didn't help. BTW, I just fiddled around with lirc a bit (never tried it before), and the lirc_sir module works just fine:

<pre>
lirc_sir: I/O port 0x02f8, IRQ 3.
lirc_sir: Installed.
</pre>

and I was able to get it to control xmms.

{{cmd|setserial|}} doesn't claim the device either:

<pre>
t43p:~# setserial -ag /dev/ttyS0
/dev/ttyS0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 921600, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test
</pre>

I'm really out of ideas.

--[[User:Spiney|spiney]] 21:20, 4 Jan 2006 (CET)
----

Hmm, it should not be ttyS0, but ttyS1 which might be stepping on the resources
ttyS0 is IO 0x3f8 and IRQ 4, while ttyS1 is IO 0x2f8 and IRQ 3.

ttyS0 is your integrated serial port, which even ThinkPads without physical serial port have.

--[[User:Tonko|Tonko]] 21:29, 4 Jan 2006 (CET)
----
Sorry, I cut'n'paste the wrong device since I checked them both, the output for ttyS1 is identical (apart from "/dev/ttyS1, Line 1" of course).

--[[User:Spiney|spiney]] 21:36, 4 Jan 2006 (CET)
----
No idea what might be wrong, perhaps it does not work on more recent machines, or kernels.

As I said, it worked for me a long time ago on my 770X with ''something'' like this:

/bin/setserial /dev/ttyS1 uart none port 0 irq 0
setpnp 12 io 0x2f8 irq 3
setpnp 12 on
modprobe nsc-ircc dongle_id=0x09 io=0x2f8 irq=3

What is the error you get from nsc-ircc in syslog? the "Wrong chip version ff" error?

--[[User:Tonko|Tonko]] 22:22, 4 Jan 2006 (CET)
----

No errors are recorded at all (dmesg, syslog), just the message above on stderr from {{cmd|modprobe|}}.

--[[User:Spiney|spiney]] 09:27, 5 Jan 2006 (CET)
----

BTW, is it just me or does the nsc-ircc patch only work if CONFIG_PNPACPI is set in the kernel config? Otherwise the module loads fine, (but without stating in the kernel log that it found the dongle) and using IRDA does not work, irattach returns "irattach: ioctl(SIOCGIFFLAGS): No such device".

--[[User:Spiney|spiney]] 14:37, 12 Jan 2006 (CET)
----

== Not even SIR working on R52 ==

I don't want/need FIR right now, so i thought i wouldn't have to mess with it.
I don't have /proc/bus/pnp, but i'm pretty sure infrared should work without it as well.
I do not have a kernel patch and am using the current Ubuntu Breezy 2.6.12-10 kernel.
Problem is, that when starting
irattach /dev/ttyS1 -s
It complains in syslog: no such device
On ttyS0 it works fine, but well does not find any packets.

# setserial -ag /dev/ttyS1
/dev/ttyS1, Line 1, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 921600, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

# cat /dev/ttyS1
cat: /dev/ttyS1: input-/outputerror

So i tried:
sudo setserial /dev/ttyS1 uart 16550A port 0x02f8 irq 3

Well ''now'' irattach will attach to ttyS1, irdadump will show me the packets '''sent''' by my computer,
but won't receive my cellphone's packets (Nokia 6210). In Windows, everything works fine.

== T23 IrDA silent? ==

Hi.
I got SIR working pretty easily on my T20. I cannot get anything to work on my T23. I can get the nsc-ircc module to load, and now irattach works (both with and without nsc-ircc), and I've checked the relevant info in /proc/sys/net/irda, but nothing shows up in /proc/net/irda/discovery, and irdadump gives nothing at all. No errors in dmesg or the log. Works fine in Windoze.

Any suggestions much appreciated
--[[User:SystemParadox|SystemParadox]] 16:58, 1 May 2006 (CEST)

Talk:How to make use of IrDA

2006-05-01T14:57:33Z

SystemParadox: T23 IrDA silent?

The "wrong chip version ff" is a real issue, and having it mentioned makes sure that google searches turn it up with a solution.
[[User:Tonko|Tonko]] 01:41, 8 Oct 2005 (CEST)

----
The present text confused me (as you now have noticed). Maybe it should better reflect that the error is incorrect ("wrong chip version ff" instead of "FIR mode not enabled" or whatever). Would that be acceptable?

[[User:Pebolle|Paul Bolle]] 02:05, 8 Oct 2005 (CEST)
----
If you think you can explain it better, go right ahead. The IrDA document could use some major cleaning.

As long as we still point out that the only error in syslog is "Wrong chip version ff" when trying to load the FIR module without first activating the PnP device. It would be nice if the ISA-PNP patch to the nsc-ircc driver got accepted upstream, so we dont have to do these hacks anymore.
[[User:Tonko|Tonko]] 03:58, 8 Oct 2005 (CEST)
----
Tonko,

Is there a reason why you deleted the TODO entry for linux 2.6 kernel config for SIR? I would like to readd it, but like to hear your reason to remove it first.

[[User:Pebolle|Paul Bolle]] 10:23, 14 Oct 2005 (CEST)

== T23 debianized kernel with probs ==

Found another crazy thing here. T23 2648-2GG, with 2.6.13 and 2.6.14 (Debianized Source). Clear init of nsc-ircc and dongle, but the dongle stays offline (dark and blind). Booted with Knoppix or Bart-PE Windows give correct function of the whole device, viewed with a digicam shows some blinks at init. But not with plain 2.6.13 an 2.6.14 from Debian.
Eric

== setpnp ==

Hello,

since the nsc-ircc patch isn't in 2.6.15, I tried to go the setpnp route, but I don't even get to see {{path|/proc/bus/pnp}} even though I enabled the support for it in the kernel config (once I found out that I need to enable ISA support to even get the option). Has anyone successfully used setpnp to enable the IRDA port or is that just some sort of urban legend? ;)

--[[User:Spiney|spiney]] 19:12, 4 Jan 2006 (CET)
----

Make sure you enable pnp-bios support specifically when compiling the kernel, just enabling pnp support is not enough.
I must however admit that I have not done this, since my ancient TP 770 running a 2.4 kernel, which was at least 5 years ago.

I just looked at a 2.6 menuconfig myself, and could not find the option, but looking at my .config file I can see the CONFIG_PNPBIOS option, so you might just want to edit the config file directly, enable the PNPBIOS option, and run make oldconfig.

--[[User:Tonko|Tonko]] 19:38, 4 Jan 2006 (CET)
----

I do have the pnp-bios support enabled (the option is depending on ISA among others, checked the Kconfig file in the source tree to find it), and also the proc-Interface option, but still no go... maybe it's not compatible with CONFIG_PNPACPI? Oh well, nevermind, going back to the patch, that works with less hassles, I just hope it'll end up in the vanilla kernel eventually. Still thanks for the help.

--[[User:Spiney|spiney]] 20:22, 4 Jan 2006 (CET)
----

Ok, on further investigation (not giving up that easily ;) it really seems that CONFIG_PNPACPI is disabling PnPBIOS, at least dmesg showed something along the lines of "PnPBIOS: disabled by PnPACPI". But, after recompiling without PnPACPI, I still can't get it to work. I can use {{cmd|setpnp|}} and {{cmd|lspnp|}} just fine, but the nsc-ircc module won't load:

<pre>
t43p:~# lspnp 12
12 IBM0071 IBM Thinkpad infrared port
t43p:~# setpnp 12 io 0x2f8 irq 3
t43p:~# lspnp -v 12
12 IBM0071 IBM Thinkpad infrared port
dma 3
io 0x02f8-0x02ff
irq 3
t43p:~# modprobe nsc-ircc io=0x2f8 irq=3 dongle_id=0x09
FATAL: Error inserting nsc_ircc (/lib/modules/2.6.15/kernel/drivers/net/irda/nsc-ircc.ko): No such device
</pre>

Hmm, I'm getting somewhat annoyed... any ideas?

--[[User:Spiney|spiney]] 20:58, 4 Jan 2006 (CET)
----

have you tried just doing {{cmd|setpnp 12 on|}}

--[[User:Tonko|Tonko]] 21:05, 4 Jan 2006 (CET)
----

Yes, that was the first thing I tried, didn't help. BTW, I just fiddled around with lirc a bit (never tried it before), and the lirc_sir module works just fine:

<pre>
lirc_sir: I/O port 0x02f8, IRQ 3.
lirc_sir: Installed.
</pre>

and I was able to get it to control xmms.

{{cmd|setserial|}} doesn't claim the device either:

<pre>
t43p:~# setserial -ag /dev/ttyS0
/dev/ttyS0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 921600, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test
</pre>

I'm really out of ideas.

--[[User:Spiney|spiney]] 21:20, 4 Jan 2006 (CET)
----

Hmm, it should not be ttyS0, but ttyS1 which might be stepping on the resources
ttyS0 is IO 0x3f8 and IRQ 4, while ttyS1 is IO 0x2f8 and IRQ 3.

ttyS0 is your integrated serial port, which even ThinkPads without physical serial port have.

--[[User:Tonko|Tonko]] 21:29, 4 Jan 2006 (CET)
----
Sorry, I cut'n'paste the wrong device since I checked them both, the output for ttyS1 is identical (apart from "/dev/ttyS1, Line 1" of course).

--[[User:Spiney|spiney]] 21:36, 4 Jan 2006 (CET)
----
No idea what might be wrong, perhaps it does not work on more recent machines, or kernels.

As I said, it worked for me a long time ago on my 770X with ''something'' like this:

/bin/setserial /dev/ttyS1 uart none port 0 irq 0
setpnp 12 io 0x2f8 irq 3
setpnp 12 on
modprobe nsc-ircc dongle_id=0x09 io=0x2f8 irq=3

What is the error you get from nsc-ircc in syslog? the "Wrong chip version ff" error?

--[[User:Tonko|Tonko]] 22:22, 4 Jan 2006 (CET)
----

No errors are recorded at all (dmesg, syslog), just the message above on stderr from {{cmd|modprobe|}}.

--[[User:Spiney|spiney]] 09:27, 5 Jan 2006 (CET)
----

BTW, is it just me or does the nsc-ircc patch only work if CONFIG_PNPACPI is set in the kernel config? Otherwise the module loads fine, (but without stating in the kernel log that it found the dongle) and using IRDA does not work, irattach returns "irattach: ioctl(SIOCGIFFLAGS): No such device".

--[[User:Spiney|spiney]] 14:37, 12 Jan 2006 (CET)
----

== Not even SIR working on R52 ==

I don't want/need FIR right now, so i thought i wouldn't have to mess with it.
I don't have /proc/bus/pnp, but i'm pretty sure infrared should work without it as well.
I do not have a kernel patch and am using the current Ubuntu Breezy 2.6.12-10 kernel.
Problem is, that when starting
irattach /dev/ttyS1 -s
It complains in syslog: no such device
On ttyS0 it works fine, but well does not find any packets.

# setserial -ag /dev/ttyS1
/dev/ttyS1, Line 1, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 921600, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

# cat /dev/ttyS1
cat: /dev/ttyS1: input-/outputerror

So i tried:
sudo setserial /dev/ttyS1 uart 16550A port 0x02f8 irq 3

Well ''now'' irattach will attach to ttyS1, irdadump will show me the packets '''sent''' by my computer,
but won't receive my cellphone's packets (Nokia 6210). In Windows, everything works fine.

== T23 IrDA silent? ==

Hi.
I got SIR working pretty easily on my T20. I cannot get anything to work on my T23. I can get the nsc-ircc module to load, and now irattach works (both with and without nsc-ircc), and I've checked the relevant info in /proc/sys/net/irda, but nothing shows up in /proc/net/irda/discovery, and irdadump gives nothing at all. No errors in dmesg or the log. Works fine in Windoze.

Any suggestions much appreciated
Thanks
Simon

Talk:Ultrabay

2006-02-20T21:16:50Z

SystemParadox:

I am reasonably sure a Floppy drive does not exist for the UltraBay Slim.
People are told to use a USB FDD instead.

Also the UltraBay 2000 battery is not supported in UltraBay Plus.
UltraBay Plus has its own battery that should be used

----

Anyone know if it's possible to bodge together a 770X Ultrabay II CD-RW from a Ultrabay II DVD and, say, a 600E UltraSlimBay CD-RW? Just something I've been wondering for a while.

lentinj

== UltraBay II? ==

Does it seem odd that the UltraBay II was the ''first'' bay? Was there no UltraBay, or some other type of bay? -- [[User:Whizkid|Whizkid]] 00:51, 16 Apr 2005 (CEST)

----
True. ;-) It seems, that actually the drive bay in the 380 models was called UltraBay, but i don't know for sure. So i didn't add it.

[[User:Wyrfel|Wyrfel]] 00:36, 17 Apr 2005 (CEST)
----

== Not just IDE ==

Obviously UltraBay is not just an IDE interface.

Most also have a floppy interface (apart from the latest 'slim' and 'enhanced' versions), and can take a battery.

If I remember correctly you could get the floppy drive activated by hibernating the thinkpad and installing the floppy drive, so that on power up the BIOS would enable the floppy disk drive and it would work. This was in the old APM days, so it might work differently with ACPI.

----
You're right. I remember reading some IBM text about the UltraBay yesterday, which said that the controller is capable of dynamically changing the pin layout to support the different kind of devices (initiated by the BIOS). I'll try finding it again and correcting the information on the page.

[[User:Wyrfel|Wyrfel]] 23:16, 17 Apr 2005 (CEST)
----

On my 770x under ACPI, if you force the floppy driver to use 2 3.5" drives (in modprobe.conf options floppy floppy=1,4,cmos), then you get to use either external floppy / ultrabay floppy / both if you plug them in after boot time. Otherwise the autodetect only finds one. I still haven't got hotplug fully working (mostly as it depends on Linux being able to hotplug IDE devices, not just IDE controllers).

[[User:lentinj|lentinj]]
----
I added a page for the drive ([[UltraBay II Floppy Drive]]) containing your info. [[User:Wyrfel|Wyrfel]] 21:24, 9 Aug 2005 (CEST)

== First UltraBay ==
The oldest references I can find to the name 'UltraBay' are the ThinkPad 755 series (755CSE, 755CE, etc).

But the older 750 models already had the hot-swappable drive bay, and support some of the same options, so it looks like the 'UltraBay' started with the 750 series.

But then again, later models support CD-ROM drives (755CD, 760CD, etc), which certainly are not supported in these older models, but they are all called 'UltraBay'.

Tonko
----

My understanding of the original Ultrabays is as follows: 

===UltraBay===
* ThinkPads:
** 355, 355C, 355Cs
** 360, 360C, 360Cs, 360P, 360CE, 360CSE, 360PE
** 370C
** 750, 750C, 750Cs, 750P
** 755C, 755Cs, 755CE, 755CSE, 755CX
** 760C, 760L, 760E (thin model)
* Devices (probably not all devices are supported in every ThinkPad):
** 1.44MB FDD
** 2.88MB FDD
** Cellular Digital Packet Data (CDPD) - not compatible with 360P, 360PE, 750P
** IBM Wireless Modem for ARDIS
** TV Tuner (NTSC)
** 2nd HDD
** 2nd Battery
** PCMCIA Cartridge

===UltraBay - Thick ===
* ThinkPads:
** 755CD, 755CDV
** 760CD, 760LD, 760EL, 760ELD, 760E (thick model), 760XL, 760XD
** 765D, 765L
* Supports UltraBay devices, in addition to:
** CD-ROM drive

Tonko
----

== Optical drive adapters ==
I canÂ´t include this information easily in ThinkWiki. Please, help me!

I think adapters P/N (or FRU P/N) should also be mentioned: above webpages can disappear in a future, and the P/N is an unequivocal reference!. Adapters may work only in selected models!!

'''Ultrabay Enhanced optical drive Adapter''' (P/N 73P3268 Â¿or 73P3269?): it allows to use an Ultrabay Enhanced optical-drive inside of an Ultrabay 2000/Ultrabay Plus bay. Only supported in a limited list of models?.

*ftp://ftp.software.ibm.com/pc/pccbbs/options/73p3269.pdf
*[http://www-1.ibm.com/support/docview.wss?uid=psg1MIGR-53014]
*[http://www-131.ibm.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=-840&partNumber=73P3268]

'''Ultrabay Slim optical drive Adapter''' (62P4557): it allows to use an Ultrabay Slim optical-drive inside of an Ultrabay 2000/Ultrabay Plus bay.

*[http://www-131.ibm.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=-840&langId=-1&partNumber=62P4557&storeId=10000001]

Device Carrier option for Ultrabay Plus in: [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-39501], and [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-39634]

--[[User:AlBundy|AlBundy]] 19:08, 9 Aug 2005 (CEST)
----
I created some pages for this. Go to [[UltraBay Devices]] and edit the pages linked from there. [[User:Wyrfel|Wyrfel]] 20:03, 9 Aug 2005 (CEST)
----
The pages have been created and are linkted from the [[UltraBay Devices]] page. [[User:Wyrfel|Wyrfel]] 01:25, 16 Aug 2005 (CEST)
----
Thank you. [[User:AlBundy|AlBundy]] 19:50, 25 Aug 2005 (CEST)

----
Hate to be picky, but the text on [http://www.answers.com/topic/thinkpad] is surprisingly similar to that on the wiki page ... copyright, anyone? -- [mailto:liekweg@gmx.de]
----
Yepp, me, copyright! ;-) I'm the actual originator of this text and the table. Then Wikipedia migrated it from here. The article at answers.com is nothing but a quote of the Wikipedia article, as stated below it: "This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)". Hate to be picky, too, but please read carefully. ;-) [[User:Wyrfel|Wyrfel]] 12:04, 28 Sep 2005 (CEST)
----
Danggit. What got me to think that they invent the stuff on that site themselves
I don't know, but I'll increase my browser's default font size. [mailto:liekweg@gmx.de]

----

--[[User:SystemParadox|SystemParadox]] 22:16, 20 February 2006 (CET)

Anyone know how to identify the type of device in the bay (e.g. battery, floppy, hdd, cd, etc) in Linux?

The ibm_acpi readme says that the eject lever being released or inserted should generate an ACPI event. On my T23 it doesn't. It's really annoying. Ideas anyone?

Talk:Ultrabay

2006-02-20T21:15:40Z

SystemParadox:

I am reasonably sure a Floppy drive does not exist for the UltraBay Slim.
People are told to use a USB FDD instead.

Also the UltraBay 2000 battery is not supported in UltraBay Plus.
UltraBay Plus has its own battery that should be used

----

Anyone know if it's possible to bodge together a 770X Ultrabay II CD-RW from a Ultrabay II DVD and, say, a 600E UltraSlimBay CD-RW? Just something I've been wondering for a while.

lentinj

== UltraBay II? ==

Does it seem odd that the UltraBay II was the ''first'' bay? Was there no UltraBay, or some other type of bay? -- [[User:Whizkid|Whizkid]] 00:51, 16 Apr 2005 (CEST)

----
True. ;-) It seems, that actually the drive bay in the 380 models was called UltraBay, but i don't know for sure. So i didn't add it.

[[User:Wyrfel|Wyrfel]] 00:36, 17 Apr 2005 (CEST)
----

== Not just IDE ==

Obviously UltraBay is not just an IDE interface.

Most also have a floppy interface (apart from the latest 'slim' and 'enhanced' versions), and can take a battery.

If I remember correctly you could get the floppy drive activated by hibernating the thinkpad and installing the floppy drive, so that on power up the BIOS would enable the floppy disk drive and it would work. This was in the old APM days, so it might work differently with ACPI.

----
You're right. I remember reading some IBM text about the UltraBay yesterday, which said that the controller is capable of dynamically changing the pin layout to support the different kind of devices (initiated by the BIOS). I'll try finding it again and correcting the information on the page.

[[User:Wyrfel|Wyrfel]] 23:16, 17 Apr 2005 (CEST)
----

On my 770x under ACPI, if you force the floppy driver to use 2 3.5" drives (in modprobe.conf options floppy floppy=1,4,cmos), then you get to use either external floppy / ultrabay floppy / both if you plug them in after boot time. Otherwise the autodetect only finds one. I still haven't got hotplug fully working (mostly as it depends on Linux being able to hotplug IDE devices, not just IDE controllers).

[[User:lentinj|lentinj]]
----
I added a page for the drive ([[UltraBay II Floppy Drive]]) containing your info. [[User:Wyrfel|Wyrfel]] 21:24, 9 Aug 2005 (CEST)

== First UltraBay ==
The oldest references I can find to the name 'UltraBay' are the ThinkPad 755 series (755CSE, 755CE, etc).

But the older 750 models already had the hot-swappable drive bay, and support some of the same options, so it looks like the 'UltraBay' started with the 750 series.

But then again, later models support CD-ROM drives (755CD, 760CD, etc), which certainly are not supported in these older models, but they are all called 'UltraBay'.

Tonko
----

My understanding of the original Ultrabays is as follows: 

===UltraBay===
* ThinkPads:
** 355, 355C, 355Cs
** 360, 360C, 360Cs, 360P, 360CE, 360CSE, 360PE
** 370C
** 750, 750C, 750Cs, 750P
** 755C, 755Cs, 755CE, 755CSE, 755CX
** 760C, 760L, 760E (thin model)
* Devices (probably not all devices are supported in every ThinkPad):
** 1.44MB FDD
** 2.88MB FDD
** Cellular Digital Packet Data (CDPD) - not compatible with 360P, 360PE, 750P
** IBM Wireless Modem for ARDIS
** TV Tuner (NTSC)
** 2nd HDD
** 2nd Battery
** PCMCIA Cartridge

===UltraBay - Thick ===
* ThinkPads:
** 755CD, 755CDV
** 760CD, 760LD, 760EL, 760ELD, 760E (thick model), 760XL, 760XD
** 765D, 765L
* Supports UltraBay devices, in addition to:
** CD-ROM drive

Tonko
----

== Optical drive adapters ==
I canÂ´t include this information easily in ThinkWiki. Please, help me!

I think adapters P/N (or FRU P/N) should also be mentioned: above webpages can disappear in a future, and the P/N is an unequivocal reference!. Adapters may work only in selected models!!

'''Ultrabay Enhanced optical drive Adapter''' (P/N 73P3268 Â¿or 73P3269?): it allows to use an Ultrabay Enhanced optical-drive inside of an Ultrabay 2000/Ultrabay Plus bay. Only supported in a limited list of models?.

*ftp://ftp.software.ibm.com/pc/pccbbs/options/73p3269.pdf
*[http://www-1.ibm.com/support/docview.wss?uid=psg1MIGR-53014]
*[http://www-131.ibm.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=-840&partNumber=73P3268]

'''Ultrabay Slim optical drive Adapter''' (62P4557): it allows to use an Ultrabay Slim optical-drive inside of an Ultrabay 2000/Ultrabay Plus bay.

*[http://www-131.ibm.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=-840&langId=-1&partNumber=62P4557&storeId=10000001]

Device Carrier option for Ultrabay Plus in: [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-39501], and [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-39634]

--[[User:AlBundy|AlBundy]] 19:08, 9 Aug 2005 (CEST)
----
I created some pages for this. Go to [[UltraBay Devices]] and edit the pages linked from there. [[User:Wyrfel|Wyrfel]] 20:03, 9 Aug 2005 (CEST)
----
The pages have been created and are linkted from the [[UltraBay Devices]] page. [[User:Wyrfel|Wyrfel]] 01:25, 16 Aug 2005 (CEST)
----
Thank you. [[User:AlBundy|AlBundy]] 19:50, 25 Aug 2005 (CEST)

----
Hate to be picky, but the text on [http://www.answers.com/topic/thinkpad] is surprisingly similar to that on the wiki page ... copyright, anyone? -- [mailto:liekweg@gmx.de]
----
Yepp, me, copyright! ;-) I'm the actual originator of this text and the table. Then Wikipedia migrated it from here. The article at answers.com is nothing but a quote of the Wikipedia article, as stated below it: "This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)". Hate to be picky, too, but please read carefully. ;-) [[User:Wyrfel|Wyrfel]] 12:04, 28 Sep 2005 (CEST)
----
Danggit. What got me to think that they invent the stuff on that site themselves
I don't know, but I'll increase my browser's default font size. [mailto:liekweg@gmx.de]

Anyone know how to identify the type of device in the bay (e.g. battery, floppy, hdd, cd, etc) in Linux?

The ibm_acpi readme says that the eject lever being released or inserted should generate an ACPI event. On my T23 it doesn't. It's really annoying. Ideas anyone?

User:SystemParadox

2006-02-20T21:04:51Z

SystemParadox:

I own a {{T23}} running Slackware 9.1, LFS 6.0 (Both with kernels 2.4.22, 2.6.8.1 and 2.6.14.2) Arch 0.7.1 (kernel 2.6.15-arch) and WinXP Pro.
Made extensive modification to the KThinkbat applet to enable displaying dual batteries separately (and more).

Previously owned {{600}}, {{600X}} and {{T20}}.
Also have much experience with {{760EL}} and {{560}}.

User:SystemParadox

2006-02-20T21:04:32Z

SystemParadox:

I own a {{T23}} running Slackware 9.1, LFS 6.0 (Both with kernels 2.4.22, 2.6.8.1 and 2.6.14.2) Arch 0.7.1 (kernel 2.6.15-arch) and WinXP Pro.
Made extensive modification to the KThinkbat applet to enable displaying dual batteries separately (and more).

Previously owned {{600}}, {{600X}} and a {{T20}}.
Also have much experience with {{760EL}} and {{560}}.

Ultrabay

2006-02-15T15:30:22Z

SystemParadox: /* Hotswapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;" | [[Image:UltraBay.jpg|UltraBay drives]] __NOTOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
=== IBM UltraBay ===
UltraBay{{footnote|1}} is IBM's name for the swapable drive slot. With IBMs words: <blockquote>"The ThinkPad UltraBay, also standard with the system, is an intelligent bay that switches its pinout signals to allow the installation of standard and optional features in what would normally be just the FDD bay."</blockquote> Introduced back in the times of the 750 ThinkPads, this technology has gone through redesigns with almost every new generation of ThinkPad models, possibly leading to some confusion that is hopefully cleared up here. The following table gives an overview of the different UltraBay types, in which models they occurred and what drives are available for them.
Note that the optical drive bay in G series ThinkPads is not an UltraBay in that the drives are fixed and not removable.

On the media side different UltraBays relate to the form factor of the drives they accept, e.g early A, T and X series models can accept UltraBay devices up to 12.5mm in thickness, whereas current T and X series machines are limited to devices no more than 9.5mm thick.
</div>
|}
{| border="1" cellspacing="0" cellpadding="2"
|+Overview over UltraBay types and available devices
! width=140px|UltraBay Type !! featured in !! available drives (see [[UltraBay Devices]] for details)

|-
| [[Image:Icon20_ultrabay.png]] UltraBay || {{355}}, {{355C}}, {{355Cs}}, {{360}}, {{360C}}, {{360Cs}}, {{360P}}, {{360CE}}, {{360CSE}}, {{360PE}}, {{370C}}, {{750}}, {{750C}}, {{750Cs}}, {{750P}}, {{755C}}, {{755CE}}, {{755Cs}}, {{755CSE}}, {{755CV}}, {{755CX}}, {{760C}}, {{760L}}, {{760E}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabay.png]] UltraBay Thick|| {{755CD}}, {{755CDV}}, {{760CD}}, {{760E}}, {{760ED}}, {{760EL}}, {{760ELD}}, {{760LD}}, {{760XD}}, {{760XL}}, {{765D}}, {{765L}}, [[SelectaDock I]], [[SelectaDock II]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabayii.png]] UltraBay II || {{770}}, {{770E}}, {{770ED}}, {{770X}}, {{770Z}}, [[SelectaDock III]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayfx.png]] UltraBay FX|| {{390}}, {{390E}}, {{390X}}, {{i1720}}, {{i1721}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultraslimbay.png]] UltraslimBay || {{600}}, {{600E}}, {{600X}}, [[UltraBase]], [[Portable Drive Bay]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 || {{A20m}}, {{A20p}}, {{A21e}}, {{A21m}}, {{A21p}}, {{A22e}}, {{A22m}}, {{A22p}}, {{A30}}, {{T20}}, {{T21}}, {{T22}}, {{T23}}, [[ThinkPad Dock|Dock]], [[ThinkPad Dock II|Dock II]], [[UltraBase X2]], [[Portable Drive Bay 2000]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayplus.png]] UltraBay Plus || {{A30}}, {{A30p}}, {{A31}}, {{A31p}}, {{R30}}, {{R31}}, {{R32}}, {{R40}}, {{T23}}, {{T30}}, [[UltraBase X3]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], WorkPad Cradle, Numpad
|-
| [[Image:Icon20_ultrabayslim.png]] UltraBay Slim || {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{T60p}}, {{Z60t}}, [[UltraBase X4]], [[UltraBase X6]], [[ThinkPad X4 Dock]] || [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], Serial/Parallel Port Adapter
|-
| [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced || {{R50}}, {{R50p}}, {{R51}}, {{R52}}, {{Z60m}} [[ ThinkPad Advanced Dock]]|| [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
|}

{| border="1" cellspacing="0" cellpadding="2" style="text-align:center;"
|+Compatibility Matrix (read columns as slots with rows as devices that are compatible)
! Slots<hr />Devices!! [[Image:Icon20_ultrabay.png]] UltraBay   !! [[Image:Icon20_ultrabay.png]] UltraBay Thick !! [[Image:Icon20_ultrabayii.png]] UltraBay II !! [[Image:Icon20_ultrabayfx.png]] UltraBay FX !! [[Image:Icon20_ultraslimbay.png]] UltraslimBay   !! [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 !! [[Image:Icon20_ultrabayplus.png]] UltraBay Plus !! [[Image:Icon20_ultrabayslim.png]] UltraBay Slim !! [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced
|-
|'''UltraBay''' || yes || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay Thick''' || - || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay II''' || - || - || yes || - || - || - || - || - || -
|-
|'''UltraBay FX''' || - || - || - || yes || - || - || - || - || -
|-
|'''UltraslimBay''' || - || - || - || - || yes || - || - || - || -
|-
|'''UltraBay 2000''' || - || - || - || - || - || yes || yes || - || -
|-
|'''UltraBay Plus''' || - || - || - || - || - || - || yes || - || -
|-
|'''UltraBay Slim''' || - || - || - || - || - || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || yes || yes
|-
|'''UltraBay Enhanced''' || - || - || - || - || - || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || - || yes
|}

===Characteristics===
*UltraBay: no hot swapping
*UltraBay Thick: Thicker version of UltraBay to support CD-ROM drive
*UltraBay II: supports hot swapping, blending has cut out edge on the right
*UltraBay FX: the combined [[Floppy]] drive and CD-ROM, DVD or CDRW mechanism found in the {{390}}/{{390E}}/{{390X}}
*UltraSlimBay: supports hot swapping; Frame, rectangle like blending
*UltraBay 2000: supports hot swapping; Frame, blending has cut out egde on the right
*UltraBay Plus: same as UltraBay 2000, but can take the [[UltraBay Plus Device Carrier]] which in turn can hold the [[UltraBay Plus c500 Cradle]] or the [[UltraBay Plus Numeric Keypad]]
*UltraBay Slim: supports hot swapping; notably thinner than UltraBay 2000, cut out right edge in blending
*UltraBay Enhanced: supports hot swapping; slightly thicker than UltraBay Slim, but accepts UltraBay Slim devices

==Linux Support==
The pinout switching is done by the BIOS and hardware, so that it is completely transparent to the operating system.
*Floppy drives are supported by the standard floppy driver.
*ZIP drive support is possible through the ide-disk driver.
*IDE hard disks and optical drives are supported by the IDE or <tt>ata_piix</tt> driver in the linux kernel. SCSI emulation via ide-scsi is possible.
*Batteries are automatically handled by the hardware (and can be controlled by using [[tp_smapi]]).
*UltraBay Plus devices should be handled by the USB subsystem, but if the devices are is not known.

===Hotswapping===
Hotswapping is supposed to be supported as well, using hdparm to (un)register devices.
People reported varying success with this (see below).

The [[ibm-acpi]] kernel module has an eject function ({{cmdroot|echo eject > /proc/acpi/ibm/bay}}). This only manages the ACPI calls to power down the device and the bay. It does not actually unregister the device from the IDE driver. {{cmdroot|cat /proc/acpi/ibm/bay}} shows "unoccupied" unless an IDE device is present, but the eject function still works and should still be used.

To unregister the device, try using the Debian hotswap package. This also allows the drive to be swapped as a normal user by default, which is useful. You should use hotswap to unregister the device and then {{cmdroot|echo eject > /proc/acpi/ibm/bay}}. This was reported to work on a ThinkPad {{T23}} (kernels 2.6.8.1, 2.6.14.2 and 2.6.15-arch) and {{T42}} (kernel 2.6.13), but fails on a ThinkPad {{T43}} (kernel 2.6.14.3).

Only IDE devices (HDD's, optical drives, zip drives) require special treatment - batteries, floppies and other devices can just be pulled from the bay, provided they are not mounted or in use at the time. However, you should still power them down first using the [[ibm-acpi]] eject function.

{{HELP|How do you identify the ultrabay device in Linux?}}

==External Sources==
*[http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50366 IBMs page on using a second hard drive adapter in the Ultrabay 2000 slot under Linux]

{{footnotes|
#IBM originally used the spelling UltraBay with a capital B and later switched to Ultrabay with a lower b. We are sticking with the capital B here.
}}

[[Category:Glossary]]

Ultrabay

2006-02-15T10:32:48Z

SystemParadox: /* Hotswapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;" | [[Image:UltraBay.jpg|UltraBay drives]] __NOTOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
=== IBM UltraBay ===
UltraBay{{footnote|1}} is IBM's name for the swapable drive slot. With IBMs words: <blockquote>"The ThinkPad UltraBay, also standard with the system, is an intelligent bay that switches its pinout signals to allow the installation of standard and optional features in what would normally be just the FDD bay."</blockquote> Introduced back in the times of the 750 ThinkPads, this technology has gone through redesigns with almost every new generation of ThinkPad models, possibly leading to some confusion that is hopefully cleared up here. The following table gives an overview of the different UltraBay types, in which models they occurred and what drives are available for them.
Note that the optical drive bay in G series ThinkPads is not an UltraBay in that the drives are fixed and not removable.

On the media side different UltraBays relate to the form factor of the drives they accept, e.g early A, T and X series models can accept UltraBay devices up to 12.5mm in thickness, whereas current T and X series machines are limited to devices no more than 9.5mm thick.
</div>
|}
{| border="1" cellspacing="0" cellpadding="2"
|+Overview over UltraBay types and available devices
! width=140px|UltraBay Type !! featured in !! available drives (see [[UltraBay Devices]] for details)

|-
| [[Image:Icon20_ultrabay.png]] UltraBay || {{355}}, {{355C}}, {{355Cs}}, {{360}}, {{360C}}, {{360Cs}}, {{360P}}, {{360CE}}, {{360CSE}}, {{360PE}}, {{370C}}, {{750}}, {{750C}}, {{750Cs}}, {{750P}}, {{755C}}, {{755CE}}, {{755Cs}}, {{755CSE}}, {{755CV}}, {{755CX}}, {{760C}}, {{760L}}, {{760E}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabay.png]] UltraBay Thick|| {{755CD}}, {{755CDV}}, {{760CD}}, {{760E}}, {{760ED}}, {{760EL}}, {{760ELD}}, {{760LD}}, {{760XD}}, {{760XL}}, {{765D}}, {{765L}}, [[SelectaDock I]], [[SelectaDock II]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabayii.png]] UltraBay II || {{770}}, {{770E}}, {{770ED}}, {{770X}}, {{770Z}}, [[SelectaDock III]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayfx.png]] UltraBay FX|| {{390}}, {{390E}}, {{390X}}, {{i1720}}, {{i1721}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultraslimbay.png]] UltraslimBay || {{600}}, {{600E}}, {{600X}}, [[UltraBase]], [[Portable Drive Bay]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 || {{A20m}}, {{A20p}}, {{A21e}}, {{A21m}}, {{A21p}}, {{A22e}}, {{A22m}}, {{A22p}}, {{A30}}, {{T20}}, {{T21}}, {{T22}}, {{T23}}, [[ThinkPad Dock|Dock]], [[ThinkPad Dock II|Dock II]], [[UltraBase X2]], [[Portable Drive Bay 2000]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayplus.png]] UltraBay Plus || {{A30}}, {{A30p}}, {{A31}}, {{A31p}}, {{R30}}, {{R31}}, {{R32}}, {{R40}}, {{T23}}, {{T30}}, [[UltraBase X3]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], WorkPad Cradle, Numpad
|-
| [[Image:Icon20_ultrabayslim.png]] UltraBay Slim || {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{T60p}}, {{Z60t}}, [[UltraBase X4]], [[UltraBase X6]], [[ThinkPad X4 Dock]] || [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], Serial/Parallel Port Adapter
|-
| [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced || {{R50}}, {{R50p}}, {{R51}}, {{R52}}, {{Z60m}} [[ ThinkPad Advanced Dock]]|| [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
|}

{| border="1" cellspacing="0" cellpadding="2" style="text-align:center;"
|+Compatibility Matrix (read columns as slots with rows as devices that are compatible)
! Slots<hr />Devices!! [[Image:Icon20_ultrabay.png]] UltraBay   !! [[Image:Icon20_ultrabay.png]] UltraBay Thick !! [[Image:Icon20_ultrabayii.png]] UltraBay II !! [[Image:Icon20_ultrabayfx.png]] UltraBay FX !! [[Image:Icon20_ultraslimbay.png]] UltraslimBay   !! [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 !! [[Image:Icon20_ultrabayplus.png]] UltraBay Plus !! [[Image:Icon20_ultrabayslim.png]] UltraBay Slim !! [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced
|-
|'''UltraBay''' || yes || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay Thick''' || - || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay II''' || - || - || yes || - || - || - || - || - || -
|-
|'''UltraBay FX''' || - || - || - || yes || - || - || - || - || -
|-
|'''UltraslimBay''' || - || - || - || - || yes || - || - || - || -
|-
|'''UltraBay 2000''' || - || - || - || - || - || yes || yes || - || -
|-
|'''UltraBay Plus''' || - || - || - || - || - || - || yes || - || -
|-
|'''UltraBay Slim''' || - || - || - || - || - || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || yes || yes
|-
|'''UltraBay Enhanced''' || - || - || - || - || - || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || - || yes
|}

===Characteristics===
*UltraBay: no hot swapping
*UltraBay Thick: Thicker version of UltraBay to support CD-ROM drive
*UltraBay II: supports hot swapping, blending has cut out edge on the right
*UltraBay FX: the combined [[Floppy]] drive and CD-ROM, DVD or CDRW mechanism found in the {{390}}/{{390E}}/{{390X}}
*UltraSlimBay: supports hot swapping; Frame, rectangle like blending
*UltraBay 2000: supports hot swapping; Frame, blending has cut out egde on the right
*UltraBay Plus: same as UltraBay 2000, but can take the [[UltraBay Plus Device Carrier]] which in turn can hold the [[UltraBay Plus c500 Cradle]] or the [[UltraBay Plus Numeric Keypad]]
*UltraBay Slim: supports hot swapping; notably thinner than UltraBay 2000, cut out right edge in blending
*UltraBay Enhanced: supports hot swapping; slightly thicker than UltraBay Slim, but accepts UltraBay Slim devices

==Linux Support==
The pinout switching is done by the BIOS and hardware, so that it is completely transparent to the operating system.
*Floppy drives are supported by the standard floppy driver.
*ZIP drive support is possible through the ide-disk driver.
*IDE hard disks and optical drives are supported by the IDE or <tt>ata_piix</tt> driver in the linux kernel. SCSI emulation via ide-scsi is possible.
*Batteries are automatically handled by the hardware (and can be controlled by using [[tp_smapi]]).
*UltraBay Plus devices should be handled by the USB subsystem, but if the devices are is not known.

===Hotswapping===
Hotswapping is supposed to be supported as well, using hdparm to (un)register devices.
People reported varying success with this (see below).

The [[ibm-acpi]] kernel module has an eject function ({{cmdroot|echo eject > /proc/acpi/ibm/bay}}). This only manages the ACPI calls to power down the device and the bay. It does not actually unregister the device from the IDE driver. {{cmdroot|cat /proc/acpi/ibm/bay}} shows "unoccupied" unless an IDE device is present, but the eject function still works and should still be used.

To unregister the device, try using the Debian hotswap package. This also allows the drive to be swapped as a normal user by default, which is useful. You should use hotswap to unregister the device and then {{cmdroot|echo eject > /proc/acpi/ibm/bay}}. This was reported to work on a ThinkPad {{T23}} (kernel 2.6.14.2) and {{T42}} (kernel 2.6.13), but fails on a ThinkPad {{T43}} (kernel 2.6.14.3).

Only IDE devices (HDD's, optical drives, zip drives) require special treatment - batteries, floppies and other devices can just be pulled from the bay, provided they are not mounted or in use at the time. However, you should still power them down first using the [[ibm-acpi]] eject function.

{{HELP|How do you identify the ultrabay device in Linux?}}

==External Sources==
*[http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50366 IBMs page on using a second hard drive adapter in the Ultrabay 2000 slot under Linux]

{{footnotes|
#IBM originally used the spelling UltraBay with a capital B and later switched to Ultrabay with a lower b. We are sticking with the capital B here.
}}

[[Category:Glossary]]

User:SystemParadox

2006-02-15T10:23:52Z

SystemParadox:

User:SystemParadox

2006-02-15T10:23:41Z

SystemParadox:

User:SystemParadox

2006-02-15T10:22:16Z

SystemParadox:

How to use UltraBay batteries

2006-01-26T15:57:05Z

SystemParadox: /* UltraBay eject lever */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charge/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device (requires [[ibm-acpi]]).

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see below).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===UltraBay eject lever===
It seems that you don't have to completely remove the UltraBay battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. While the BIOS can switch to the UltraBay battery when the main battery runs out, it cannot switch fast enough when the main battery is pulled. Make sure you push the eject lever in before swapping the main battery or the system will power down. The order of charging is not affected. Test machine: T23. May or may not work on other models.

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-26T15:53:15Z

SystemParadox: /* UltraBay eject lever */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charge/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device (requires [[ibm-acpi]]).

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see below).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===UltraBay eject lever===
It seems that you don't have to completely remove the UltraBay battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. While the BIOS can switch to the UltraBay battery when the main battery runs out, it cannot switch fast enough when the main battery is pulled (the system powers down). Make sure you push the eject lever in before swapping the main battery. The order of charging is not affected. Test machine: T23. May or may not work on other models.

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

User:SystemParadox

2006-01-26T15:51:02Z

SystemParadox:

I own a {{T23}} running Slackware 9.1, LFS 6.0 (Both with kernels 2.4.22, 2.6.8.1 and 2.6.14.2) and WinXP Pro.
Made extensive modification to the KThinkbat applet to enable displaying dual batteries separately.

How to use UltraBay batteries

2006-01-25T17:58:41Z

SystemParadox: /* Battery hot-swapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charge/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device (requires IBM-ACPI: http://ibm-acpi.sourceforge.net) .

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see below).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===UtraBay eject lever===
It seems that you don't have to completely remove the UltraBay battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. The order of charging is not affected. Test machine: T23. May or may not work on other models.

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-25T17:56:32Z

SystemParadox: /* UtraBay eject lever */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charge/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see below).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===UtraBay eject lever===
It seems that you don't have to completely remove the UltraBay battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. The order of charging is not affected. Test machine: T23. May or may not work on other models.

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-25T17:55:52Z

SystemParadox:

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charge/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see below).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===UtraBay eject lever===
It seems that you don't have to completely remove the battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. The order of charging is not affected. Test machine: T23. May or may not work on other models.

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-25T16:17:05Z

SystemParadox: /* Battery hot-swapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charges/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

It seems that you don't have to completely remove the battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. When charging, the main battery is always charged before the UltraBay battery, regardless of the state of the eject lever. Test machine: T23. May or may not work on other models.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see above).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-25T16:16:05Z

SystemParadox: /* Battery hot-swapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charges/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

It seems that you don't have to completely remove the battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the ultrabay battery. When charging, the main battery is always charged before the ultrabay battery, regardless of the state of the eject lever. Test machine: T23. May or may not work on other models.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see above).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-25T15:03:43Z

SystemParadox: /* Battery hot-swapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charges/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

It seems that you don't have to completely remove the battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the ultrabay battery. Charging not tested. Test machine: T23. May not work on other models.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see above).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

Ultrabay

2006-01-20T18:25:29Z

SystemParadox: /* Hotswapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;" | [[Image:UltraBay.jpg|UltraBay drives]] __NOTOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
=== IBM UltraBay ===
UltraBay{{footnote|1}} is IBM's name for the swapable drive slot. With IBMs words: "The ThinkPad UltraBay, also standard with the system, is an intelligent bay that switches its pinout signals to allow the installation of standard and optional features in what would normally be just the FDD bay." Introduced back in the times of the 750 ThinkPads, this technology has gone through redesigns with almost every new generation of ThinkPad models, possibly leading to some confusion that is hopefully cleared up here. The following table gives an overview of the different UltraBay types, in which models they occurred and what drives are available for them.
Note that the optical drive bay in G series ThinkPads is not an UltraBay in that the drives are fixed and not removable.

On the media side different UltraBays relate to the form factor of the drives they accept, e.g early A, T and X series models can accept UltraBay devices up to 12.5mm in thickness, whereas current T and X series machines are limited to devices no more than 9.5mm thick.
</div>
|}
{| border="1" cellspacing="0" cellpadding="2"
|+Overview over UltraBay types and available devices
! width=140px|UltraBay Type !! featured in !! available drives (see [[UltraBay Devices]] for details)

|-
| [[Image:Icon20_ultrabay.png]] UltraBay || {{355}}, {{355C}}, {{355Cs}}, {{360}}, {{360C}}, {{360Cs}}, {{360P}}, {{360CE}}, {{360CSE}}, {{360PE}}, {{370C}}, {{750}}, {{750C}}, {{750Cs}}, {{750P}}, {{755C}}, {{755CE}}, {{755Cs}}, {{755CSE}}, {{755CV}}, {{755CX}}, {{760C}}, {{760L}}, {{760E}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabay.png]] UltraBay Thick|| {{755CD}}, {{755CDV}}, {{760CD}}, {{760E}}, {{760ED}}, {{760EL}}, {{760ELD}}, {{760LD}}, {{760XD}}, {{760XL}}, {{765D}}, {{765L}}, [[SelectaDock I]], [[SelectaDock II]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabayii.png]] UltraBay II || {{770}}, {{770E}}, {{770ED}}, {{770X}}, {{770Z}}, [[SelectaDock III]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayfx.png]] UltraBay FX|| {{390}}, {{390E}}, {{390X}}, {{i1720}}, {{i1721}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultraslimbay.png]] UltraslimBay || {{600}}, {{600E}}, {{600X}}, [[UltraBase]], [[Portable Drive Bay]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 || {{A20m}}, {{A20p}}, {{A21e}}, {{A21m}}, {{A21p}}, {{A22e}}, {{A22m}}, {{A22p}}, {{A30}}, {{T20}}, {{T21}}, {{T22}}, {{T23}}, [[ThinkPad Dock|Dock]], [[ThinkPad Dock II|Dock II]], [[UltraBase X2]], [[Portable Drive Bay 2000]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayplus.png]] UltraBay Plus || {{A30}}, {{A30p}}, {{A31}}, {{A31p}}, {{R30}}, {{R31}}, {{R32}}, {{R40}}, {{T23}}, {{T30}}, [[UltraBase X3]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], WorkPad Cradle, Numpad
|-
| [[Image:Icon20_ultrabayslim.png]] UltraBay Slim || {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{Z60t}}, [[UltraBase X4]], [[UltraBase X6]], [[ThinkPad X4 Dock]] || [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced || {{R50}}, {{R50p}}, {{R51}}, {{R52}}, {{Z60m}} [[ ThinkPad Advanced Dock]]|| [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
|}

{| border="1" cellspacing="0" cellpadding="2" style="text-align:center;"
|+Compatibility Matrix (read columns as slots with rows as devices that are compatible)
! Slots<hr />Devices!! [[Image:Icon20_ultrabay.png]] UltraBay   !! [[Image:Icon20_ultrabay.png]] UltraBay Thick !! [[Image:Icon20_ultrabayii.png]] UltraBay II !! [[Image:Icon20_ultrabayfx.png]] UltraBay FX !! [[Image:Icon20_ultraslimbay.png]] UltraslimBay   !! [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 !! [[Image:Icon20_ultrabayplus.png]] UltraBay Plus !! [[Image:Icon20_ultrabayslim.png]] UltraBay Slim !! [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced
|-
|'''UltraBay''' || yes || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay Thick''' || - || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay II''' || - || - || yes || - || - || - || - || - || -
|-
|'''UltraBay FX''' || - || - || - || yes || - || - || - || - || -
|-
|'''UltraslimBay''' || - || - || - || - || yes || - || - || - || -
|-
|'''UltraBay 2000''' || - || - || - || - || - || yes || yes || - || -
|-
|'''UltraBay Plus''' || - || - || - || - || - || - || yes || - || -
|-
|'''UltraBay Slim''' || - || - || - || - || - || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || yes || yes
|-
|'''UltraBay Enhanced''' || - || - || - || - || - || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || - || yes
|}

===Characteristics===
*UltraBay: no hot swapping
*UltraBay Thick: Thicker version of UltraBay to support CD-ROM drive
*UltraBay II: supports hot swapping, blending has cut out edge on the right
*UltraBay FX: the combined [[Floppy]] drive and CD-ROM, DVD or CDRW mechanism found in the {{390}}/{{390E}}/{{390X}}
*UltraSlimBay: supports hot swapping; Frame, rectangle like blending
*UltraBay 2000: supports hot swapping; Frame, blending has cut out egde on the right
*UltraBay Plus: same as UltraBay 2000, but can take the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46440 UltraBay Plus Device Carrier] which in turn can hold the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46440 UltraBay Plus WorkPad Cradle] or the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46440 UltraBay Plus Numeric Keypad]
*UltraBay Slim: supports hot swapping; notably thinner than UltraBay 2000, cut out right edge in blending
*UltraBay Enhanced: supports hot swapping; slightly thicker than UltraBay Slim, but accepts UltraBay Slim devices

==Linux Support==
The pinout switching is done by the BIOS and hardware, so that it is completely transparent to the operating system.
*Floppy drives are supported by the standard floppy driver.
*ZIP drive support is possible through the ide-disk driver.
*IDE hard disks and optical drives are supported by the IDE or <tt>ata_piix</tt> driver in the linux kernel. SCSI emulation via ide-scsi is possible.
*Batteries are automatically handled by the hardware (and can be controlled by using [[tp_smapi]]).
*UltraBay Plus devices should be handled by the USB subsystem, but if the devices are is not known.

===Hotswapping===
Hotswapping is supposed to be supported as well, using hdparm to (un)register devices.
People reported varying success with this (see below).

The IBM-ACPI kernel module (http://ibm-acpi.sourceforge.net) has an eject function ({{cmdroot|echo eject > /proc/acpi/ibm/bay}}). This only manages the ACPI calls to power down the device and the bay. It does not actually unregister the device from the IDE driver. {{cmdroot|cat /proc/acpi/ibm/bay}} shows "unoccupied" unless an IDE device is present, but the eject function still works and should still be used.

To unregister the device, try using the Debian hotswap package. This also allows the drive to be swapped as a normal user by default, which is useful. You should use hotswap to unregister the device and then "echo eject > /proc/acpi/ibm/bay". This was reported to work on a ThinkPad {{T23}} (kernel 2.6.14.2) and {{T42}} (kernel 2.6.13), but fails on a ThinkPad {{T43}} (kernel 2.6.14.3).

Only IDE devices (HDD's, optical drives, zip drives) require special treatment - batteries, floppies and other devices can just be pulled from the bay, provided they are not mounted or in use at the time. However, you should still power them down first using the IBM-ACPI eject function.

==External Sources==
*[http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50366 IBMs page on using a second hard drive adapter in the Ultrabay 2000 slot under Linux]

{{footnotes|
#IBM originally used the spelling UltraBay with a capital B and later switched to Ultrabay with a lower b. We are sticking with the capital B here.
}}

[[Category:Glossary]]

Ultrabay

2006-01-20T18:22:36Z

SystemParadox: /* Hotswapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;" | [[Image:UltraBay.jpg|UltraBay drives]] __NOTOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
=== IBM UltraBay ===
UltraBay{{footnote|1}} is IBM's name for the swapable drive slot. With IBMs words: "The ThinkPad UltraBay, also standard with the system, is an intelligent bay that switches its pinout signals to allow the installation of standard and optional features in what would normally be just the FDD bay." Introduced back in the times of the 750 ThinkPads, this technology has gone through redesigns with almost every new generation of ThinkPad models, possibly leading to some confusion that is hopefully cleared up here. The following table gives an overview of the different UltraBay types, in which models they occurred and what drives are available for them.
Note that the optical drive bay in G series ThinkPads is not an UltraBay in that the drives are fixed and not removable.

On the media side different UltraBays relate to the form factor of the drives they accept, e.g early A, T and X series models can accept UltraBay devices up to 12.5mm in thickness, whereas current T and X series machines are limited to devices no more than 9.5mm thick.
</div>
|}
{| border="1" cellspacing="0" cellpadding="2"
|+Overview over UltraBay types and available devices
! width=140px|UltraBay Type !! featured in !! available drives (see [[UltraBay Devices]] for details)

|-
| [[Image:Icon20_ultrabay.png]] UltraBay || {{355}}, {{355C}}, {{355Cs}}, {{360}}, {{360C}}, {{360Cs}}, {{360P}}, {{360CE}}, {{360CSE}}, {{360PE}}, {{370C}}, {{750}}, {{750C}}, {{750Cs}}, {{750P}}, {{755C}}, {{755CE}}, {{755Cs}}, {{755CSE}}, {{755CV}}, {{755CX}}, {{760C}}, {{760L}}, {{760E}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabay.png]] UltraBay Thick|| {{755CD}}, {{755CDV}}, {{760CD}}, {{760E}}, {{760ED}}, {{760EL}}, {{760ELD}}, {{760LD}}, {{760XD}}, {{760XL}}, {{765D}}, {{765L}}, [[SelectaDock I]], [[SelectaDock II]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], 2.88 MB diskette, PCMCIA Cartridge, IBM Wireless Modem ARDIS, IBM Wireless Modem
|-
| [[Image:Icon20_ultrabayii.png]] UltraBay II || {{770}}, {{770E}}, {{770ED}}, {{770X}}, {{770Z}}, [[SelectaDock III]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayfx.png]] UltraBay FX|| {{390}}, {{390E}}, {{390X}}, {{i1720}}, {{i1721}} || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultraslimbay.png]] UltraslimBay || {{600}}, {{600E}}, {{600X}}, [[UltraBase]], [[Portable Drive Bay]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 || {{A20m}}, {{A20p}}, {{A21e}}, {{A21m}}, {{A21p}}, {{A22e}}, {{A22m}}, {{A22p}}, {{A30}}, {{T20}}, {{T21}}, {{T22}}, {{T23}}, [[ThinkPad Dock|Dock]], [[ThinkPad Dock II|Dock II]], [[UltraBase X2]], [[Portable Drive Bay 2000]]|| [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayplus.png]] UltraBay Plus || {{A30}}, {{A30p}}, {{A31}}, {{A31p}}, {{R30}}, {{R31}}, {{R32}}, {{R40}}, {{T23}}, {{T30}}, [[UltraBase X3]] || [[Image:Icon20_floppy.png|Floppy Drive]] [[Image:Icon20_ls120.png|SuperDisk LS-120 Drive]] [[Image:Icon20_ls240.png|SuperDisk LS-240 Drive]] [[Image:Icon20_zip100.png|100MB Zip Drive]] [[Image:Icon20_zip250.png|250MB Zip Drive]] [[Image:Icon20_cdrom.png|CD-ROM Drive]] [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_cdrw.png|CD-RW Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]], WorkPad Cradle, Numpad
|-
| [[Image:Icon20_ultrabayslim.png]] UltraBay Slim || {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{Z60t}}, [[UltraBase X4]], [[UltraBase X6]], [[ThinkPad X4 Dock]] || [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
| [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced || {{R50}}, {{R50p}}, {{R51}}, {{R52}}, {{Z60m}} [[ ThinkPad Advanced Dock]]|| [[Image:Icon20_dvd.png|DVD-ROM Drive]] [[Image:Icon20_combo.png|CD-RW/DVD-ROM Combo Drive]] [[Image:Icon20_multiburner.png|DVD Multi-Burner Drive]] [[Image:Icon20_hdd.png|Harddisk Drive Adapter]] [[Image:Icon20_battery.png|Battery]]
|-
|}

{| border="1" cellspacing="0" cellpadding="2" style="text-align:center;"
|+Compatibility Matrix (read columns as slots with rows as devices that are compatible)
! Slots<hr />Devices!! [[Image:Icon20_ultrabay.png]] UltraBay   !! [[Image:Icon20_ultrabay.png]] UltraBay Thick !! [[Image:Icon20_ultrabayii.png]] UltraBay II !! [[Image:Icon20_ultrabayfx.png]] UltraBay FX !! [[Image:Icon20_ultraslimbay.png]] UltraslimBay   !! [[Image:Icon20_ultrabay2000.png]] UltraBay 2000 !! [[Image:Icon20_ultrabayplus.png]] UltraBay Plus !! [[Image:Icon20_ultrabayslim.png]] UltraBay Slim !! [[Image:Icon20_ultrabayenh.png]] UltraBay Enhanced
|-
|'''UltraBay''' || yes || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay Thick''' || - || yes || [[Ultrabay Drive Adapter for Ultrabay II|Adapter]] || - || - || - || - || - || -
|-
|'''UltraBay II''' || - || - || yes || - || - || - || - || - || -
|-
|'''UltraBay FX''' || - || - || - || yes || - || - || - || - || -
|-
|'''UltraslimBay''' || - || - || - || - || yes || - || - || - || -
|-
|'''UltraBay 2000''' || - || - || - || - || - || yes || yes || - || -
|-
|'''UltraBay Plus''' || - || - || - || - || - || - || yes || - || -
|-
|'''UltraBay Slim''' || - || - || - || - || - || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Slim Drive Adapter for Ultrabay 2000|Adapter]] || yes || yes
|-
|'''UltraBay Enhanced''' || - || - || - || - || - || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || [[Ultrabay Enhanced Drive Adapter for Ultrabay 2000|Adapter]] || - || yes
|}

===Characteristics===
*UltraBay: no hot swapping
*UltraBay Thick: Thicker version of UltraBay to support CD-ROM drive
*UltraBay II: supports hot swapping, blending has cut out edge on the right
*UltraBay FX: the combined [[Floppy]] drive and CD-ROM, DVD or CDRW mechanism found in the {{390}}/{{390E}}/{{390X}}
*UltraSlimBay: supports hot swapping; Frame, rectangle like blending
*UltraBay 2000: supports hot swapping; Frame, blending has cut out egde on the right
*UltraBay Plus: same as UltraBay 2000, but can take the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46440 UltraBay Plus Device Carrier] which in turn can hold the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46440 UltraBay Plus WorkPad Cradle] or the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-46440 UltraBay Plus Numeric Keypad]
*UltraBay Slim: supports hot swapping; notably thinner than UltraBay 2000, cut out right edge in blending
*UltraBay Enhanced: supports hot swapping; slightly thicker than UltraBay Slim, but accepts UltraBay Slim devices

==Linux Support==
The pinout switching is done by the BIOS and hardware, so that it is completely transparent to the operating system.
*Floppy drives are supported by the standard floppy driver.
*ZIP drive support is possible through the ide-disk driver.
*IDE hard disks and optical drives are supported by the IDE or <tt>ata_piix</tt> driver in the linux kernel. SCSI emulation via ide-scsi is possible.
*Batteries are automatically handled by the hardware (and can be controlled by using [[tp_smapi]]).
*UltraBay Plus devices should be handled by the USB subsystem, but if the devices are is not known.

===Hotswapping===
Hotswapping is supposed to be supported as well, using hdparm to (un)register devices.
People reported varying success with this (see below).

The IBM-ACPI kernel module (http://ibm-acpi.sourceforge.net) has an eject function ({{cmdroot|echo eject > /proc/acpi/ibm/bay}}). This only manages the ACPI calls to power down the device and the bay. It does not actually unregister the device from the IDE driver. {{cmdroot|cat /proc/acpi/ibm/bay}} shows "unoccupied" unless an IDE device is present, but the eject function still works and should still be used.

To unregister the device, try using the Debian hotswap package. This also allows the drive to be swapped as a normal user by default, which is useful. You should use hotswap to unregister the device and then "echo eject > /proc/acpi/ibm/bay". This was reported to work on a ThinkPad {{T23}} (kernel 2.6.14.2) and {{T42}} (kernel 2.6.13), but fails on a ThinkPad {{T43}} (kernel 2.6.14.3).

Only IDE devices (HDD's, optical drives, zip drives) require special treatment - batteries, floppies and other devices can just be pulled from the bay, provided they are not mounted or in use at the time. However, you should still power them down using the IBM-ACPI eject function first.

==External Sources==
*[http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50366 IBMs page on using a second hard drive adapter in the Ultrabay 2000 slot under Linux]

{{footnotes|
#IBM originally used the spelling UltraBay with a capital B and later switched to Ultrabay with a lower b. We are sticking with the capital B here.
}}

[[Category:Glossary]]

How to use UltraBay batteries

2006-01-20T18:00:15Z

SystemParadox: /* Charging and discharging */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charges/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

It seems that you don't have to completely remove the battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS stops discharging it and moves onto the main battery. Charging not tested. Test machine: T23. May not work on other models.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see above).
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-20T17:58:43Z

SystemParadox: /* Battery hot-swapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charges/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

It seems that you don't have to completely remove the battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS stops discharging it and moves onto the main battery. Charging not tested. Test machine: T23. May not work on other models.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low.
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.

How to use UltraBay batteries

2006-01-20T17:54:28Z

SystemParadox: /* Battery hot-swapping */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
ThinkPad laptops only charges/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.
|}

===Battery hot-swapping===
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).

You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device.

===Charging and discharging===
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:

* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low.
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].

===Reading the battery status under Linux===

====Using APM====

The second battery is correctly detected by the APM subsystem (if activated).

====Using ACPI====

The second battery is correctly detected by the ACPI subsystem (if activated). 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.

For BAT1 all the states go to 0, critical, etc. .

{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/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), {{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 <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.

====Using <tt>tp_smapi</tt>====

Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). 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, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.