ThinkWiki - User contributions [en]

How to hotswap Ultrabay devices

2008-08-26T11:33:18Z

Zin: /* Scripts for hotswapping */

The following discusses hotswap (AKA "hotplug") of devices in the [[UltraBay]].

==Which driver?==
Since this may be confusing for SATA thinkpad owners, which are likely all the same for now, you have two busses and drivers: one SATA bus which works with the AHCI driver and one IDE bus for the ultrabay for which you should pick ata_piix (not piix/CONFIG_BLK_DEV_PIIX). See below for hotswapping.

==Choosing the right driver: new style <tt>ata_piix</tt> vs old style <tt>piix/ide-disk</tt>==
For ICH5,6,7,8, systems, whether you have an older IDE only thinkpad, or a newer thinkpad like the T/Z61p, there is one SATA bus for the system hard drive and an IDE bus for the ultrabay (even if your ultrabay happens to have a SATA drive, as it'll be seen as an IDE device), you'll have two drivers to chose from for your ultrabay: the old IDE/piix+ide-disk driver, and the newer PATA (=IDE) support of the newer ata_piix driver. 
<tt>piix+ide-disk</tt> are part of the old original IDE driver and your ultrabay device will show up as <tt>/dev/hda</tt>. <tt>ata-piix</tt> is the new SATA/PATA (=IDE) driver that will cause your ultrabay Hard Drive to show up as <tt>/dev/sda</tt> and your CD-Rom as <tt>/dev/sr0</tt>

The two things to know are: 1) you want to use ata_piix and 2) if you build piix in (CONFIG_BLK_DEV_PIIX enabled), or load it as a module, it'll take over the IDE bus and prevent ATA_PIIX from seeing your ultrabay. You don't want that.

The longer details are: 
You don't want the piix+ide-disk combo because even as modules, you will not be able to unload piix to reset the bus if there are issues swapping devices (with ata_piix, even if you forget to unregister a drive before removing it, you can unload the module and reload it to reset the bus after the fact if you have a newer thinkpad with a separate AHCI/SATA bus for the boot drive).

As for hotswap, with piix+ide-disk, you can read the section below, but after more than one day of trying on 2.6.22.15 (as piix+ide-disk was taking over my IDE bus, and stopping me from using ata_piix before I removed it), I was not able to get hotswapping to work with piix+ide-disk (lt_hotswap would not even build on 2.6.22.15).

hotswap just works with ata_pixx on 2.6.22, and reportedly with anything newer than 2.6.18, so you want to get rid of piix+ide-disk.
There are several ways to do that:
* if piix is built in your kernel (CONFIG_BLK_DEV_PIIX):
** rebuild your kernel with CONFIG_BLK_DEV_PIIX turned off.
** if you don't want to rebuild your kernel, try disabling the IDE bus grabbing by that driver with <tt>ide0=noprobe hda=noprobe hdb=noprobe</tt> in your grub/lilo config (adjust the drive letters as appropriate, but note that this did not work for me on 2.6.22.15: the drive didn't show up on the piix bus, but it didn't show up on the ata_piix bus either).
* if piix is built in as a module
** you can move out the module in {{path|/lib/modules/ver/kernel/drivers/ide/pci/piix.ko}} and reboot.
** or build a new kernel, again with CONFIG_BLK_DEV_PIIX turned off.
** or add <tt>options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe"</tt> to your modprobe.conf is supposed to work too (but didn't work on 2.6.22.15, see comment above)

Then, continue this document to see how to do hotswap with ata_piix (if you are lucky enough to have a newer SATA thinkpad where the ata_piix driver only runs the ultrabay, and you have a separate bus and ahci driver for your main drive, it is recommended to have ata_piix as a module (<tt>CONFIG_ATA_PIIX=m</tt>) so that you can unload/reload it if your bus gets in a bad state after a failed hotswap)

==When using the <tt>ata_piix</tt> driver==
The following applies when using the <tt>ata_piix</tt> driver, which is necessary for many recent ThinkPad models that use an [[Intel ICH6-M]] controller. See also [[Problems with SATA and Linux]].

Mainline kernels before 2.6.18 cannot reliably recognize newly (re-)inserted UltraBay drives without a reboot. There are experimental hotplug patches against pre-2.6.18 mainline kernels [http://home-tj.org/wiki/index.php/Libata-tj-stable here].

* Available hotplug patches
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.16.16-20060512.tar.bz2 Patch tarball against 2.6.16.16] ([http://lwn.net/Articles/183407/ Announce])
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17-20060625-1.tar.bz2 Patch tarball against 2.6.17/2.6.17.1] ([http://article.gmane.org/gmane.linux.ide/11598 Announce])
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17.4-20060710.tar.bz2 Patch tarball against 2.6.17.4]
**[http://whoopie.gmxhome.de/linux/patches/2.6.17.14-tj/00-libata-tj-2.6.17.4-20060710.patch Patch against 2.6.17.14]

* Confirmed to work on the following laptops, with bus the following ID
**ThinkPad {{T30}}
**ThinkPad {{T43}}, {{T43p}}
**ThinkPad {{R52}}
**ThinkPad {{T60}} ID=4
**ThinkPad {{T61}} ID=0
**ThinkPad {{Z61p}} ID=4 (0-3:ahci, 5-6: ata_piix)
ID will typically be 1 if you only have an IDE bus (0 is boot drive, 1 is ultrabay), and it'll be 4 if you have a SATA bus your system boots from (ID 0-3) and an IDE bus for your ultrabay (ID 4-5). 
Note that even on a given laptop model the ID can vary depending on whether your kernel has drivers that configure your boot drive is using the old style IDE driver (which doesn't add IDs before your ultrabay), or whether your boot drive is using the new style driver (which adds IDs before your ultrabay)

Hotplug just works with kernels newer than 2.6.18 ( or older kernels that were patched to support <tt>ata_piix</tt> hotplug (don't try it otherwise!)) 
First, it is recommended you find the right SCSI ID for your drive to hotswap and unregister it before removing it (this works with all recent mainline kernels):
{{cmdroot|echo 1 > /sys/class/scsi_device/$ID:0:0:0/device/delete}}
{{cmdroot|echo eject > /proc/acpi/ibm/bay}}
The drive can now be ejected (without this, your IDE bus may complain if you just yank a drive, but you can usually recover by unloading/reloading the ata_piix module on a SATA laptop if your main drive is not on the ata_piix bus)

You can then issue the following after inserting an UltraBay drive to rescan the port:
{{cmdroot|echo 0 0 0 > /sys/class/scsi_host/host$ID/scan}}
The inserted drive should now be recognized by the kernel, and appropriate {{path|/dev/*}} entries created automatically (e.g., by <tt>udev</tt>).

Ted T'so has also written this hotswap patch, which may or may not be needed for you, see [http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg04716.html hotswap patch] and report back

===Scripts for hotswapping===

The following scripts and [[acpid]] daemon configuration files do the following:
* Automatically unmounts the relevant filesystems and power off the UltraBay when the UltraBay eject lever is released. Screams if some filesystem can't be unmounted.
* Rescans the UltraBay port when then UltraBay eject lever is pushed back in.

They assumes you're using the <tt>ata_piix</tt> driver with an appropriate kernel (see above).

Create {{path|/usr/local/sbin/ultrabay_insert}} with permissions 755:
<pre>
#!/bin/bash
echo 12 > /proc/acpi/ibm/beep
sync
echo 0 0 0 > /sys/class/scsi_host/host1/scan
</pre>

Create {{path|/usr/local/sbin/ultrabay_eject}} with permissions 755:
<pre>
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

# Umount the filesystem(s) backed by the given major:minor device(s)
unmount_rdev() { perl - "$@" <<'EOPERL' # let's do it in Perl
for $major_minor (@ARGV) {
$major_minor =~ m/^(\d+):(\d+)$/ or die;
push(@tgt_rdevs, ($1<<8)|$2);
}
# Sort by reverse length of mount point, to unmount sub-directories first
open MOUNTS,"</proc/mounts" or die "$!";
@mounts=sort { length($b->[1]) <=> length($a->[1]) } map { [ split ] } <MOUNTS>;
close MOUNTS;
foreach $m (@mounts) {
($dev,$dir)=@$m;
next unless -b $dev; $rdev=(stat($dev))[6];
next unless grep($_==$rdev, @tgt_rdevs);
system("umount","-v","$dir")==0 or $bad=1;
}
exit 1 if $bad;
EOPERL
}

# Get the UltraBay's /dev/foo block device node
ultrabay_dev_node() {
UDEV_PATH="`readlink -e "$ULTRABAY_SYSDIR/block:"*`" || return 1
UDEV_NAME="`udevinfo -q name -p $UDEV_PATH`" || return 1
echo /dev/$UDEV_NAME
}

if [ -d $ULTRABAY_SYSDIR ]; then
sync
# Unmount filesystems backed by this device
unmount_rdev `cat $ULTRABAY_SYSDIR/block\:*/dev \
$ULTRABAY_SYSDIR/block\:*/*/dev` \
|| {
echo 10 > /proc/acpi/ibm/beep; # error tone
exit 1;
}
sync
# Nicely power off the device
DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE
# Let HAL+KDE notice the unmount and let the disk spin down
sleep 0.5
# Unregister this SCSI device:
sync
echo 1 > $ULTRABAY_SYSDIR/delete
fi
sync
# Turn off power to the UltraBay:
if [ -d /sys/devices/platform/bay.0 ]; then
echo 1 > /sys/devices/platform/bay.0/eject
elif [ -e /proc/acpi/ibm/bay ]; then
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
echo 12 > /proc/acpi/ibm/beep
</pre>

Use the modified version below if the above doesn't work for you (for kernels 2.6.25+ due to "ULTRABAY_SYSDIR/block\:*/dev" path change). It was tested on a Thinkpad X41 with Fedora 9 and kernel 2.6.25.11:

<pre>
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

# Umount the filesystem(s) backed by the given major:minor device(s)
unmount_rdev() { perl - "$@" <<'EOPERL' # let's do it in Perl
for $major_minor (@ARGV) {
$major_minor =~ m/^(\d+):(\d+)$/ or die;
push(@tgt_rdevs, ($1<<8)|$2);
}
# Sort by reverse length of mount point, to unmount sub-directories first
open MOUNTS,"</proc/mounts" or die "$!";
@mounts=sort { length($b->[1]) <=> length($a->[1]) } map { [ split ] } <MOUNTS>;
close MOUNTS;
foreach $m (@mounts) {
($dev,$dir)=@$m;
next unless -b $dev; $rdev=(stat($dev))[6];
next unless grep($_==$rdev, @tgt_rdevs);
system("umount","-v","$dir")==0 or $bad=1;
}
exit 1 if $bad;
EOPERL
}

# Get the UltraBay's /dev/foo block device node
ultrabay_dev_node() {
UDEV_PATH="`readlink -e "$ULTRABAY_SYSDIR/block/"*`" || return 1
UDEV_NAME="`udevinfo -q name -p $UDEV_PATH`" || return 1
echo /dev/$UDEV_NAME
}

if [ -d $ULTRABAY_SYSDIR ]; then
sync
# Unmount filesystems backed by this device
unmount_rdev `cat $ULTRABAY_SYSDIR/block/*/dev \
$ULTRABAY_SYSDIR/block/*/*/dev` \
|| {
echo 10 > /proc/acpi/ibm/beep; # error tone
exit 1;
}
sync
# Nicely power off the device
DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE
# Let HAL+KDE notice the unmount and let the disk spin down
sleep 0.5
# Unregister this SCSI device:
sync
echo 1 > $ULTRABAY_SYSDIR/delete
fi

# We really need a 3 sec pause here otherwise the system will freeze..
sleep 3

# Turn off power to the UltraBay:
if [ -d /sys/devices/platform/bay.0 ]; then
echo 1 > /sys/devices/platform/bay.0/eject
elif [ -e /proc/acpi/ibm/bay ]; then
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
echo 12 > /proc/acpi/ibm/beep
</pre>

Create {{path|/etc/acpi/events/ultrabay-insert}}:
<pre>
event=ibm/bay MSTR 00000001 00000000
action=/usr/local/sbin/ultrabay_insert
</pre>

Create {{path|/etc/acpi/events/ultrabay-eject}}:
<pre>
event=ibm/bay MSTR 00000003 00000000
action=/usr/local/sbin/ultrabay_eject
</pre>

Restart <tt>acpid</tt>.

===using the generic bay driver and udev===

Starting from kernel 2.6.23-rc3, it's possible to use the generic <tt>bay</tt> driver in combination with udev to hotswap. Please check if CONFIG_ACPI_BAY is enabled (module or built-in) in your kernel configuration.

Create {{path|/etc/udev/rules.d/ibm-ultrabay.rules}}:
<pre>
ENV{BAY_EVENT}=="3", KERNEL=="bay.0", ACTION=="change", SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_eject"
ENV{BAY_EVENT}=="1", KERNEL=="bay.0", ACTION=="change", SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_insert"
</pre>

===using libata-acpi and udev===

Starting from kernel 2.6.26-rc5, it's possible to use <tt>libata-acpi</tt> in combination with udev to hotswap. Please check if CONFIG_ATA_ACPI is enabled in your kernel configuration.

For 2.6.25, you need two patches which can be easily backported ([http://article.gmane.org/gmane.linux.acpi.devel/31159],[http://article.gmane.org/gmane.linux.acpi.devel/31369]).

Create {{path|/etc/udev/rules.d/ibm-ultrabay.rules}}:
<pre>
ENV{BAY_EVENT}=="3", ACTION=="change", SUBSYSTEM=="scsi", RUN+="/usr/local/sbin/ultrabay_eject"
</pre>

===Model-specific notes===
See the table above for a list of ata_piix supported laptops and the bus ID to use.

===HAL support===

{{NOTE| Starting from HAL 0.5.11, you need to replace "storage.physical_device" with "info.parent".}}

Many programs, KDE included, rely on [[HAL]] to get notifications and information about device hotplugging. You need to tell HAL that devices connected the UltraBay port are hotpluggable. To do so, create the file {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as follows:
<pre>
<?xml version="1.0" encoding="UTF-8"?> 

<deviceinfo version="0.2">
<device>


<match key="storage.bus" string="scsi">
<match key="storage.physical_device" string="/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0">
<merge key="storage.hotpluggable" type="bool">true</merge>
</match>
</match>

</device>
</deviceinfo>
</pre>

The string "8086_2653" may need to be changed to match your ThinkPad model; see below.

====Details====

By default, HAL doesn't know that UltraBay devices are hotpluggable:

# PHYSDEV=/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0
# UDI=`hal-find-by-property --key storage.physical_device --string $PHYSDEV` || echo Failed
# hal-get-property --udi $UDI --key block.device
/dev/sdb
# hal-get-property --udi $UDI --key storage.hotpluggable
false

After creating {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as above and re-plugging the device, it will get marked correctly:

# PHYSDEV=/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0
# UDI=`hal-find-by-property --key storage.physical_device --string $PHYSDEV` || echo Failed
# hal-get-property --udi $UDI --key block.device
/dev/sdb
# hal-get-property --udi $UDI --key storage.hotpluggable
true

The string "8086_2653" gives the PCI ID of the [[Intel 82801FBM]] southbridge. If your model has a different southbridge, or the UltraBay is attached to a different port, then you can find the appropriate <tt>storage.physical_device</tt> value by finding out the block device of the currently running UltraBay device (<tt>/dev/sdb</tt> in the following example) and then running:

# DEVICE=/dev/sdb
# UDI=`hal-find-by-property --key block.device --string $DEVICE` || echo Failed
# hal-get-property --udi $UDI --key storage.physical_device
/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0

If you have a different <tt>storage.physical_device</tt> value, please report your findings.

{| border=1
|+ Known South Bridge PCI IDs
! ID !! ThinkPad model !! South Bridge chip
|-
| 8086_248a || 2366-83U (T30) || Intel 82801CAM IDE U100 (rev 2)
|-
| 8086_2653 || 2525FAG (X41), ? (T43) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40), 2373KXU (T42p) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 Family)
|-
| 8086_2850 || T61p || Intel 82801H (ICH8 Family)
|}

==When using the <tt>ide-disk</tt> driver==
The following applies if you use the <tt>ide-disk</tt> driver for the UltraBay device. 
Note that essentially, you shouldn't be using this driver, and use ata_piix instead unless you're running an older kernel where ata_piix won't work for you

Hotswapping is supposed to be supported as well, using either hdparm/[http://packages.debian.org/unstable/admin/hotswap Debian hotswap] or [[lt_hotswap]] to (un)register IDE devices. The latter is the recommended method with kernels from 2.6, since it will leave DMA working. However, for recent models (R52, T43, X41, Z60 and later) no method is known to work while maintaining DMA support; see [[Problems with SATA and Linux]].

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.

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, you can either use the [http://packages.debian.org/unstable/admin/hotswap Debian hotswap] package, or [[lt_hotswap]]. Note that lt_hotswap doesn't seem to even build on recent (at 2.6.22 or newer, although it probably broke before 2.6.22) and on newer kernels, you should not build/load the old IDE PIIX (CONFIG_BLK_DEV_PIIX) and use the natively hotswapping ata_piix (CONFIG_ATA_PIIX) as explained on the top of this page.

[http://packages.debian.org/unstable/admin/hotswap Debian hotswap] also allows the drive to be swapped as a normal user by default, which is useful. You should use <tt>hotswap</tt> to unregister the device and then {{cmdroot|echo eject > /proc/acpi/ibm/bay}}. However, if you use this method on a 2.6 kernel, you will lose DMA support for the reinserted drive. This is due to kernel issues. This method 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).

[[lt_hotswap]] is now the recommended method to un- and reregister the IDE device. It installs as a kernel module and has support for automatically unregistering (if loaded with the auto_eject=1 option) the device when the eject event is generated by [[ibm-acpi]]. It will leave DMA support intact. It has supported to work on a ThinkPad {{T22}} and {{T40}} and should work with many other models (but not recent models which require the <tt>ata_piix</tt> driver for disk DMA support). With the [[lt_hotswap]] kernel module loaded, run: {{cmdroot|modprobe -r ide_cd && modprobe -r cdrom && echo "MSTR eject" > /proc/acpi/lths}}

===HAL support===

HAL support also can also be configured To do so, create the file {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as follows:
<pre>
<?xml version="1.0" encoding="UTF-8"?> 

<deviceinfo version="0.2">
<device>


<match key="storage.bus" string="ide">
<match key="storage.physical_device" string="/org/freedesktop/Hal/devices/pci_8086_24ca_ide_1_0">
<merge key="storage.hotpluggable" type="bool">true</merge>
</match>
</match>

</device>
</deviceinfo>
</pre>
For more details see HAL section for ata driver.

==Other comments==

If you are hot-swapping a hard disk on a disk tray, make sure the disk does not have a password set, otherwise it will not be recognized on reinsertion.

[[Category:Scripts]]
[[Category:HOWTOs]]

How to hotswap Ultrabay devices

2008-08-26T11:27:28Z

Zin: /* Scripts for hotswapping */

The following discusses hotswap (AKA "hotplug") of devices in the [[UltraBay]].

==Which driver?==
Since this may be confusing for SATA thinkpad owners, which are likely all the same for now, you have two busses and drivers: one SATA bus which works with the AHCI driver and one IDE bus for the ultrabay for which you should pick ata_piix (not piix/CONFIG_BLK_DEV_PIIX). See below for hotswapping.

==Choosing the right driver: new style <tt>ata_piix</tt> vs old style <tt>piix/ide-disk</tt>==
For ICH5,6,7,8, systems, whether you have an older IDE only thinkpad, or a newer thinkpad like the T/Z61p, there is one SATA bus for the system hard drive and an IDE bus for the ultrabay (even if your ultrabay happens to have a SATA drive, as it'll be seen as an IDE device), you'll have two drivers to chose from for your ultrabay: the old IDE/piix+ide-disk driver, and the newer PATA (=IDE) support of the newer ata_piix driver. 
<tt>piix+ide-disk</tt> are part of the old original IDE driver and your ultrabay device will show up as <tt>/dev/hda</tt>. <tt>ata-piix</tt> is the new SATA/PATA (=IDE) driver that will cause your ultrabay Hard Drive to show up as <tt>/dev/sda</tt> and your CD-Rom as <tt>/dev/sr0</tt>

The two things to know are: 1) you want to use ata_piix and 2) if you build piix in (CONFIG_BLK_DEV_PIIX enabled), or load it as a module, it'll take over the IDE bus and prevent ATA_PIIX from seeing your ultrabay. You don't want that.

The longer details are: 
You don't want the piix+ide-disk combo because even as modules, you will not be able to unload piix to reset the bus if there are issues swapping devices (with ata_piix, even if you forget to unregister a drive before removing it, you can unload the module and reload it to reset the bus after the fact if you have a newer thinkpad with a separate AHCI/SATA bus for the boot drive).

As for hotswap, with piix+ide-disk, you can read the section below, but after more than one day of trying on 2.6.22.15 (as piix+ide-disk was taking over my IDE bus, and stopping me from using ata_piix before I removed it), I was not able to get hotswapping to work with piix+ide-disk (lt_hotswap would not even build on 2.6.22.15).

hotswap just works with ata_pixx on 2.6.22, and reportedly with anything newer than 2.6.18, so you want to get rid of piix+ide-disk.
There are several ways to do that:
* if piix is built in your kernel (CONFIG_BLK_DEV_PIIX):
** rebuild your kernel with CONFIG_BLK_DEV_PIIX turned off.
** if you don't want to rebuild your kernel, try disabling the IDE bus grabbing by that driver with <tt>ide0=noprobe hda=noprobe hdb=noprobe</tt> in your grub/lilo config (adjust the drive letters as appropriate, but note that this did not work for me on 2.6.22.15: the drive didn't show up on the piix bus, but it didn't show up on the ata_piix bus either).
* if piix is built in as a module
** you can move out the module in {{path|/lib/modules/ver/kernel/drivers/ide/pci/piix.ko}} and reboot.
** or build a new kernel, again with CONFIG_BLK_DEV_PIIX turned off.
** or add <tt>options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe"</tt> to your modprobe.conf is supposed to work too (but didn't work on 2.6.22.15, see comment above)

Then, continue this document to see how to do hotswap with ata_piix (if you are lucky enough to have a newer SATA thinkpad where the ata_piix driver only runs the ultrabay, and you have a separate bus and ahci driver for your main drive, it is recommended to have ata_piix as a module (<tt>CONFIG_ATA_PIIX=m</tt>) so that you can unload/reload it if your bus gets in a bad state after a failed hotswap)

==When using the <tt>ata_piix</tt> driver==
The following applies when using the <tt>ata_piix</tt> driver, which is necessary for many recent ThinkPad models that use an [[Intel ICH6-M]] controller. See also [[Problems with SATA and Linux]].

Mainline kernels before 2.6.18 cannot reliably recognize newly (re-)inserted UltraBay drives without a reboot. There are experimental hotplug patches against pre-2.6.18 mainline kernels [http://home-tj.org/wiki/index.php/Libata-tj-stable here].

* Available hotplug patches
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.16.16-20060512.tar.bz2 Patch tarball against 2.6.16.16] ([http://lwn.net/Articles/183407/ Announce])
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17-20060625-1.tar.bz2 Patch tarball against 2.6.17/2.6.17.1] ([http://article.gmane.org/gmane.linux.ide/11598 Announce])
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17.4-20060710.tar.bz2 Patch tarball against 2.6.17.4]
**[http://whoopie.gmxhome.de/linux/patches/2.6.17.14-tj/00-libata-tj-2.6.17.4-20060710.patch Patch against 2.6.17.14]

* Confirmed to work on the following laptops, with bus the following ID
**ThinkPad {{T30}}
**ThinkPad {{T43}}, {{T43p}}
**ThinkPad {{R52}}
**ThinkPad {{T60}} ID=4
**ThinkPad {{T61}} ID=0
**ThinkPad {{Z61p}} ID=4 (0-3:ahci, 5-6: ata_piix)
ID will typically be 1 if you only have an IDE bus (0 is boot drive, 1 is ultrabay), and it'll be 4 if you have a SATA bus your system boots from (ID 0-3) and an IDE bus for your ultrabay (ID 4-5). 
Note that even on a given laptop model the ID can vary depending on whether your kernel has drivers that configure your boot drive is using the old style IDE driver (which doesn't add IDs before your ultrabay), or whether your boot drive is using the new style driver (which adds IDs before your ultrabay)

Hotplug just works with kernels newer than 2.6.18 ( or older kernels that were patched to support <tt>ata_piix</tt> hotplug (don't try it otherwise!)) 
First, it is recommended you find the right SCSI ID for your drive to hotswap and unregister it before removing it (this works with all recent mainline kernels):
{{cmdroot|echo 1 > /sys/class/scsi_device/$ID:0:0:0/device/delete}}
{{cmdroot|echo eject > /proc/acpi/ibm/bay}}
The drive can now be ejected (without this, your IDE bus may complain if you just yank a drive, but you can usually recover by unloading/reloading the ata_piix module on a SATA laptop if your main drive is not on the ata_piix bus)

You can then issue the following after inserting an UltraBay drive to rescan the port:
{{cmdroot|echo 0 0 0 > /sys/class/scsi_host/host$ID/scan}}
The inserted drive should now be recognized by the kernel, and appropriate {{path|/dev/*}} entries created automatically (e.g., by <tt>udev</tt>).

Ted T'so has also written this hotswap patch, which may or may not be needed for you, see [http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg04716.html hotswap patch] and report back

===Scripts for hotswapping===

The following scripts and [[acpid]] daemon configuration files do the following:
* Automatically unmounts the relevant filesystems and power off the UltraBay when the UltraBay eject lever is released. Screams if some filesystem can't be unmounted.
* Rescans the UltraBay port when then UltraBay eject lever is pushed back in.

They assumes you're using the <tt>ata_piix</tt> driver with an appropriate kernel (see above).

Create {{path|/usr/local/sbin/ultrabay_insert}} with permissions 755:
<pre>
#!/bin/bash
echo 12 > /proc/acpi/ibm/beep
sync
echo 0 0 0 > /sys/class/scsi_host/host1/scan
</pre>

Create {{path|/usr/local/sbin/ultrabay_eject}} with permissions 755:
<pre>
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

# Umount the filesystem(s) backed by the given major:minor device(s)
unmount_rdev() { perl - "$@" <<'EOPERL' # let's do it in Perl
for $major_minor (@ARGV) {
$major_minor =~ m/^(\d+):(\d+)$/ or die;
push(@tgt_rdevs, ($1<<8)|$2);
}
# Sort by reverse length of mount point, to unmount sub-directories first
open MOUNTS,"</proc/mounts" or die "$!";
@mounts=sort { length($b->[1]) <=> length($a->[1]) } map { [ split ] } <MOUNTS>;
close MOUNTS;
foreach $m (@mounts) {
($dev,$dir)=@$m;
next unless -b $dev; $rdev=(stat($dev))[6];
next unless grep($_==$rdev, @tgt_rdevs);
system("umount","-v","$dir")==0 or $bad=1;
}
exit 1 if $bad;
EOPERL
}

# Get the UltraBay's /dev/foo block device node
ultrabay_dev_node() {
UDEV_PATH="`readlink -e "$ULTRABAY_SYSDIR/block:"*`" || return 1
UDEV_NAME="`udevinfo -q name -p $UDEV_PATH`" || return 1
echo /dev/$UDEV_NAME
}

if [ -d $ULTRABAY_SYSDIR ]; then
sync
# Unmount filesystems backed by this device
unmount_rdev `cat $ULTRABAY_SYSDIR/block\:*/dev \
$ULTRABAY_SYSDIR/block\:*/*/dev` \
|| {
echo 10 > /proc/acpi/ibm/beep; # error tone
exit 1;
}
sync
# Nicely power off the device
DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE
# Let HAL+KDE notice the unmount and let the disk spin down
sleep 0.5
# Unregister this SCSI device:
sync
echo 1 > $ULTRABAY_SYSDIR/delete
fi
sync
# Turn off power to the UltraBay:
if [ -d /sys/devices/platform/bay.0 ]; then
echo 1 > /sys/devices/platform/bay.0/eject
elif [ -e /proc/acpi/ibm/bay ]; then
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
echo 12 > /proc/acpi/ibm/beep
</pre>

Use the modified version below if the above doesn't work for you (for kernels 2.6.25+ due to ULTRABAY_SYSDIR/block\:*/dev path change). It was tested on a Thinkpad X41 with Fedora 9 and kernel 2.6.25.11:

<pre>
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

# Umount the filesystem(s) backed by the given major:minor device(s)
unmount_rdev() { perl - "$@" <<'EOPERL' # let's do it in Perl
for $major_minor (@ARGV) {
$major_minor =~ m/^(\d+):(\d+)$/ or die;
push(@tgt_rdevs, ($1<<8)|$2);
}
# Sort by reverse length of mount point, to unmount sub-directories first
open MOUNTS,"</proc/mounts" or die "$!";
@mounts=sort { length($b->[1]) <=> length($a->[1]) } map { [ split ] } <MOUNTS>;
close MOUNTS;
foreach $m (@mounts) {
($dev,$dir)=@$m;
next unless -b $dev; $rdev=(stat($dev))[6];
next unless grep($_==$rdev, @tgt_rdevs);
system("umount","-v","$dir")==0 or $bad=1;
}
exit 1 if $bad;
EOPERL
}

# Get the UltraBay's /dev/foo block device node
ultrabay_dev_node() {
UDEV_PATH="`readlink -e "$ULTRABAY_SYSDIR/block/"*`" || return 1
UDEV_NAME="`udevinfo -q name -p $UDEV_PATH`" || return 1
echo /dev/$UDEV_NAME
}

if [ -d $ULTRABAY_SYSDIR ]; then
sync
# Unmount filesystems backed by this device
unmount_rdev `cat $ULTRABAY_SYSDIR/block/*/dev \
$ULTRABAY_SYSDIR/block/*/*/dev` \
|| {
echo 10 > /proc/acpi/ibm/beep; # error tone
exit 1;
}
sync
# Nicely power off the device
DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE
# Let HAL+KDE notice the unmount and let the disk spin down
sleep 0.5
# Unregister this SCSI device:
sync
echo 1 > $ULTRABAY_SYSDIR/delete
fi

# We really need a 3 sec pause here otherwise the system will freeze..
sleep 3

# Turn off power to the UltraBay:
if [ -d /sys/devices/platform/bay.0 ]; then
echo 1 > /sys/devices/platform/bay.0/eject
elif [ -e /proc/acpi/ibm/bay ]; then
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
echo 12 > /proc/acpi/ibm/beep
</pre>

Create {{path|/etc/acpi/events/ultrabay-insert}}:
<pre>
event=ibm/bay MSTR 00000001 00000000
action=/usr/local/sbin/ultrabay_insert
</pre>

Create {{path|/etc/acpi/events/ultrabay-eject}}:
<pre>
event=ibm/bay MSTR 00000003 00000000
action=/usr/local/sbin/ultrabay_eject
</pre>

Restart <tt>acpid</tt>.

===using the generic bay driver and udev===

Starting from kernel 2.6.23-rc3, it's possible to use the generic <tt>bay</tt> driver in combination with udev to hotswap. Please check if CONFIG_ACPI_BAY is enabled (module or built-in) in your kernel configuration.

Create {{path|/etc/udev/rules.d/ibm-ultrabay.rules}}:
<pre>
ENV{BAY_EVENT}=="3", KERNEL=="bay.0", ACTION=="change", SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_eject"
ENV{BAY_EVENT}=="1", KERNEL=="bay.0", ACTION=="change", SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_insert"
</pre>

===using libata-acpi and udev===

Starting from kernel 2.6.26-rc5, it's possible to use <tt>libata-acpi</tt> in combination with udev to hotswap. Please check if CONFIG_ATA_ACPI is enabled in your kernel configuration.

For 2.6.25, you need two patches which can be easily backported ([http://article.gmane.org/gmane.linux.acpi.devel/31159],[http://article.gmane.org/gmane.linux.acpi.devel/31369]).

Create {{path|/etc/udev/rules.d/ibm-ultrabay.rules}}:
<pre>
ENV{BAY_EVENT}=="3", ACTION=="change", SUBSYSTEM=="scsi", RUN+="/usr/local/sbin/ultrabay_eject"
</pre>

===Model-specific notes===
See the table above for a list of ata_piix supported laptops and the bus ID to use.

===HAL support===

{{NOTE| Starting from HAL 0.5.11, you need to replace "storage.physical_device" with "info.parent".}}

Many programs, KDE included, rely on [[HAL]] to get notifications and information about device hotplugging. You need to tell HAL that devices connected the UltraBay port are hotpluggable. To do so, create the file {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as follows:
<pre>
<?xml version="1.0" encoding="UTF-8"?> 

<deviceinfo version="0.2">
<device>


<match key="storage.bus" string="scsi">
<match key="storage.physical_device" string="/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0">
<merge key="storage.hotpluggable" type="bool">true</merge>
</match>
</match>

</device>
</deviceinfo>
</pre>

The string "8086_2653" may need to be changed to match your ThinkPad model; see below.

====Details====

By default, HAL doesn't know that UltraBay devices are hotpluggable:

# PHYSDEV=/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0
# UDI=`hal-find-by-property --key storage.physical_device --string $PHYSDEV` || echo Failed
# hal-get-property --udi $UDI --key block.device
/dev/sdb
# hal-get-property --udi $UDI --key storage.hotpluggable
false

After creating {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as above and re-plugging the device, it will get marked correctly:

# PHYSDEV=/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0
# UDI=`hal-find-by-property --key storage.physical_device --string $PHYSDEV` || echo Failed
# hal-get-property --udi $UDI --key block.device
/dev/sdb
# hal-get-property --udi $UDI --key storage.hotpluggable
true

The string "8086_2653" gives the PCI ID of the [[Intel 82801FBM]] southbridge. If your model has a different southbridge, or the UltraBay is attached to a different port, then you can find the appropriate <tt>storage.physical_device</tt> value by finding out the block device of the currently running UltraBay device (<tt>/dev/sdb</tt> in the following example) and then running:

# DEVICE=/dev/sdb
# UDI=`hal-find-by-property --key block.device --string $DEVICE` || echo Failed
# hal-get-property --udi $UDI --key storage.physical_device
/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0

If you have a different <tt>storage.physical_device</tt> value, please report your findings.

{| border=1
|+ Known South Bridge PCI IDs
! ID !! ThinkPad model !! South Bridge chip
|-
| 8086_248a || 2366-83U (T30) || Intel 82801CAM IDE U100 (rev 2)
|-
| 8086_2653 || 2525FAG (X41), ? (T43) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40), 2373KXU (T42p) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 Family)
|-
| 8086_2850 || T61p || Intel 82801H (ICH8 Family)
|}

==When using the <tt>ide-disk</tt> driver==
The following applies if you use the <tt>ide-disk</tt> driver for the UltraBay device. 
Note that essentially, you shouldn't be using this driver, and use ata_piix instead unless you're running an older kernel where ata_piix won't work for you

Hotswapping is supposed to be supported as well, using either hdparm/[http://packages.debian.org/unstable/admin/hotswap Debian hotswap] or [[lt_hotswap]] to (un)register IDE devices. The latter is the recommended method with kernels from 2.6, since it will leave DMA working. However, for recent models (R52, T43, X41, Z60 and later) no method is known to work while maintaining DMA support; see [[Problems with SATA and Linux]].

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.

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, you can either use the [http://packages.debian.org/unstable/admin/hotswap Debian hotswap] package, or [[lt_hotswap]]. Note that lt_hotswap doesn't seem to even build on recent (at 2.6.22 or newer, although it probably broke before 2.6.22) and on newer kernels, you should not build/load the old IDE PIIX (CONFIG_BLK_DEV_PIIX) and use the natively hotswapping ata_piix (CONFIG_ATA_PIIX) as explained on the top of this page.

[http://packages.debian.org/unstable/admin/hotswap Debian hotswap] also allows the drive to be swapped as a normal user by default, which is useful. You should use <tt>hotswap</tt> to unregister the device and then {{cmdroot|echo eject > /proc/acpi/ibm/bay}}. However, if you use this method on a 2.6 kernel, you will lose DMA support for the reinserted drive. This is due to kernel issues. This method 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).

[[lt_hotswap]] is now the recommended method to un- and reregister the IDE device. It installs as a kernel module and has support for automatically unregistering (if loaded with the auto_eject=1 option) the device when the eject event is generated by [[ibm-acpi]]. It will leave DMA support intact. It has supported to work on a ThinkPad {{T22}} and {{T40}} and should work with many other models (but not recent models which require the <tt>ata_piix</tt> driver for disk DMA support). With the [[lt_hotswap]] kernel module loaded, run: {{cmdroot|modprobe -r ide_cd && modprobe -r cdrom && echo "MSTR eject" > /proc/acpi/lths}}

===HAL support===

HAL support also can also be configured To do so, create the file {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as follows:
<pre>
<?xml version="1.0" encoding="UTF-8"?> 

<deviceinfo version="0.2">
<device>


<match key="storage.bus" string="ide">
<match key="storage.physical_device" string="/org/freedesktop/Hal/devices/pci_8086_24ca_ide_1_0">
<merge key="storage.hotpluggable" type="bool">true</merge>
</match>
</match>

</device>
</deviceinfo>
</pre>
For more details see HAL section for ata driver.

==Other comments==

If you are hot-swapping a hard disk on a disk tray, make sure the disk does not have a password set, otherwise it will not be recognized on reinsertion.

[[Category:Scripts]]
[[Category:HOWTOs]]

How to hotswap Ultrabay devices

2008-08-26T10:55:45Z

Zin: /* Scripts for hotswapping */

The following discusses hotswap (AKA "hotplug") of devices in the [[UltraBay]].

==Which driver?==
Since this may be confusing for SATA thinkpad owners, which are likely all the same for now, you have two busses and drivers: one SATA bus which works with the AHCI driver and one IDE bus for the ultrabay for which you should pick ata_piix (not piix/CONFIG_BLK_DEV_PIIX). See below for hotswapping.

==Choosing the right driver: new style <tt>ata_piix</tt> vs old style <tt>piix/ide-disk</tt>==
For ICH5,6,7,8, systems, whether you have an older IDE only thinkpad, or a newer thinkpad like the T/Z61p, there is one SATA bus for the system hard drive and an IDE bus for the ultrabay (even if your ultrabay happens to have a SATA drive, as it'll be seen as an IDE device), you'll have two drivers to chose from for your ultrabay: the old IDE/piix+ide-disk driver, and the newer PATA (=IDE) support of the newer ata_piix driver. 
<tt>piix+ide-disk</tt> are part of the old original IDE driver and your ultrabay device will show up as <tt>/dev/hda</tt>. <tt>ata-piix</tt> is the new SATA/PATA (=IDE) driver that will cause your ultrabay Hard Drive to show up as <tt>/dev/sda</tt> and your CD-Rom as <tt>/dev/sr0</tt>

The two things to know are: 1) you want to use ata_piix and 2) if you build piix in (CONFIG_BLK_DEV_PIIX enabled), or load it as a module, it'll take over the IDE bus and prevent ATA_PIIX from seeing your ultrabay. You don't want that.

The longer details are: 
You don't want the piix+ide-disk combo because even as modules, you will not be able to unload piix to reset the bus if there are issues swapping devices (with ata_piix, even if you forget to unregister a drive before removing it, you can unload the module and reload it to reset the bus after the fact if you have a newer thinkpad with a separate AHCI/SATA bus for the boot drive).

As for hotswap, with piix+ide-disk, you can read the section below, but after more than one day of trying on 2.6.22.15 (as piix+ide-disk was taking over my IDE bus, and stopping me from using ata_piix before I removed it), I was not able to get hotswapping to work with piix+ide-disk (lt_hotswap would not even build on 2.6.22.15).

hotswap just works with ata_pixx on 2.6.22, and reportedly with anything newer than 2.6.18, so you want to get rid of piix+ide-disk.
There are several ways to do that:
* if piix is built in your kernel (CONFIG_BLK_DEV_PIIX):
** rebuild your kernel with CONFIG_BLK_DEV_PIIX turned off.
** if you don't want to rebuild your kernel, try disabling the IDE bus grabbing by that driver with <tt>ide0=noprobe hda=noprobe hdb=noprobe</tt> in your grub/lilo config (adjust the drive letters as appropriate, but note that this did not work for me on 2.6.22.15: the drive didn't show up on the piix bus, but it didn't show up on the ata_piix bus either).
* if piix is built in as a module
** you can move out the module in {{path|/lib/modules/ver/kernel/drivers/ide/pci/piix.ko}} and reboot.
** or build a new kernel, again with CONFIG_BLK_DEV_PIIX turned off.
** or add <tt>options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe"</tt> to your modprobe.conf is supposed to work too (but didn't work on 2.6.22.15, see comment above)

Then, continue this document to see how to do hotswap with ata_piix (if you are lucky enough to have a newer SATA thinkpad where the ata_piix driver only runs the ultrabay, and you have a separate bus and ahci driver for your main drive, it is recommended to have ata_piix as a module (<tt>CONFIG_ATA_PIIX=m</tt>) so that you can unload/reload it if your bus gets in a bad state after a failed hotswap)

==When using the <tt>ata_piix</tt> driver==
The following applies when using the <tt>ata_piix</tt> driver, which is necessary for many recent ThinkPad models that use an [[Intel ICH6-M]] controller. See also [[Problems with SATA and Linux]].

Mainline kernels before 2.6.18 cannot reliably recognize newly (re-)inserted UltraBay drives without a reboot. There are experimental hotplug patches against pre-2.6.18 mainline kernels [http://home-tj.org/wiki/index.php/Libata-tj-stable here].

* Available hotplug patches
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.16.16-20060512.tar.bz2 Patch tarball against 2.6.16.16] ([http://lwn.net/Articles/183407/ Announce])
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17-20060625-1.tar.bz2 Patch tarball against 2.6.17/2.6.17.1] ([http://article.gmane.org/gmane.linux.ide/11598 Announce])
**[http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17.4-20060710.tar.bz2 Patch tarball against 2.6.17.4]
**[http://whoopie.gmxhome.de/linux/patches/2.6.17.14-tj/00-libata-tj-2.6.17.4-20060710.patch Patch against 2.6.17.14]

* Confirmed to work on the following laptops, with bus the following ID
**ThinkPad {{T30}}
**ThinkPad {{T43}}, {{T43p}}
**ThinkPad {{R52}}
**ThinkPad {{T60}} ID=4
**ThinkPad {{T61}} ID=0
**ThinkPad {{Z61p}} ID=4 (0-3:ahci, 5-6: ata_piix)
ID will typically be 1 if you only have an IDE bus (0 is boot drive, 1 is ultrabay), and it'll be 4 if you have a SATA bus your system boots from (ID 0-3) and an IDE bus for your ultrabay (ID 4-5). 
Note that even on a given laptop model the ID can vary depending on whether your kernel has drivers that configure your boot drive is using the old style IDE driver (which doesn't add IDs before your ultrabay), or whether your boot drive is using the new style driver (which adds IDs before your ultrabay)

Hotplug just works with kernels newer than 2.6.18 ( or older kernels that were patched to support <tt>ata_piix</tt> hotplug (don't try it otherwise!)) 
First, it is recommended you find the right SCSI ID for your drive to hotswap and unregister it before removing it (this works with all recent mainline kernels):
{{cmdroot|echo 1 > /sys/class/scsi_device/$ID:0:0:0/device/delete}}
{{cmdroot|echo eject > /proc/acpi/ibm/bay}}
The drive can now be ejected (without this, your IDE bus may complain if you just yank a drive, but you can usually recover by unloading/reloading the ata_piix module on a SATA laptop if your main drive is not on the ata_piix bus)

You can then issue the following after inserting an UltraBay drive to rescan the port:
{{cmdroot|echo 0 0 0 > /sys/class/scsi_host/host$ID/scan}}
The inserted drive should now be recognized by the kernel, and appropriate {{path|/dev/*}} entries created automatically (e.g., by <tt>udev</tt>).

Ted T'so has also written this hotswap patch, which may or may not be needed for you, see [http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg04716.html hotswap patch] and report back

===Scripts for hotswapping===

The following scripts and [[acpid]] daemon configuration files do the following:
* Automatically unmounts the relevant filesystems and power off the UltraBay when the UltraBay eject lever is released. Screams if some filesystem can't be unmounted.
* Rescans the UltraBay port when then UltraBay eject lever is pushed back in.

They assumes you're using the <tt>ata_piix</tt> driver with an appropriate kernel (see above).

Create {{path|/usr/local/sbin/ultrabay_insert}} with permissions 755:
<pre>
#!/bin/bash
echo 12 > /proc/acpi/ibm/beep
sync
echo 0 0 0 > /sys/class/scsi_host/host1/scan
</pre>

Create {{path|/usr/local/sbin/ultrabay_eject}} with permissions 755:
<pre>
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

# Umount the filesystem(s) backed by the given major:minor device(s)
unmount_rdev() { perl - "$@" <<'EOPERL' # let's do it in Perl
for $major_minor (@ARGV) {
$major_minor =~ m/^(\d+):(\d+)$/ or die;
push(@tgt_rdevs, ($1<<8)|$2);
}
# Sort by reverse length of mount point, to unmount sub-directories first
open MOUNTS,"</proc/mounts" or die "$!";
@mounts=sort { length($b->[1]) <=> length($a->[1]) } map { [ split ] } <MOUNTS>;
close MOUNTS;
foreach $m (@mounts) {
($dev,$dir)=@$m;
next unless -b $dev; $rdev=(stat($dev))[6];
next unless grep($_==$rdev, @tgt_rdevs);
system("umount","-v","$dir")==0 or $bad=1;
}
exit 1 if $bad;
EOPERL
}

# Get the UltraBay's /dev/foo block device node
ultrabay_dev_node() {
UDEV_PATH="`readlink -e "$ULTRABAY_SYSDIR/block:"*`" || return 1
UDEV_NAME="`udevinfo -q name -p $UDEV_PATH`" || return 1
echo /dev/$UDEV_NAME
}

if [ -d $ULTRABAY_SYSDIR ]; then
sync
# Unmount filesystems backed by this device
unmount_rdev `cat $ULTRABAY_SYSDIR/block\:*/dev \
$ULTRABAY_SYSDIR/block\:*/*/dev` \
|| {
echo 10 > /proc/acpi/ibm/beep; # error tone
exit 1;
}
sync
# Nicely power off the device
DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE
# Let HAL+KDE notice the unmount and let the disk spin down
sleep 0.5
# Unregister this SCSI device:
sync
echo 1 > $ULTRABAY_SYSDIR/delete
fi
sync
# Turn off power to the UltraBay:
if [ -d /sys/devices/platform/bay.0 ]; then
echo 1 > /sys/devices/platform/bay.0/eject
elif [ -e /proc/acpi/ibm/bay ]; then
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
echo 12 > /proc/acpi/ibm/beep
</pre>

Use the modified version below if the above doesn't work for you (for kernels 2.5.25+ due to ULTRABAY_SYSDIR/block\:*/dev path change). It was tested on a Thinkpad X41 with Fedora 9 and kernel 2.6.25.11:

<pre>
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

# Umount the filesystem(s) backed by the given major:minor device(s)
unmount_rdev() { perl - "$@" <<'EOPERL' # let's do it in Perl
for $major_minor (@ARGV) {
$major_minor =~ m/^(\d+):(\d+)$/ or die;
push(@tgt_rdevs, ($1<<8)|$2);
}
# Sort by reverse length of mount point, to unmount sub-directories first
open MOUNTS,"</proc/mounts" or die "$!";
@mounts=sort { length($b->[1]) <=> length($a->[1]) } map { [ split ] } <MOUNTS>;
close MOUNTS;
foreach $m (@mounts) {
($dev,$dir)=@$m;
next unless -b $dev; $rdev=(stat($dev))[6];
next unless grep($_==$rdev, @tgt_rdevs);
system("umount","-v","$dir")==0 or $bad=1;
}
exit 1 if $bad;
EOPERL
}

# Get the UltraBay's /dev/foo block device node
ultrabay_dev_node() {
UDEV_PATH="`readlink -e "$ULTRABAY_SYSDIR/block/"*`" || return 1
UDEV_NAME="`udevinfo -q name -p $UDEV_PATH`" || return 1
echo /dev/$UDEV_NAME
}

if [ -d $ULTRABAY_SYSDIR ]; then
sync
# Unmount filesystems backed by this device
unmount_rdev `cat $ULTRABAY_SYSDIR/block/*/dev \
$ULTRABAY_SYSDIR/block/*/*/dev` \
|| {
echo 10 > /proc/acpi/ibm/beep; # error tone
exit 1;
}
sync
# Nicely power off the device
DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE
# Let HAL+KDE notice the unmount and let the disk spin down
sleep 0.5
# Unregister this SCSI device:
sync
echo 1 > $ULTRABAY_SYSDIR/delete
fi

# We really need a 3 sec pause here otherwise the system will freeze..
sleep 3

# Turn off power to the UltraBay:
if [ -d /sys/devices/platform/bay.0 ]; then
echo 1 > /sys/devices/platform/bay.0/eject
elif [ -e /proc/acpi/ibm/bay ]; then
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
echo 12 > /proc/acpi/ibm/beep
</pre>

Create {{path|/etc/acpi/events/ultrabay-insert}}:
<pre>
event=ibm/bay MSTR 00000001 00000000
action=/usr/local/sbin/ultrabay_insert
</pre>

Create {{path|/etc/acpi/events/ultrabay-eject}}:
<pre>
event=ibm/bay MSTR 00000003 00000000
action=/usr/local/sbin/ultrabay_eject
</pre>

Restart <tt>acpid</tt>.

===using the generic bay driver and udev===

Starting from kernel 2.6.23-rc3, it's possible to use the generic <tt>bay</tt> driver in combination with udev to hotswap. Please check if CONFIG_ACPI_BAY is enabled (module or built-in) in your kernel configuration.

Create {{path|/etc/udev/rules.d/ibm-ultrabay.rules}}:
<pre>
ENV{BAY_EVENT}=="3", KERNEL=="bay.0", ACTION=="change", SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_eject"
ENV{BAY_EVENT}=="1", KERNEL=="bay.0", ACTION=="change", SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_insert"
</pre>

===using libata-acpi and udev===

Starting from kernel 2.6.26-rc5, it's possible to use <tt>libata-acpi</tt> in combination with udev to hotswap. Please check if CONFIG_ATA_ACPI is enabled in your kernel configuration.

For 2.6.25, you need two patches which can be easily backported ([http://article.gmane.org/gmane.linux.acpi.devel/31159],[http://article.gmane.org/gmane.linux.acpi.devel/31369]).

Create {{path|/etc/udev/rules.d/ibm-ultrabay.rules}}:
<pre>
ENV{BAY_EVENT}=="3", ACTION=="change", SUBSYSTEM=="scsi", RUN+="/usr/local/sbin/ultrabay_eject"
</pre>

===Model-specific notes===
See the table above for a list of ata_piix supported laptops and the bus ID to use.

===HAL support===

{{NOTE| Starting from HAL 0.5.11, you need to replace "storage.physical_device" with "info.parent".}}

Many programs, KDE included, rely on [[HAL]] to get notifications and information about device hotplugging. You need to tell HAL that devices connected the UltraBay port are hotpluggable. To do so, create the file {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as follows:
<pre>
<?xml version="1.0" encoding="UTF-8"?> 

<deviceinfo version="0.2">
<device>


<match key="storage.bus" string="scsi">
<match key="storage.physical_device" string="/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0">
<merge key="storage.hotpluggable" type="bool">true</merge>
</match>
</match>

</device>
</deviceinfo>
</pre>

The string "8086_2653" may need to be changed to match your ThinkPad model; see below.

====Details====

By default, HAL doesn't know that UltraBay devices are hotpluggable:

# PHYSDEV=/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0
# UDI=`hal-find-by-property --key storage.physical_device --string $PHYSDEV` || echo Failed
# hal-get-property --udi $UDI --key block.device
/dev/sdb
# hal-get-property --udi $UDI --key storage.hotpluggable
false

After creating {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as above and re-plugging the device, it will get marked correctly:

# PHYSDEV=/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0
# UDI=`hal-find-by-property --key storage.physical_device --string $PHYSDEV` || echo Failed
# hal-get-property --udi $UDI --key block.device
/dev/sdb
# hal-get-property --udi $UDI --key storage.hotpluggable
true

The string "8086_2653" gives the PCI ID of the [[Intel 82801FBM]] southbridge. If your model has a different southbridge, or the UltraBay is attached to a different port, then you can find the appropriate <tt>storage.physical_device</tt> value by finding out the block device of the currently running UltraBay device (<tt>/dev/sdb</tt> in the following example) and then running:

# DEVICE=/dev/sdb
# UDI=`hal-find-by-property --key block.device --string $DEVICE` || echo Failed
# hal-get-property --udi $UDI --key storage.physical_device
/org/freedesktop/Hal/devices/pci_8086_2653_scsi_host_0_scsi_device_lun0

If you have a different <tt>storage.physical_device</tt> value, please report your findings.

{| border=1
|+ Known South Bridge PCI IDs
! ID !! ThinkPad model !! South Bridge chip
|-
| 8086_248a || 2366-83U (T30) || Intel 82801CAM IDE U100 (rev 2)
|-
| 8086_2653 || 2525FAG (X41), ? (T43) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40), 2373KXU (T42p) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 Family)
|-
| 8086_2850 || T61p || Intel 82801H (ICH8 Family)
|}

==When using the <tt>ide-disk</tt> driver==
The following applies if you use the <tt>ide-disk</tt> driver for the UltraBay device. 
Note that essentially, you shouldn't be using this driver, and use ata_piix instead unless you're running an older kernel where ata_piix won't work for you

Hotswapping is supposed to be supported as well, using either hdparm/[http://packages.debian.org/unstable/admin/hotswap Debian hotswap] or [[lt_hotswap]] to (un)register IDE devices. The latter is the recommended method with kernels from 2.6, since it will leave DMA working. However, for recent models (R52, T43, X41, Z60 and later) no method is known to work while maintaining DMA support; see [[Problems with SATA and Linux]].

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.

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, you can either use the [http://packages.debian.org/unstable/admin/hotswap Debian hotswap] package, or [[lt_hotswap]]. Note that lt_hotswap doesn't seem to even build on recent (at 2.6.22 or newer, although it probably broke before 2.6.22) and on newer kernels, you should not build/load the old IDE PIIX (CONFIG_BLK_DEV_PIIX) and use the natively hotswapping ata_piix (CONFIG_ATA_PIIX) as explained on the top of this page.

[http://packages.debian.org/unstable/admin/hotswap Debian hotswap] also allows the drive to be swapped as a normal user by default, which is useful. You should use <tt>hotswap</tt> to unregister the device and then {{cmdroot|echo eject > /proc/acpi/ibm/bay}}. However, if you use this method on a 2.6 kernel, you will lose DMA support for the reinserted drive. This is due to kernel issues. This method 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).

[[lt_hotswap]] is now the recommended method to un- and reregister the IDE device. It installs as a kernel module and has support for automatically unregistering (if loaded with the auto_eject=1 option) the device when the eject event is generated by [[ibm-acpi]]. It will leave DMA support intact. It has supported to work on a ThinkPad {{T22}} and {{T40}} and should work with many other models (but not recent models which require the <tt>ata_piix</tt> driver for disk DMA support). With the [[lt_hotswap]] kernel module loaded, run: {{cmdroot|modprobe -r ide_cd && modprobe -r cdrom && echo "MSTR eject" > /proc/acpi/lths}}

===HAL support===

HAL support also can also be configured To do so, create the file {{path|/etc/hal/fdi/information/10-ultrabay.fdi}} as follows:
<pre>
<?xml version="1.0" encoding="UTF-8"?> 

<deviceinfo version="0.2">
<device>


<match key="storage.bus" string="ide">
<match key="storage.physical_device" string="/org/freedesktop/Hal/devices/pci_8086_24ca_ide_1_0">
<merge key="storage.hotpluggable" type="bool">true</merge>
</match>
</match>

</device>
</deviceinfo>
</pre>
For more details see HAL section for ata driver.

==Other comments==

If you are hot-swapping a hard disk on a disk tray, make sure the disk does not have a password set, otherwise it will not be recognized on reinsertion.

[[Category:Scripts]]
[[Category:HOWTOs]]

Talk:How to hotswap Ultrabay devices

2008-08-26T10:38:29Z

Zin: /* Ultrabay Hotswap on ThinkPad X41 */

I recently tried using the libata-tj patch tarball for 2.6.16.16, applying this against the newly released 2.6.16.18 kernel (released today.) Patch applied cleanly. Upon boot, I immediately get a multitude of "weird" errors -- strange lockups, programs segmentation fault (running "top" resulted in a seg fault), and ultimately a hard lockup.

I booted back to my vanilla 2.6.16.16, ran fsck (appeared to just replay a few transactions, no major damage), and am back to normal. However, it successfully scared me off - unfortunately can't risk too much downtime (or worse, subtle fs corruption) right now on my main system. Anybody have experiences with this on a T43p using piix driver?

--[[User:gsmenden|gsmenden]] 00:00, 23 May 2006 (EST)
----

The 2.6.16.16 patch works fine on my T43. There's a git tree (mentioned on the patch's webpage) which is closer to 2.6.18, but AFAIK no simple unified patch was prepred.

--[[User:Thinker|Thinker]] 08:37, 23 May 2006 (CEST)
----

Cool. If I get brave I'll try it again on the 43p against 2.6.16.16 proper and report back.

--[[User:gsmenden|gsmenden]] 15:29, 23 May 2006 (EST)
----

Works fine here on 2.6.16.
I got only one crash with Suspend to Ram, which I'm unable to reproduce yet.
I renamed the acpi event files because at least my acpid doesn't read files that ends with .conf

--[[User:Defiant|Defiant]] 21:09, 28 May 2006 (CEST)

----
Update - patched against 2.6.16.19, works fine. It appears my previous problems were due to a disk error unrelated to the patch. Excellent!

--[[User:gsmenden|gsmenden]] 00:57, 31 May 2006 (EST)

Anybody have time to make a patch of the libata(-tj) .git tree against the recently released 2.6.17? I hope to make one in the future if not...

--[[User:gsmenden|gsmenden]] 22:08, 19 Jun 2006 (EST)

== one nit about ultrabay_close script / patch against 2.6.17 available ==

Howdy,

In ultrabay_close, there is 'sleep 3' for disk spinup, which isn't necessary. libata itself waits for disk spinup and if something breaks (e.g. first reset fails w/ timeout or something), it's libata's fault. Please remove that line and see if anything breaks.

Also, I've uploaded patch against 2.6.17/2.6.17.1 today.

http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17-20060625-1.tar.bz2

Hmmm... My post looks different from others. This wasn't intentional. Just don't know how to add normal discussion entry. Sorry.

--tj
----

Right, it works fine without "sleep 3" using the new patches. Sleep removed.

--[[User:Thinker|Thinker]] 12:35, 1 July 2006 (CEST)
----

Is it correct, that the ata_piix driver in kernel 2.6.18 RC4 now supports hot swapping like described in the howto and announced here http://lwn.net/Articles/183734/?

--[[User:cob|cob]] 15:53, 23 August 2006

== T42 freezing up when trying to hot swap ultrabay. ==

Hi,

Please bear with me. I am totally new at this and I am making my best effort to understand and learn.

My problem is that when typing "# echo eject > /proc/acpi/ibm/bay" to eject my ultrabay and put another in, I see the power going off in the ultrabay LED, but then my PC freezes completely.

I am running Fedora 6 Test 3, kernel 2.6.17-1.2647 and my notebook is a ThinkPad T42.

Please help! I have to constantly be changing my bay to use information in other hard drives, and I have to shutdown the system completely to not have any problems.

Thanks,

--Barny 09/21/2006@7:46PM EST

----
Have the same problem on a T40p running SuSE 10.1. Also lt_hotplug module is of no help. Keep me informed in case you have a solution!
Thanks,
--[[User:Ays|Ays]] 19:49, 5 October 2006 (CEST)

----

I have no problems with kernel 2.6.17-1.2187_1.fc5.cu from suspend2 on my T42p running Fedora Core 5. I have compiled the lt_hotswap module and every thing works fine. Since kernel 2.6.18-1.2200.fc5 my system freeez on loading the modul or on calling "echo eject > /proc/acpi/ibm/bay".
Any ideas what has changed in the kernel?

--CoolMischa 2006-11-06@13:24 CET

== Second disk not seen correctly on reinsert (T43p) [solved] ==

(update: see below for solution)

I have followed the instructions on my T43p running Gentoo using 2.6.18. I have a second hard disk in the UltraBay, using ata_piix, so it is seen as /dev/sdb (as described in [[Problems with SATA and Linux#No_DMA_on_system_hard_disk|Problems with SATA and Linux]]). The eject works fine. When I reinsert it and issue the rescan command, Only the main /dev/sdb device reappears, but not the ones corresponding to the partitions (/dev/sdb1, etc.), so I cannot mount them, and fdisk /dev/sdb says that it cannot open the device.

In dmesg, I see a bunch of errors like these, repeated multiple times:

<pre>
sd 1:0:0:0: SCSI error: return code = 0x08000002
sdb: Current: sense key=0xb
ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sdb, sector 0
ata2: EH complete
ata2.00: speed down requested but no transfer mode left
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata2.00: tag 0 cmd 0x20 Emask 0x1 stat 0x51 err 0x4 (device error)
ata2: EH complete
ata2.00: speed down requested but no transfer mode left
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata2.00: tag 0 cmd 0x20 Emask 0x1 stat 0x51 err 0x4 (device error)
ata2: EH complete
ata2.00: speed down requested but no transfer mode left
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata2.00: tag 0 cmd 0x20 Emask 0x1 stat 0x51 err 0x4 (device error)
ata2: EH complete
ata2.00: speed down requested but no transfer mode left
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata2.00: tag 0 cmd 0x20 Emask 0x1 stat 0x51 err 0x4 (device error)
ata2: EH complete
ata2.00: speed down requested but no transfer mode left
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata2.00: tag 0 cmd 0x20 Emask 0x1 stat 0x51 err 0x4 (device error)
ata2: EH complete
ata2.00: speed down requested but no transfer mode left
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata2.00: tag 0 cmd 0x20 Emask 0x1 stat 0x51 err 0x4 (device error)
</pre>

And at the end:

<pre>
sdb: Current: sense key=0xb
ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sdb, sector 0
ata2: EH complete
SCSI device sdb: 117210240 512-byte hdwr sectors (60012 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 117210240 512-byte hdwr sectors (60012 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
</pre>

The situation is not cured by a reboot (I still see only /dev/sdb), I have to power cycle to get the devices back.

Thanks for any ideas.

----

(2006-10-10) As a followup to my note above, I have noticed that the DVD-RW drive works perfectly after hot-swapping it - it's just the second hard disk that doesg not get recognized properly. I can "scsiping" the /dev/sdb device and it seems to respond OK, I have tried restarting udevd without success, and I'm at a loss as to what to try next.

---

It turned out to be an obvious problem - I had a disk password set on my second disk, so on reinsert it could not be accessed. I turned off the disk password, and now it works perfectly.

== ultrabay_open: Problem when using /proc/mounts ==

I am just working on a perl-free version of the ultrabay_open script. When the script reads the currently mounted devices from /proc/mounts, it may not find all the relevant device files. A file system mounted with a relative device path given to the mount command doesn't show up with the absolute device path in /proc/mounts. Example:

{{cmdroot|cd /dev/; mount sdb5 /mnt}} results in the following line in {{path|/proc/mounts}}:

{{cmdresult|sdb5 /mnt ext3 rw 0 0}}

{{path|/etc/mtab}} contains the needed information:

{{cmdresult|/dev/sdb5 /mnt ext3 rw 0 0}}

However, /proc/mounts is the more reliable source of information IMHO. The absolute device path is needed to find out its major and minor numbers.

Any suggestions?

--[[User:Acolomb|MinioN]] 01:03, 28 December 2006 (CET)

== Can/t mount CD after reinsert on X41 ==

I did all the steps described on this page, and the drive ejects fine, and then when I
reinsert it the /dev/scd0 entry reappears, but when I insert a CD Gnome won't mount it
automatically, and when I try manually I ger this message:

mount: wrong fs type, bad option, bad superblock on /dev/scd0,
missing codepage or other error

and dmesg says:

isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16

I have to reboot to use the drive again.

P.S. I discovered the following in dmesg when I boot:

ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.00: configured for UDMA/33

Is that relevant?

== hdparm -Y /dev/<devnode> ==

is the hdparm part in the ultrabay_eject script really necessary?

It does not work with my dvdram drive (R60):

hdparm -Y /dev/sdb

/dev/sdb:
issuing sleep command
HDIO_DRIVE_CMD(sleep) failed: Input/output error

thanks,

== problem with umount_rdev ==

I tried out the ultrabay_eject script and get this error (debian lenny with kernel 2.6.22.3)

cat: /sys/class/scsi_device/1:0:0:0/device/block:*/*/dev: No such file or directory

What is wrong? Why I need the output of $ULTRABAY_SYSDIR/block\:*/*/dev in

unmount_rdev `cat $ULTRABAY_SYSDIR/block\:*/dev /
$ULTRABAY_SYSDIR/block\:*/*/dev` \

?
== hotswap with kernel 2.6.24 and archlinux ==
Since I change to kernle 2.6.24 on my archlinux hotswap isn't working anymore. When I try to swap between harddisk and DVD-drive the system frezzes and the only way to get it back to work ist turn the power of.
Has anyone else the same problem? And is there a way to fix it?

---

Yes I stumbled today(6.Apr.) over this annoying regression: On my T42p 2373-KYG with Kubuntu 8.04 Hardy Heron
Kubuntu is freezing totally after only removing the DVD drive from the UltraBay slot.
This happens on a T42p upgraded from Gutsy and on another T42p with a clean and fresh Hardy install. (/Lophiomys)

---

I think I may know what is causing the issue: Disable ACPI support on libata, or switch to thinkpad-acpi [deprecated] bay support. The bay module is not able to load on 2.6.24+ if libata is compiled with ACPI support.

--[[User:Hmh|hmh]] 06:30, 7 May 2008 (CEST)

Could you help out with instructions for an interim workaround, how to disable ACPI support on libdata or switch to thinkpad-acpi? Thanks.

--[[User:Lophiomys|lophiomys]] 19:13, 7 May 2008 (CEST)

== Ultrabay Hotswap on ThinkPad X41 ==

After several hours of debugging and trial+error, I managed to get hotswaping ultrabay devices working in Fedora 9. The kernels I tested were 2.6.25.11 and 2.6.25.14 from fedora updates. The bay.ko driver was not present in the kernel so I just used the ibm-acpi driver (works fine). You need to create only 4 files (/usr/sbin/ultrabay_insert; /usr/sbin/ultrabay_eject; /etc/acpi/events/ultrabay-insert and /etc/acpi/events/ultrabay-eject) available from the linnk here: [http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices]. NOTE!! - DO NOT use the ultrabay_eject script from the link as it won't work. I have a modified version that works below. I have tested swapping dvdrw with an hdd and it works just fine. Make sure you restart acpid after adding the scripts. Hope this works for others..

/usr/sbin/ultrabay_eject:

<pre>
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

# Umount the filesystem(s) backed by the given major:minor device(s)
unmount_rdev() { perl - "$@" <<'EOPERL' # let's do it in Perl
for $major_minor (@ARGV) {
$major_minor =~ m/^(\d+):(\d+)$/ or die;
push(@tgt_rdevs, ($1<<8)|$2);
}
# Sort by reverse length of mount point, to unmount sub-directories first
open MOUNTS,"</proc/mounts" or die "$!";
@mounts=sort { length($b->[1]) <=> length($a->[1]) } map { [ split ] } <MOUNTS>;
close MOUNTS;
foreach $m (@mounts) {
($dev,$dir)=@$m;
next unless -b $dev; $rdev=(stat($dev))[6];
next unless grep($_==$rdev, @tgt_rdevs);
system("umount","-v","$dir")==0 or $bad=1;
}
exit 1 if $bad;
EOPERL
}

# Get the UltraBay's /dev/foo block device node
ultrabay_dev_node() {
UDEV_PATH="`readlink -e "$ULTRABAY_SYSDIR/block/"*`" || return 1
UDEV_NAME="`udevinfo -q name -p $UDEV_PATH`" || return 1
echo /dev/$UDEV_NAME
}

if [ -d $ULTRABAY_SYSDIR ]; then
sync
# Unmount filesystems backed by this device
unmount_rdev `cat $ULTRABAY_SYSDIR/block/*/dev \
$ULTRABAY_SYSDIR/block/*/*/dev` \
|| {
echo 10 > /proc/acpi/ibm/beep; # error tone
exit 1;
}
sync
# Nicely power off the device
DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE
# Let HAL+KDE notice the unmount and let the disk spin down
sleep 0.5
# Unregister this SCSI device:
sync
echo 1 > $ULTRABAY_SYSDIR/delete
fi

# We really need a 3 sec pause here otherwise the system will freeze..
sleep 3

# Turn off power to the UltraBay:
if [ -d /sys/devices/platform/bay.0 ]; then
echo 1 > /sys/devices/platform/bay.0/eject
elif [ -e /proc/acpi/ibm/bay ]; then
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
echo 12 > /proc/acpi/ibm/beep
</pre>

zin 26 August 2008

Talk:How to hotswap Ultrabay devices

2008-08-26T10:37:28Z

Zin: New section: Ultrabay Hotswap on ThinkPad X41