ThinkWiki - User contributions [en]

How to hotswap Ultrabay devices

2007-12-27T16:36:31Z

Marcmerlin:

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
else
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>

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

===HAL support===

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) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 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

2007-12-27T06:43:15Z

Marcmerlin: /* Choosing the right driver: new style <tt>ata_piix</tt> vs old style <tt>piix/ide-disk</tt> */

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

==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
else
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>

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

===HAL support===

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) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 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

2007-12-26T23:29:56Z

Marcmerlin: /* Choosing the right driver: new style <tt>ata_piix</tt> vs old style <tt>piix/ide-disk</tt> */

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

==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 ultrabady, 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
else
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>

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

===HAL support===

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) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 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]]

Lt hotswap

2007-12-26T23:26:57Z

Marcmerlin: /* Features */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
=== lt_hotswap ===
The <tt>lt_hotswap</tt> kernel module enables hot-swapping of UltraBay disk drives under Linux, with DMA support on machines with an old kernel where you might still be required to use piix+ide-disk. With 2.6.2x or better, you should use the new driver, ata_pixx with native hotswapping support.:
|}
===Features===
*enable hotswapping of [[UltraBay]] drives if you have to use the old piix/ide-disk drive instead of ata_piix which supports hotswap natively. On new kernels, you should not bother with piix+ide-disk+lt_hotswap and just use ata_piix. See the [[How to hotswap UltraBay devices]] page for more detaoils on ata_piix vs iix+ide-disk+lt_hotswap
*automatic IDE unregistering on [[ibm-acpi]] eject event
*leaves DMA support intact

===Limitations===
* Requires [[ibm-acpi]] to be running (does not work with [[APM]]).
* Works only in conjunction with the <tt>ide-disk</tt> driver (recent ThinkPad models use <tt>ata_piix</tt> instead).
* Does '''not''' get on well with idectl. Use one, or the other, or crash.
* On Kernel >= 2.6.19 "#include <linux/config.h>" in lt_hotswap.c has to be replaced by "#include <linux/autoconf.h>"
* On Kernel >= 2.6.22, "create_proc_ide_interfaces();" in lt_hotswap.c has to be replaced by "ide_proc_register_port(&ide_hwifs[num]);".
* On Kernel >= 2.6.23, all occurrences of "acpi_bus_generate_event" in lt_hotswap.c need to be replaced by "acpi_bus_generate_proc_event".

===Project Homepage / Availability===
*Project page: http://www.sourceforge.net/projects/lths
*Latest version: http://prdownloads.sourceforge.net/lths/lt_hotswap-0.3.6.tar.gz?download

Development and discussion of lt_hotswap is currently being held in
[[Mailinglists#Linux-ThinkPad Mailinglist|Linux-ThinkPad Mailinglist]].

===Installation===
In order to use the driver you must use ACPI and also have the [[ibm-acpi]] driver linked to your kernel (module or compiled).

When loading the hotswap module, you can use the module parameter: {{bootparm|auto_eject|1}} to automatically unregister the drives IDE interface. This will happen upon popping out the [[UltraBay]] lever.

===Supported models===
The driver has been explicitly reported to work on the following models. It should work on many others as well:
*ThinkPad {{A31p}} (warmswap), {{X22}}, {{X24}}, {{T30}}, {{T22}}, {{T23}}, {{T40}}, {{T42}}

<tt>lt_hotswap</tt> does '''not''' work well on models that require the <tt>ata_piix</tt> driver rather than the generic <tt>ide-disk</tt> IDE driver. See [[problems with SATA and Linux]] for a list, and [[How to hotswap UltraBay devices]] for an alternative solution on these models.

At least for a thinkpad T41p with a 2.6.15 kernel I recommend to use version 0.2 of lt_hotswap - the latest version reproducable produces oopses and kernel crashes for me.

===Script to eject an optical ultrabay drive===
I configured my system to automatically eject my optical drive in battery mode, because it saves about 500mW which is about 5% when my system is idle.
But when the drive is in use, issuing an eject will result in a kernel ooops/crash.
So the problem is: How do I check if the device is still in use, either by the kernel or by some other process?
The trick is to compile "cdrom and ide_cd" as modules. If the unload of ide_cd failes some other process is still using the device.
<bash>
#!/bin/sh
# disable bay if possible
# saves about 500mW

if modprobe -r ide_cd; then
modprobe -r cdrom
echo "MSTR eject" > /proc/acpi/lths
modprobe ide-cd
modprobe cdrom
else
echo ""
echo "$(fuser -vm /dev/hdc)"
fi
</bash>

[[Category:Drivers]] [[Category:Patches]]

==See also==
* [[How to hotswap UltraBay devices]]
* [[How_to_hotswap_the_UltraBase]]

Problems with SATA and Linux

2007-12-26T23:18:02Z

Marcmerlin:

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
Some ThinkPad models use an [[Intel ICH6-M]] SATA/PATA controller for the system hard disk. This causes several complications for Linux installation. The following lists these problems and known workarounds. Note that the details are often version- and distribution-specific.

===Models using a SATA disk interface===
Models using a SATA controller and a SATA system disk:
*ThinkPad {{R60}}, {{R60e}}, {{R61}}
*ThinkPad {{T60}}, {{T60p}}, {{T61}}
*ThinkPad {{X60}}, {{X60s}}, {{X60_Tablet}}, {{X61}}, {{X61s}}, {{X61_Tablet}}
*ThinkPad {{Z60t}}, {{Z60m}}
*ThinkPad {{Z61e}}, {{Z61t}}, {{Z61m}}, {{Z61p}}
Models using a SATA controller and a PATA (IDE) system disk with a SATA-to-PATA bridge:
*ThinkPad {{T43}}, {{T43p}}
*ThinkPad {{R52}}
*ThinkPad {{X41}}, {{X41T}}

{{NOTE|Some of these problems (namely SMART support, power management and disk information) are solved in Linux 2.6.15 with the inclusion of libata pass-through. See the SATA driver [http://linux-ata.org/features.html features], [http://linux-ata.org/software-status.html software status] and [http://linux-ata.org/driver-status.html hardware status].}}
|}

==Hang on resume from suspend to RAM==

Linux kernels prior to 2.6.16 (ata_piix) and 2.6.19 (ahci) do not support suspend and resume for SATA devices. As a result, the machine hangs upon the first disk access after resume. A kernel patch ([http://lkml.org/lkml/2005/5/2/46 LKML posting]) fixes this by adding SATA power management support.

Kernel 2.6.16 and later fixes this problem for most systems. The Thinkpad T60 and X60s still need some patches to get resume working using 2.6.16, see [[Talk:Problems with SATA and Linux#Patch against SATA-resume problem with T60|here]]. The T60p resumes properly with 2.6.17-rc6, the T60 and X60 should also. You need to enable ata_piix and disable AHCI in the bios. The latest fedora (FC5) 2.6.17 kernel seems to have fixed the resume problem on the T60p, still need to disable AHCI though. Applying [http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-5/linux-2.6-console-suspend.patch this FC5 patch] makes suspend-to-ram work with AHCI enabled.

===Patches===
* [http://shamrock.dyndns.org/~ln/linux/sata_pm.2.6.12.diff Patch for kernel 2.6.12]
* [http://shamrock.dyndns.org/~ln/linux/sata_pm.2.6.13-rc5.diff Patch for kernel 2.6.13-rc5]
* [http://lkml.org/lkml/2005/9/23/97 Patch for kernel 2.6.14]
* [http://www.xenotime.net/linux/SATA/2.6.15-rc/libata_suspend.patch Patch for kernel 2.6.15-rc4]
* [http://tpctl.sourceforge.net/tmp/sata_pm.2.6.15-rc6.patch Patch for kernels 2.6.15-rc6 through 2.6.15]

Some distributions already include this patch (e.g., {{Ubuntu}} Breezy, {{Gentoo}}'s gentoo-sources 2.6.15-r1), but some don't (e.g., {{Fedora}} 4). If your distribution doesn't include the patch, you will need to compile your own kernel with this patch included.

===Links===
* RedHat Bugzilla [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169201 bug 169201: "SATA drives fail on laptop suspend"]
* [http://lkml.org/lkml/2005/11/15/385 Fix to libata.h recommended on LKML] in case you get "ata: abnormal state 0x80 on port 0x1F7"
* RedHat Bugzilla [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183138 bug 183138": "SATA failure after pm-suspend/resume ata1: handling error/timeout"]

==Failed resume from suspend to disk==

Suspend to disk (using [[swsusp]] or [[Software Suspend 2]]) needs to load the memory image from the SATA disk. For this to work, you either need an initrd with all the necessary SATA modules, or the SATA drivers compiled into the kernel.

==DVD drive not recognized==

The <tt>ata_piix</tt> SATA driver grabs ownership over the IDE ports when it is loaded, but (by default) does not support PATA ATAPI devices such as the Ultrabay optical drives. Thus, if the <tt>ide</tt> driver is compiled as a module and loaded after <tt>ata_piix</tt>, the DVD drive will not be recognized by either driver.

Either of the following configurations will work:
* For kernel 2.6.14 and newer: enable ATAPI support in the SATA system using {{bootparm|libata.atapi_enabled|1}} (see below; this is experimental) (note this is not needed for more recent kernels)
* Compile IDE into the kernel (non-module).
* Compile both IDE and SATA as modules and make sure IDE is loaded first (the module is called 'ide_generic').

Note that the optical drive must be in the Ultrabay during system boot (Ultrabay device swapping is currently unsupported).

==No DMA on DVD drive==

Using the IDE driver, DMA support cannot be enabled on an Ultrabay optical drive:

# hdparm -d1 /dev/hdc

/dev/hdc:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

As a result, the optical drive is slow, and in particular, too slow to play video DVDs.

One workaround is to use the <tt>ata_piix</tt> driver (instead of the IDE driver) for the optical drive. This requires enabling the ATAPI support of the <tt>ata_piix</tt> driver (which as of 2.6.2x kernels, is working fine but wasn't stable in kernels before 2.6.18). You must also make sure that the IDE driver (<tt>ide-generic</tt>) does not grab the devices before <tt>ata_piix</tt>.

* Grab a recent kernel (must be 2.6.18 or newer)
* Do one of the following:
** Enable the <tt>ata_piix</tt> and <tt>libata</tt> drivers as built-in,
** Enable <tt>ata_piix</tt> and <tt>libata</tt> as modules (this is often the default) and add "<tt>options libata atapi_enabled=1</tt>" to your {{path|/etc/modprobe.conf}} (or the equivalent in your distribution).
* Do one of the following:
** Disable the IDE system.
** Build the IDE driver as built-in (this is often the default) and add the {{bootparm|hdc|noprobe}} kernel argument (e.g., in in {{path|/boot/grub/menu.lst}} or {{path|/etc/lilo.conf}}. Don't forget to run lilo after changes).
** Build the IDE driver as module and add "<tt>options ide hdc=noprobe</tt>" to your {{path|/etc/modprobe.conf}} (or the equivalent in your distribution).
* If you chose to use modules above, regenerate your <tt>initrd</tt> file.

Note : If you are using a ''Debian Sid'' system, and want to use Debian precompiled kernels, then type the following command in a ''root'' shell (This creates a new <tt>initrd</tt> with enabled ATAPI support of <tt>ata_piix</tt> and loads <tt>ata_piix</tt> before the IDE driver):
'''# echo options libata atapi_enabled=1>/etc/modprobe.d/atapienable && update-initramfs -u'''
(this is apparently not necessary with newer kernels)

The following is likely obsolete with recent kernels
Note : If your work was successful, your CD-ROM drive will no longer be accessible through /dev/hdc, but /dev/scd0 or /dev/sr0.

If this all doesn't work, use {{cmd|lspci -vn|}} to check whether one of the following chipsets is used in the Thinkpad:
{| border="1" cellspacing="0" cellpadding="2"
|-
!PCI ID
!Name
|-
|8086:7111
|Intel 82371AB/EB/MB PIIX4 IDE
|-
|8086:24db
|Intel 82801EB/ER (ICH5/ICH5R) IDE Controller
|-
|8086:25a2
|Intel 6300ESB PATA Storage Controller
|}
If yes, enable support for these chipsets has to be enabled by setting
#define ATA_ENABLE_PATA
in {{path|include/linux/libata.h}} (and report your ThinkPad model in the discussion page).

There have been reports that DVD burning doesn't work under this configuration, but it seems to work with kernel 2.6.14 and later (tested on a ThinkPad {{T43}} and {{T43p}} with a [[UltraBay Slim DVD Multi-Burner Plus]]).

===Problem with kernel 2.6.16 kernel and suspend2 2.2.1===
DVD access fails with kernel 2.6.16.* and [[Software Suspend 2|suspend2]] 2.2.1. Thia is fixed by later versions of suspend2, or by deleting the 4000-libata-rollup-2616-rc3.patch (see
[http://lists.suspend2.net/lurker/message/20060322.082452.873dc526.en.html this post notice] by Alexander E. Patrakov).

===Links===
* RedHat Bugzilla [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163418 bug 163418: "can't enable DMA on DVD drive"]
* Enabling DMA on a SATA DVD drive, kernel 2.6.18 [http://thomer.com/howtos/dma_on_sata_dvd.html]

==No DMA on system hard disk==

In recent Linux kernels, there are two modules capable of handling the ICH6 disk controller:
* <tt>ata_piix</tt>: the disk shows as {{path|/dev/sda}} and DMA is enabled.
* Generic IDE driver (<tt>ide-disk</tt>): the disk shows as {{path|/dev/hda}} and DMA is disabled.

The simplest way to enable DMA is to force the IDE driver to ignore the system hard disk by passing the {{bootparm|hda|noprobe}} and {{bootparm|hda|none}} kernel argument. The driver will then be handled by the <tt>ata_piix</tt> driver. Note that this will change its device name to {{path|/dev/sda}} (which may require changes in {{path|/etc/fstab}} and the boot loader) and may cause other problems as listed above.

(Observed on a ThinkPad T43 with Fedora Core kernel 2.6.13-1.1526_FC4.)
(Observed on a ThinkPad X40 with Debian kernel 2.6.18-4-686.) [[User:Hendry|Hendry]] 20:05, 11 June 2007 (UTC)

==No SMART support==

Prior to kernel 2.6.15, the Linux SATA system did not support SMART commands (e.g., via smartctl).

The necessary capability is "libata pass-through", which was incorporated into Linux 2.6.15-rc1 and later. A patch is available for older kernels:
* Kernel 2.6.12: http://rtr.ca/dell_i9300/kernel/kernel-2.6.12/03_libata_passthru.patch
* Kernel 2.6.13: http://rtr.ca/dell_i9300/kernel/kernel-2.6.13/02_libata_passthru.patch
* Kernel 2.6.14: http://www.foo.fh-furtwangen.de/~koenigr/02_libata_passthru.fixed.again.patch
* Kernel 2.6.14 with the above suspend-to-RAM patch: http://linux.spiney.org/system/files?file=02_libata_passthru.fixed.patch

After applying the patch, run smartctl with the "-d ata" parameter:
:{{cmdroot|smartctl -d ata -a /dev/sda}}

From smartmontools version 5.37 "-d sat" is preferred to "-d ata". The smartctl command will auto-detect SATA disks so:
:{{cmdroot|smartctl -a /dev/sda}}
should just work. The smartd daemon still requires "-d sat" in /etc/smartd.conf .

==No disk power management==

Prior to kernel 2.6.15, the Linux SATA system did not support power management commands on these models.

The above patches for SMART support resolves this, and in particular enables the following commands:
* {{cmdroot|hdparm -y}} (spin down)
* {{cmdroot|hdparm -S num}} (automatic spin down timeout)
* {{cmdroot|hdparm -B num}} (advanced power management level)
Note that this command is still rejected:
* {{cmdroot|hdparm -M num}} (acoustic management)
(Tested with patched kernels 2.6.13.1 and 2.6.12-4 and a 60GB 7200RPM disk model HTS726060M9AT00.)

Refer to [[How to make use of Harddisk Power Management features]] for details about using
HD power management. Refer to [[Laptop-mode]] if you are interested into spinning down your HD.

==No disk information==

Prior to kernel 2.6.15, on these models the disk information could not be read by the standard commands such as:
*{{cmdroot|hdparm -i /dev/sda}}
*{{cmdroot|hdparm -I /dev/sda}}
The latter is fixed by the above patch for SMART support.

==No swapping of UltraBay device==

The <tt>ata_piix</tt> driver in mainline Linux kernels supports hot-swapping and warm-swapping of PATA and SATA devices. This requires kernel 2.6.18 or newer (with older kernels, you must power off the laptop before swapping such devices). See [[How_to_hotswap_UltraBay_devices#When_using_the_ata_piix_driver|How_to_hotswap_UltraBay_devices]] for further information.

Swapping of the [[UltraBay Slim Battery]] works out-of-the box.

==BIOS error 2010 on user-installed hard disk==

While not a Linux issue, note that there is an issue with installing alternative PATA (IDE) hard disks as the system drive. Unless the disk is one of the few approved disks listed inside the BIOS, you will get an BIOS error 2010 during system boot, and the disk may operate unreliably. See [[Problem with non-ThinkPad hard disks]].

==CompactFlash module doesn't work==

Normally, PATA disks can be replaced with a solid-state [[CompactFlash]] module using a cheap PATA-to-CompactFlash adapter. However, there is a [http://thread.gmane.org/gmane.linux.ide/22400 report] that replacing the system disk with CompactFlash fails on a ThinkPad {{X41}}, possibly due to the SATA-to-PATA bridge. If so, the problem would probably occur also on the {{X41T}}, {{T43}}, {{T43p}} and {{R52}}.
I (KotCzarny) can confirm that {{X41T}} has this issue. READ is OK, but every attempt to do a WRITE results in timeouts as listed in gmane report. A quick and dirty workaround is to use generic ide driver (not sata one) to disable DMA. You won't get high speeds but at least it will work.

==RHEL3.0 Update 7 on T60p==

RHEL3.0 Update 7 will install on a {{T60p}}, but you need to make an adjustment. Both uni-processor and SMP kernels get installed, with the SMP kerrnel the default. However, the SMP kernel can't seem to find the disk drive. You can work around this by use "e" at the GRUB kernel prompt, then on the "kernel" line appending " noapic". After the system boots, you'll want to edit /boot/grub/grub.conf to add the " noapic" option to the kernel line as well.

==Mandriva 2006 on T60==

Mandriva 2006.0 has a problem with SATA on a {{T60}}, to fix this you need to make an adjustment. The install procedure can't seem to find the SATA disk drive, you can work around this by adding the "noapic" kernel option during CD/DVD boot. You *might* need to add this to lilo or GRUB for normal operations, after install completes. The problem with not using apic during normal operations is that you might have problems with power management, please see article on [[Software Suspend 2]]

==Problem burning CD/DVD==

To a CD/DVD problem, try to burn a CD/DVD as "root"-user on command-line with the option "-dummy" and "-v" enabled, do not use K3B or similar. Doing so you will get more informations and waste less CD/DVD's.

Experiment with the parameters "burnfree" and "dev". With cdrecord on debian etch, burnfree seems not work, disable it. With wodim on debian etch: try parameter "dev=/dev/scd0", the default "dev=1,0,0" seems not to work.

==Spurious NCQ completions==

The HDD firmware support for NCQ appears to be buggy ([http://lkml.org/lkml/2007/6/6/15 LKML posting] and [http://lkml.org/lkml/2007/6/6/195 LKML posting]).

The recent firmware upgrade to version SBDIC7UP ([http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-63685 Lenovo support]), didn't help.

Anyway, after months of keeping NCQ enabled despite this warning, I've had no corruptions. It could be harmless, but you are advised to be careful.

Lt hotswap

2007-12-26T21:55:49Z

Marcmerlin:

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
=== lt_hotswap ===
The <tt>lt_hotswap</tt> kernel module enables hot-swapping of UltraBay disk drives under Linux, with DMA support on machines with an old kernel where you might still be required to use piix+ide-disk. With 2.6.2x or better, you should use the new driver, ata_pixx with native hotswapping support.:
|}
===Features===
*enable hotswapping of [[UltraBay]] drives if you have to use the old piix/ide-disk drive instead of ata_piix which supports hotswap natively. On new kernels, you should not bother with piix+ide-disk+lt_hotswap and just use ata_piix.
*automatic IDE unregistering on [[ibm-acpi]] eject event
*leaves DMA support intact

===Limitations===
* Requires [[ibm-acpi]] to be running (does not work with [[APM]]).
* Works only in conjunction with the <tt>ide-disk</tt> driver (recent ThinkPad models use <tt>ata_piix</tt> instead).
* Does '''not''' get on well with idectl. Use one, or the other, or crash.
* On Kernel >= 2.6.19 "#include <linux/config.h>" in lt_hotswap.c has to be replaced by "#include <linux/autoconf.h>"
* On Kernel >= 2.6.22, "create_proc_ide_interfaces();" in lt_hotswap.c has to be replaced by "ide_proc_register_port(&ide_hwifs[num]);".
* On Kernel >= 2.6.23, all occurrences of "acpi_bus_generate_event" in lt_hotswap.c need to be replaced by "acpi_bus_generate_proc_event".

===Project Homepage / Availability===
*Project page: http://www.sourceforge.net/projects/lths
*Latest version: http://prdownloads.sourceforge.net/lths/lt_hotswap-0.3.6.tar.gz?download

Development and discussion of lt_hotswap is currently being held in
[[Mailinglists#Linux-ThinkPad Mailinglist|Linux-ThinkPad Mailinglist]].

===Installation===
In order to use the driver you must use ACPI and also have the [[ibm-acpi]] driver linked to your kernel (module or compiled).

When loading the hotswap module, you can use the module parameter: {{bootparm|auto_eject|1}} to automatically unregister the drives IDE interface. This will happen upon popping out the [[UltraBay]] lever.

===Supported models===
The driver has been explicitly reported to work on the following models. It should work on many others as well:
*ThinkPad {{A31p}} (warmswap), {{X22}}, {{X24}}, {{T30}}, {{T22}}, {{T23}}, {{T40}}, {{T42}}

<tt>lt_hotswap</tt> does '''not''' work well on models that require the <tt>ata_piix</tt> driver rather than the generic <tt>ide-disk</tt> IDE driver. See [[problems with SATA and Linux]] for a list, and [[How to hotswap UltraBay devices]] for an alternative solution on these models.

At least for a thinkpad T41p with a 2.6.15 kernel I recommend to use version 0.2 of lt_hotswap - the latest version reproducable produces oopses and kernel crashes for me.

===Script to eject an optical ultrabay drive===
I configured my system to automatically eject my optical drive in battery mode, because it saves about 500mW which is about 5% when my system is idle.
But when the drive is in use, issuing an eject will result in a kernel ooops/crash.
So the problem is: How do I check if the device is still in use, either by the kernel or by some other process?
The trick is to compile "cdrom and ide_cd" as modules. If the unload of ide_cd failes some other process is still using the device.
<bash>
#!/bin/sh
# disable bay if possible
# saves about 500mW

if modprobe -r ide_cd; then
modprobe -r cdrom
echo "MSTR eject" > /proc/acpi/lths
modprobe ide-cd
modprobe cdrom
else
echo ""
echo "$(fuser -vm /dev/hdc)"
fi
</bash>

[[Category:Drivers]] [[Category:Patches]]

==See also==
* [[How to hotswap UltraBay devices]]
* [[How_to_hotswap_the_UltraBase]]

How to hotswap Ultrabay devices

2007-12-26T21:44:13Z

Marcmerlin: /* When using the <tt>ata_piix</tt> driver */

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

==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 'ide0=noprobe hda=noprobe hdb=noprobe' in your grub/lilo config (adjust the drive letters as appropriate and untested).
* 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 'options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe"' to your modprobe.conf is supposed to work too.

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 ultrabady, 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
else
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>

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

===HAL support===

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) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 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]]

Lt hotswap

2007-12-26T21:39:38Z

Marcmerlin: /* Features */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
=== lt_hotswap ===
The <tt>lt_hotswap</tt> kernel module enables hot-swapping of UltraBay disk drives under Linux, with DMA support.
|}
===Features===
*enable hotswapping of [[UltraBay]] drives if you have to use the old piix/ide-disk drive instead of ata_piix which supports hotswap natively
*automatic IDE unregistering on [[ibm-acpi]] eject event
*leaves DMA support intact

===Limitations===
* Requires [[ibm-acpi]] to be running (does not work with [[APM]]).
* Works only in conjunction with the <tt>ide-disk</tt> driver (recent ThinkPad models use <tt>ata_piix</tt> instead).
* Does '''not''' get on well with idectl. Use one, or the other, or crash.
* On Kernel >= 2.6.19 "#include <linux/config.h>" in lt_hotswap.c has to be replaced by "#include <linux/autoconf.h>"
* On Kernel >= 2.6.22, "create_proc_ide_interfaces();" in lt_hotswap.c has to be replaced by "ide_proc_register_port(&ide_hwifs[num]);".
* On Kernel >= 2.6.23, all occurrences of "acpi_bus_generate_event" in lt_hotswap.c need to be replaced by "acpi_bus_generate_proc_event".

===Project Homepage / Availability===
*Project page: http://www.sourceforge.net/projects/lths
*Latest version: http://prdownloads.sourceforge.net/lths/lt_hotswap-0.3.6.tar.gz?download

Development and discussion of lt_hotswap is currently being held in
[[Mailinglists#Linux-ThinkPad Mailinglist|Linux-ThinkPad Mailinglist]].

===Installation===
In order to use the driver you must use ACPI and also have the [[ibm-acpi]] driver linked to your kernel (module or compiled).

When loading the hotswap module, you can use the module parameter: {{bootparm|auto_eject|1}} to automatically unregister the drives IDE interface. This will happen upon popping out the [[UltraBay]] lever.

===Supported models===
The driver has been explicitly reported to work on the following models. It should work on many others as well:
*ThinkPad {{A31p}} (warmswap), {{X22}}, {{X24}}, {{T30}}, {{T22}}, {{T23}}, {{T40}}, {{T42}}

<tt>lt_hotswap</tt> does '''not''' work well on models that require the <tt>ata_piix</tt> driver rather than the generic <tt>ide-disk</tt> IDE driver. See [[problems with SATA and Linux]] for a list, and [[How to hotswap UltraBay devices]] for an alternative solution on these models.

At least for a thinkpad T41p with a 2.6.15 kernel I recommend to use version 0.2 of lt_hotswap - the latest version reproducable produces oopses and kernel crashes for me.

===Script to eject an optical ultrabay drive===
I configured my system to automatically eject my optical drive in battery mode, because it saves about 500mW which is about 5% when my system is idle.
But when the drive is in use, issuing an eject will result in a kernel ooops/crash.
So the problem is: How do I check if the device is still in use, either by the kernel or by some other process?
The trick is to compile "cdrom and ide_cd" as modules. If the unload of ide_cd failes some other process is still using the device.
<bash>
#!/bin/sh
# disable bay if possible
# saves about 500mW

if modprobe -r ide_cd; then
modprobe -r cdrom
echo "MSTR eject" > /proc/acpi/lths
modprobe ide-cd
modprobe cdrom
else
echo ""
echo "$(fuser -vm /dev/hdc)"
fi
</bash>

[[Category:Drivers]] [[Category:Patches]]

==See also==
* [[How to hotswap UltraBay devices]]
* [[How_to_hotswap_the_UltraBase]]

How to hotswap Ultrabay devices

2007-12-26T21:36:30Z

Marcmerlin: /* Choosing the right driver: new style <tt>ata_piix</tt> vs old style <tt>piix/ide-disk</tt> */

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

==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 'ide0=noprobe hda=noprobe hdb=noprobe' in your grub/lilo config (adjust the drive letters as appropriate and untested).
* 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 'options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe"' to your modprobe.conf is supposed to work too.

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 ultrabady, 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>).

===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
else
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>

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

===HAL support===

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) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 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

2007-12-26T21:35:21Z

Marcmerlin:

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

==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 'ide0=noprobe hda=noprobe hdb=noprobe' in your grub/lilo config (adjust the drive letters as appropriate and untested).
* 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 'options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe"' to your modprobe.conf is supposed to work too.

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 ultrabady, 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>).

===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
else
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>

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

===HAL support===

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) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 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]]

Problems with SATA and Linux

2007-12-26T21:20:16Z

Marcmerlin:

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
Some ThinkPad models use an [[Intel ICH6-M]] SATA/PATA controller for the system hard disk. This causes several complications for Linux installation. The following lists these problems and known workarounds. Note that the details are often version- and distribution-specific.

===Models using a SATA disk interface===
Models using a SATA controller and a SATA system disk:
*ThinkPad {{R60}}, {{R60e}}, {{R61}}
*ThinkPad {{T60}}, {{T60p}}, {{T61}}
*ThinkPad {{X60}}, {{X60s}}, {{X60_Tablet}}, {{X61}}, {{X61s}}, {{X61_Tablet}}
*ThinkPad {{Z60t}}, {{Z60m}}
*ThinkPad {{Z61e}}, {{Z61t}}, {{Z61m}}, {{Z61p}}
Models using a SATA controller and a PATA (IDE) system disk with a SATA-to-PATA bridge:
*ThinkPad {{T43}}, {{T43p}}
*ThinkPad {{R52}}
*ThinkPad {{X41}}, {{X41T}}

{{NOTE|Some of these problems (namely SMART support, power management and disk information) are solved in Linux 2.6.15 with the inclusion of libata pass-through. See the SATA driver [http://linux-ata.org/features.html features], [http://linux-ata.org/software-status.html software status] and [http://linux-ata.org/driver-status.html hardware status].}}
|}

==Hang on resume from suspend to RAM==

Linux kernels prior to 2.6.16 (ata_piix) and 2.6.19 (ahci) do not support suspend and resume for SATA devices. As a result, the machine hangs upon the first disk access after resume. A kernel patch ([http://lkml.org/lkml/2005/5/2/46 LKML posting]) fixes this by adding SATA power management support.

Kernel 2.6.16 and later fixes this problem for most systems. The Thinkpad T60 and X60s still need some patches to get resume working using 2.6.16, see [[Talk:Problems with SATA and Linux#Patch against SATA-resume problem with T60|here]]. The T60p resumes properly with 2.6.17-rc6, the T60 and X60 should also. You need to enable ata_piix and disable AHCI in the bios. The latest fedora (FC5) 2.6.17 kernel seems to have fixed the resume problem on the T60p, still need to disable AHCI though. Applying [http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-5/linux-2.6-console-suspend.patch this FC5 patch] makes suspend-to-ram work with AHCI enabled.

===Patches===
* [http://shamrock.dyndns.org/~ln/linux/sata_pm.2.6.12.diff Patch for kernel 2.6.12]
* [http://shamrock.dyndns.org/~ln/linux/sata_pm.2.6.13-rc5.diff Patch for kernel 2.6.13-rc5]
* [http://lkml.org/lkml/2005/9/23/97 Patch for kernel 2.6.14]
* [http://www.xenotime.net/linux/SATA/2.6.15-rc/libata_suspend.patch Patch for kernel 2.6.15-rc4]
* [http://tpctl.sourceforge.net/tmp/sata_pm.2.6.15-rc6.patch Patch for kernels 2.6.15-rc6 through 2.6.15]

Some distributions already include this patch (e.g., {{Ubuntu}} Breezy, {{Gentoo}}'s gentoo-sources 2.6.15-r1), but some don't (e.g., {{Fedora}} 4). If your distribution doesn't include the patch, you will need to compile your own kernel with this patch included.

===Links===
* RedHat Bugzilla [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169201 bug 169201: "SATA drives fail on laptop suspend"]
* [http://lkml.org/lkml/2005/11/15/385 Fix to libata.h recommended on LKML] in case you get "ata: abnormal state 0x80 on port 0x1F7"
* RedHat Bugzilla [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183138 bug 183138": "SATA failure after pm-suspend/resume ata1: handling error/timeout"]

==Failed resume from suspend to disk==

Suspend to disk (using [[swsusp]] or [[Software Suspend 2]]) needs to load the memory image from the SATA disk. For this to work, you either need an initrd with all the necessary SATA modules, or the SATA drivers compiled into the kernel.

==DVD drive not recognized==

The <tt>ata_piix</tt> SATA driver grabs ownership over the IDE ports when it is loaded, but (by default) does not support PATA ATAPI devices such as the Ultrabay optical drives. Thus, if the <tt>ide</tt> driver is compiled as a module and loaded after <tt>ata_piix</tt>, the DVD drive will not be recognized by either driver.

Either of the following configurations will work:
* For kernel 2.6.14 and newer: enable ATAPI support in the SATA system using {{bootparm|libata.atapi_enabled|1}} (see below; this is experimental).
* Compile IDE into the kernel (non-module).
* Compile both IDE and SATA as modules and make sure IDE is loaded first (the module is called 'ide_generic').

Note that the optical drive must be in the Ultrabay during system boot (Ultrabay device swapping is currently unsupported).

==No DMA on DVD drive==

Using the IDE driver, DMA support cannot be enabled on an Ultrabay optical drive:

# hdparm -d1 /dev/hdc

/dev/hdc:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

As a result, the optical drive is slow, and in particular, too slow to play video DVDs.

One workaround is to use the <tt>ata_piix</tt> driver (instead of the IDE driver) for the optical drive. This requires enabling the ATAPI support of the <tt>ata_piix</tt> driver (which as of 2.6.2x kernels, is working fine but wasn't stable in kernels before 2.6.18). You must also make sure that the IDE driver (<tt>ide-generic</tt>) does not grab the devices before <tt>ata_piix</tt>.

* Grab a recent kernel (must be 2.6.18 or newer)
* Do one of the following:
** Enable the <tt>ata_piix</tt> and <tt>libata</tt> drivers as built-in,
** Enable <tt>ata_piix</tt> and <tt>libata</tt> as modules (this is often the default) and add "<tt>options libata atapi_enabled=1</tt>" to your {{path|/etc/modprobe.conf}} (or the equivalent in your distribution).
* Do one of the following:
** Disable the IDE system.
** Build the IDE driver as built-in (this is often the default) and add the {{bootparm|hdc|noprobe}} kernel argument (e.g., in in {{path|/boot/grub/menu.lst}} or {{path|/etc/lilo.conf}}. Don't forget to run lilo after changes).
** Build the IDE driver as module and add "<tt>options ide hdc=noprobe</tt>" to your {{path|/etc/modprobe.conf}} (or the equivalent in your distribution).
* If you chose to use modules above, regenerate your <tt>initrd</tt> file.

Note : If you are using a ''Debian Sid'' system, and want to use Debian precompiled kernels, then type the following command in a ''root'' shell (This creates a new <tt>initrd</tt> with enabled ATAPI support of <tt>ata_piix</tt> and loads <tt>ata_piix</tt> before the IDE driver):
'''# echo options libata atapi_enabled=1>/etc/modprobe.d/atapienable && update-initramfs -u'''
(this is apparently not necessary with newer kernels)

The following is likely obsolete with recent kernels
Note : If your work was successful, your CD-ROM drive will no longer be accesiible through /dev/hdc, but /dev/scd0 or /dev/sr0.

If this all doesn't work, use {{cmd|lspci -vn|}} to check whether one of the following chipsets is used in the Thinkpad:
{| border="1" cellspacing="0" cellpadding="2"
|-
!PCI ID
!Name
|-
|8086:7111
|Intel 82371AB/EB/MB PIIX4 IDE
|-
|8086:24db
|Intel 82801EB/ER (ICH5/ICH5R) IDE Controller
|-
|8086:25a2
|Intel 6300ESB PATA Storage Controller
|}
If yes, enable support for these chipsets has to be enabled by setting
#define ATA_ENABLE_PATA
in {{path|include/linux/libata.h}} (and report your ThinkPad model in the discussion page).

There have been reports that DVD burning doesn't work under this configuration, but it seems to work with kernel 2.6.14 and later (tested on a ThinkPad {{T43}} and {{T43p}} with a [[UltraBay Slim DVD Multi-Burner Plus]]).

===Problem with kernel 2.6.16 kernel and suspend2 2.2.1===
DVD access fails with kernel 2.6.16.* and [[Software Suspend 2|suspend2]] 2.2.1. Thia is fixed by later versions of suspend2, or by deleting the 4000-libata-rollup-2616-rc3.patch (see
[http://lists.suspend2.net/lurker/message/20060322.082452.873dc526.en.html this post notice] by Alexander E. Patrakov).

===Links===
* RedHat Bugzilla [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163418 bug 163418: "can't enable DMA on DVD drive"]
* Enabling DMA on a SATA DVD drive, kernel 2.6.18 [http://thomer.com/howtos/dma_on_sata_dvd.html]

==No DMA on system hard disk==

In recent Linux kernels, there are two modules capable of handling the ICH6 disk controller:
* <tt>ata_piix</tt>: the disk shows as {{path|/dev/sda}} and DMA is enabled.
* Generic IDE driver (<tt>ide-disk</tt>): the disk shows as {{path|/dev/hda}} and DMA is disabled.

The simplest way to enable DMA is to force the IDE driver to ignore the system hard disk by passing the {{bootparm|hda|noprobe}} and {{bootparm|hda|none}} kernel argument. The driver will then be handled by the <tt>ata_piix</tt> driver. Note that this will change its device name to {{path|/dev/sda}} (which may require changes in {{path|/etc/fstab}} and the boot loader) and may cause other problems as listed above.

(Observed on a ThinkPad T43 with Fedora Core kernel 2.6.13-1.1526_FC4.)
(Observed on a ThinkPad X40 with Debian kernel 2.6.18-4-686.) [[User:Hendry|Hendry]] 20:05, 11 June 2007 (UTC)

==No SMART support==

Prior to kernel 2.6.15, the Linux SATA system did not support SMART commands (e.g., via smartctl).

The necessary capability is "libata pass-through", which was incorporated into Linux 2.6.15-rc1 and later. A patch is available for older kernels:
* Kernel 2.6.12: http://rtr.ca/dell_i9300/kernel/kernel-2.6.12/03_libata_passthru.patch
* Kernel 2.6.13: http://rtr.ca/dell_i9300/kernel/kernel-2.6.13/02_libata_passthru.patch
* Kernel 2.6.14: http://www.foo.fh-furtwangen.de/~koenigr/02_libata_passthru.fixed.again.patch
* Kernel 2.6.14 with the above suspend-to-RAM patch: http://linux.spiney.org/system/files?file=02_libata_passthru.fixed.patch

After applying the patch, run smartctl with the "-d ata" parameter:
:{{cmdroot|smartctl -d ata -a /dev/sda}}

From smartmontools version 5.37 "-d sat" is preferred to "-d ata". The smartctl command will auto-detect SATA disks so:
:{{cmdroot|smartctl -a /dev/sda}}
should just work. The smartd daemon still requires "-d sat" in /etc/smartd.conf .

==No disk power management==

Prior to kernel 2.6.15, the Linux SATA system did not support power management commands on these models.

The above patches for SMART support resolves this, and in particular enables the following commands:
* {{cmdroot|hdparm -y}} (spin down)
* {{cmdroot|hdparm -S num}} (automatic spin down timeout)
* {{cmdroot|hdparm -B num}} (advanced power management level)
Note that this command is still rejected:
* {{cmdroot|hdparm -M num}} (acoustic management)
(Tested with patched kernels 2.6.13.1 and 2.6.12-4 and a 60GB 7200RPM disk model HTS726060M9AT00.)

Refer to [[How to make use of Harddisk Power Management features]] for details about using
HD power management. Refer to [[Laptop-mode]] if you are interested into spinning down your HD.

==No disk information==

Prior to kernel 2.6.15, on these models the disk information could not be read by the standard commands such as:
*{{cmdroot|hdparm -i /dev/sda}}
*{{cmdroot|hdparm -I /dev/sda}}
The latter is fixed by the above patch for SMART support.

==No swapping of UltraBay device==

The <tt>ata_piix</tt> driver in mainline Linux kernels supports hot-swapping and warm-swapping of PATA and SATA devices. This requires kernel 2.6.18 or newer (with older kernels, you must power off the laptop before swapping such devices). See [[How_to_hotswap_UltraBay_devices#When_using_the_ata_piix_driver|How_to_hotswap_UltraBay_devices]] for further information.

Swapping of the [[UltraBay Slim Battery]] works out-of-the box.

==BIOS error 2010 on user-installed hard disk==

While not a Linux issue, note that there is an issue with installing alternative PATA (IDE) hard disks as the system drive. Unless the disk is one of the few approved disks listed inside the BIOS, you will get an BIOS error 2010 during system boot, and the disk may operate unreliably. See [[Problem with non-ThinkPad hard disks]].

==CompactFlash module doesn't work==

Normally, PATA disks can be replaced with a solid-state [[CompactFlash]] module using a cheap PATA-to-CompactFlash adapter. However, there is a [http://thread.gmane.org/gmane.linux.ide/22400 report] that replacing the system disk with CompactFlash fails on a ThinkPad {{X41}}, possibly due to the SATA-to-PATA bridge. If so, the problem would probably occur also on the {{X41T}}, {{T43}}, {{T43p}} and {{R52}}.
I (KotCzarny) can confirm that {{X41T}} has this issue. READ is OK, but every attempt to do a WRITE results in timeouts as listed in gmane report. A quick and dirty workaround is to use generic ide driver (not sata one) to disable DMA. You won't get high speeds but at least it will work.

==RHEL3.0 Update 7 on T60p==

RHEL3.0 Update 7 will install on a {{T60p}}, but you need to make an adjustment. Both uni-processor and SMP kernels get installed, with the SMP kerrnel the default. However, the SMP kernel can't seem to find the disk drive. You can work around this by use "e" at the GRUB kernel prompt, then on the "kernel" line appending " noapic". After the system boots, you'll want to edit /boot/grub/grub.conf to add the " noapic" option to the kernel line as well.

==Mandriva 2006 on T60==

Mandriva 2006.0 has a problem with SATA on a {{T60}}, to fix this you need to make an adjustment. The install procedure can't seem to find the SATA disk drive, you can work around this by adding the "noapic" kernel option during CD/DVD boot. You *might* need to add this to lilo or GRUB for normal operations, after install completes. The problem with not using apic during normal operations is that you might have problems with power management, please see article on [[Software Suspend 2]]

==Problem burning CD/DVD==

To a CD/DVD problem, try to burn a CD/DVD as "root"-user on command-line with the option "-dummy" and "-v" enabled, do not use K3B or similar. Doing so you will get more informations and waste less CD/DVD's.

Experiment with the parameters "burnfree" and "dev". With cdrecord on debian etch, burnfree seems not work, disable it. With wodim on debian etch: try parameter "dev=/dev/scd0", the default "dev=1,0,0" seems not to work.

==Spurious NCQ completions==

The HDD firmware support for NCQ appears to be buggy ([http://lkml.org/lkml/2007/6/6/15 LKML posting] and [http://lkml.org/lkml/2007/6/6/195 LKML posting]).

The recent firmware upgrade to version SBDIC7UP ([http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-63685 Lenovo support]), didn't help.

Anyway, after months of keeping NCQ enabled despite this warning, I've had no corruptions. It could be harmless, but you are advised to be careful.

How to hotswap Ultrabay devices

2007-12-26T21:03:51Z

Marcmerlin:

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

==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
ide0=noprobe hda=noprobe hdb=noprobe in your grub/lilo config
(adjust the drive letters as appropriate and untested).
* if piix is built in as a module
* you can move out the module in
/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
'options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe'
to your modprobe.conf is supposed to work too.

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 ultrabady, 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>).

===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
else
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>

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

===HAL support===

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) || Intel 82801FBM (ICH6-M)
|-
| 8086_24ca || 237358U (T40) || Intel 82801DBM (ICH4-M)
|-
| 8086_27c4 || X60 || Intel 82801GBM (ICH7 Family)
|-
| 8086_27df || Z61p, T60, T60p || Intel 82801GBM/GHM (ICH7 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]]

Tp smapi

2007-12-26T03:36:07Z

Marcmerlin: /* Z series */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
The <tt>tp_smapi</tt> kernel module exposes some features of the ThinkPad hardware/firmware via a <tt>sysfs</tt> interface. Currently, the main implemented functionality is control of battery charging and extended battery status. It also includes an improved version of the [[HDAPS]] driver. The underlying hardware interfaces are [[SMAPI support for Linux|SMAPI]] and direct access to the embedded controller.

For older ThinkPad models, see also [[tpctl]].

{{WARN|This driver uses undocumented features and direct hardware access. It thus cannot be guaranteed to work and could conceivably damage your computer (though so far no incidents have been reported).}}
|}

===Features===
*Battery charge/discharge control
*Battery status information

===Project Homepage / Availability===
* Project page: http://tpctl.sourceforge.net/
* You need to [http://sourceforge.net/project/showfiles.php?group_id=1212&package_id=171579 download] only the <tt>tp_smapi</tt> package.

===Installation===
====Installation from source====
You will need the kernel headers and makefiles corresponding to your current kernel version. On {{Fedora}}, this means {{cmdroot|yum install kernel-devel-$(uname -r)}} .

:{{cmdroot|tar xzvf tp_smapi-0.33.tgz}}
:{{cmdroot|cd tp_smapi-0.33}}

Then, either compile and load the driver within the current working directory (for testing):
:{{cmdroot|make load}}
OR compile and install into the kernel's module path:
:{{cmdroot|make install}}

If you use the [[HDAPS]] driver, add <tt>HDAPS=1</tt> to also patch the <tt>hdaps</tt> for compatibility with <tt>tp_smapi</tt> (this requires a kernel source tree matching the current kernel).
Again, either load the driver within the current working directory:
:{{cmdroot|1=make load HDAPS=1}}
OR install into the kernel's module path:
:{{cmdroot|1=make install HDAPS=1}}

To prepare a stand-alone patch against the current kernel tree (including
a patch against <tt>hdaps</tt> and new <tt>Kconfig</tt> entries):
:{{cmdroot|make patch}}

To delete all autogenerated files:
:{{cmdroot|make clean}}

The original kernel tree is never modified by any these commands.
The {{path|/lib/modules}} directory is modified only by {{cmdroot|make install}}.

====Installation in Gentoo====
The {{Gentoo}} portage system carries a [http://packages.gentoo.org/packages/?category=app-laptop;name=tp_smapi tp_smapi package], which follows the latest version pretty closely. On a Gentoo system, you can install and load as follows.

If you use the [[HDAPS]] driver, do this first:

* Configure <tt>hdaps</tt> as module in your kernel
* Add the <tt>HDAPS</tt> use flag in {{path|/etc/make.conf}}
* {{cmdroot|rmmod hdaps}}

Then:

* {{cmdroot|emerge tp_smapi}} (or install tp_smapi with hdaps support manually, as above)
* {{cmdroot|echo "tp_smapi" >> /etc/modules.autoload.d/kernel-2.6}}
* {{cmdroot|echo "hdaps" >> /etc/modules.autoload.d/kernel-2.6}}

Then reboot, or run:
* {{cmdroot|modprobe tp_smapi}}
* {{cmdroot|modprobe hdaps}}

====Installation on Debian unstable (sid) or testing (lenny)====
Debian now contains the [http://packages.debian.org/tp-smapi packaged module source] for use with module-assistant.

* {{cmdroot|apt-get install tp-smapi}}
* {{cmdroot|m-a -t a-i tp-smapi}}

====Installation on Ubuntu/Debian====
Installation on Ubuntu or Debian is quite easy, but there are a few things to look after:

To get your system ready for compiling code, install the build-essentials (as root, of course, as all of the following comands; Ubuntu users have to prepend 'sudo' to every line and enter their own password when prompted):
<pre><nowiki>apt-get install build-essential</nowiki></pre>

To get tp_smapi to work, obtain the latest source as mentioned above and unpack it. If you want to use HDAPS, you need to install the kernel source matching te kernel you are running. To do so, issue this:
<pre><nowiki>uname -r</nowiki></pre>
This will give you the version of your current kernel. As Ubuntu adds '-generic' to the kernel-version, the following command works for Debian users only:
<pre><nowiki>apt-get install linux-source-`uname -r`</nowiki></pre>
Ubuntu users use the kernel-version they got by the command before, e.g. 'linux-source-2.6.20'

Now change to the tp_smapi dir:
<pre><nowiki>cd tp_smapi-X.YY</nowiki></pre> (X.YY being the version-number of [[tp_smapi]])
and make and install tp_smapi as instructed above.

If you get an error that the kernel version isn't matching (or that you need to set KSRC/KBUILD), please check that there is a symlink from the modules dir to the kernel source:
<pre><nowiki>root@localhost:~#ls -l /lib/modules/2.6.20-16-generic
lrwxrwxrwx 1 root root 28 2007-02-02 08:39 source -> /usr/src/linux-source-2.6.20</nowiki></pre>
Create the link if the line above is not existent:
<pre><nowiki>root@localhost:~#ln -s /usr/src/linux-source-2.6.20 /lib/modules/2.6.20-16-generic/source</nowiki></pre>

Now the following will build and install the correct modules to their locations:
<pre><nowiki>make install HDAPS=1</nowiki></pre>
To make sure your system loads the modules at boot time, do this:
<pre><nowiki>echo "tp_smapi" >> /etc/modules
echo "hdaps" >> /etc/modules</nowiki></pre>
and update your initramfs:
<pre><nowiki>update-initramfs -u</nowiki></pre>

To get tp_smapi running now, just load the modules:
<pre><nowiki>modprobe -a tp_smapi hdaps</nowiki></pre>

This description was tested on Kubuntu 'Feisty Fawn' and should work on all Debian-based distros with minor tweaks.

'''EDIT:''' Works on Kubuntu 7.10 ("Gutsy Gibbon"), too

===Battery charge control features===
To set the thresholds for starting and stopping battery charging (in percent of current full charge capacity):
:{{cmdroot|echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh}}
:{{cmdroot|echo 70 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh}}
:{{cmdroot|cat /sys/devices/platform/smapi/BAT0/*_charge_thresh}}
{{HINT|Battery charging thresholds can be used to keep Li-Ion ad Li-Polymer batteries partially charged, in order to [[Maintenance#Battery_treatment|increase their lifetime]].}}
To prevent charging for 17 minutes (regardless of thresholds):
:{{cmdroot|echo 17 > /sys/devices/platform/smapi/BAT0/inhibit_charge_minutes}}
{{HINT|Charge inhibiting can be used to reduce the power draw of the laptop, in order to use an under-spec power supply that can't handle the combined power draw of running and charging. It can also be used to control which battery is charged when [[How to use UltraBay batteries|using an Ultrabay battery]].}}

To cancel charging preventation:
:{{cmdroot|echo 0 > /sys/devices/platform/smapi/BAT0/inhibit_charge_minutes}}

To force battery discharging (even if connected to AC):
:{{cmdroot|echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge}}
{{HINT|This can be used to choose which battery is discharged when [[How to use UltraBay batteries|using an UltraBay battery]].}}

To cancel forced discharge:
:{{cmdroot|echo 0 > /sys/devices/platform/smapi/BAT0/force_discharge}}

===Battery status features===
To view extended battery status such as charging state, voltage, current, capacity, cycle count and model information:

<pre>
# cat /sys/devices/platform/smapi/BAT0/installed
# cat /sys/devices/platform/smapi/BAT0/state # idle/charging/discharging
# cat /sys/devices/platform/smapi/BAT0/cycle_count
# cat /sys/devices/platform/smapi/BAT0/current_now # instantaneous current
# cat /sys/devices/platform/smapi/BAT0/current_avg # last minute average
# cat /sys/devices/platform/smapi/BAT0/power_now # instantaneous power
# cat /sys/devices/platform/smapi/BAT0/power_avg # last minute average
# cat /sys/devices/platform/smapi/BAT0/last_full_capacity
# cat /sys/devices/platform/smapi/BAT0/remaining_percent
# cat /sys/devices/platform/smapi/BAT0/remaining_running_time
# cat /sys/devices/platform/smapi/BAT0/remaining_charging_time
# cat /sys/devices/platform/smapi/BAT0/remaining_capacity
# cat /sys/devices/platform/smapi/BAT0/design_capacity
# cat /sys/devices/platform/smapi/BAT0/voltage
# cat /sys/devices/platform/smapi/BAT0/design_voltage
# cat /sys/devices/platform/smapi/BAT0/manufacturer
# cat /sys/devices/platform/smapi/BAT0/model
# cat /sys/devices/platform/smapi/BAT0/barcoding
# cat /sys/devices/platform/smapi/BAT0/chemistry
# cat /sys/devices/platform/smapi/BAT0/serial
# cat /sys/devices/platform/smapi/BAT0/manufacture_date
# cat /sys/devices/platform/smapi/BAT0/first_use_date
# cat /sys/devices/platform/smapi/BAT0/temperature # in milli-Celsius
# cat /sys/devices/platform/smapi/ac_connected
</pre>

The raw status data is also available, including some fields not listed above (in case you can figure them out):

:{{cmdroot|cat /sys/devices/platform/smapi/BAT0/dump}}

In all of the above, replace <tt>BAT0</tt> with <tt>BAT1</tt> to address the 2nd battery.

Note that the battery status readout conflicts with the stock [[HDAPS|hdaps]] driver, so if you use <tt>hdaps</tt> you will need to load <tt>tp_smapi</tt> using {{cmdroot|1=make load HDAPS=1}} (see [[#Bundled hdaps driver|Bundled hdaps driver]] below).

On [[ACPI]]-enabled systems, most of above information is also available through the files under {{path|/proc/acpi/battery}}. However, the ACPI interface does not include the instantaneous power and cycle count readouts, and does not work well when [[How to use UltraBay batteries|hotswapping UltraBay batteries]].

===Other features===

There is also [[sysfs]] attribute for making direct SMAPI requests to the SM BIOS firmware. Don't touch it unless you really know what you're doing. Example:
# echo '211a 100 0 0' > /sys/devices/platform/smapi/smapi_request; cat /sys/devices/platform/smapi/smapi_request
211a 34b b2 0 0 0 'OK'
The "4b" in the 2nd value, converted to decimal, is 75: the current charging stop threshold (stop_charge_thresh).

===Bundled <tt>hdaps</tt> driver===

The tp_smapi package includes a modified version of the <tt>hdaps</tt> Linux kernel driver used by the [[HDAPS]] system. To use <tt>tp_smapi</tt> and <tt>hdaps</tt> concurrently, you '''must''' use the modified version.

To build the modified version, simply append the <tt>HDAPS=1</tt> parameter to the <tt>make</tt> command (see [[#Installation|Installation]] above):
:{{cmdroot|1=make load HDAPS=1}}
or
:{{cmdroot|1=make install HDAPS=1}}

If you don't do that, you will not be able to load <tt>tp_smapi</tt> (and its support module <tt>thinkpad_ec</tt>) when <tt>hdaps</tt> is loaded, and vice versa. You can use <tt>rmmod</tt> to switch between these modules.

Note that some of the battery status is also visible through ACPI ({{path|/proc/acpi/battery/*}}), independently of <tt>tp_smapi</tt>.

The modified <tt>hdaps</tt> has several changes:
* The <tt>hdaps</tt> driver in mainline kernels conflicts with the extended battery status (they use the same IO ports). The modified <tt>hdaps</tt> coordinates this access through the bundled <tt>thinkpad_ec</tt> driver.
* The modified <tt>hdaps</tt> driver fixes reliability and improves support for recent ThinkPad models (*60 and newer), since unlike the mainline driver, it correctly follows the Embedded Controller communication protocol.
* Several other improvements, such as the ability to control the polling rate.

===Troubleshooting===

If you get "<tt>thinkpad_ec: no ThinkPad embedded controller!</tt>" when trying to load the module on a supported model listed below, you should [[BIOS_Upgrade|upgrade your BIOS]]. Some early BIOS (like 1.x on the X31) don't handle the embedded controller.

===Model-specific status===

<div style="font-size: 92%">
{| border="1" cellspacing="0" cellpadding="2"
|+<tt>tp_smapi</tt> feature support matrix
|-
! colspan=11 style="text-align:center;background:#efefef;" |
=====A series=====
|-
{{tp_smapi/model_status_table_header}}
|-
! {{A22p}} 2629-USG
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{A30}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! colspan=11 style="text-align:center;background:#efefef;" |
=====G series=====
|-
{{tp_smapi/model_status_table_header}}
|-
! {{G41}}
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || || ||
|-
! colspan=11 style="text-align:center;background:#efefef;" |
=====R series=====
|-
{{tp_smapi/model_status_table_header}}
|-
! {{R31}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cunk}} || || || No SMAPI BIOS
|-
! {{R40}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{R50}}
| {{Cunk}} || {{Cno}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{R50e}} 1834-JAG
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{R50p}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{R51}} 18*
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes|text=}} 0 || 0.32 || 3.22 || Machine types 1829, 1830, 1831 and 1836
|-
! {{R51}} 28*
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || 1.29 || Machine types 2883, 2887, 2888, 2889, 2894 and 2495
|-
! {{R52}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes|text=}} 0 || 0.33 || 1.29 ||
|-
! {{R60}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} ||{{Cyes}} || {{Cno|text=}} 1 || 0.33 || ||
|-

! colspan=11 style="text-align:center;background:#efefef;" |

=====T series=====
|-
{{tp_smapi/model_status_table_header}}
|-
! {{T20}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cunk}} || || || Has SMAPI BIOS but no function is supported. EC LPC3 protocol fails.
|-
! {{T22}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cunk}} || || || Has SMAPI BIOS but no function is supported. EC LPC3 protocol fails.
|-
! {{T23}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{T30}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{T40}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{T40p}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{T41}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{T41p}} 2373-AM9
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cyes}} || {{Cyes|text=}} 1 || 0.32 || 3.20 || EC v3.04
|-
! {{T42}}
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{T42p}} 2373-KXU
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes|text=}} 1 || 0.32 || 3.21 || Stop charge threshold works in Windows, but dmesg says "__get_real_thresh: cannot get stop_thresh of bat=0: Function is not supported by SMAPI BIOS".
|-
! {{T42p}} 2373-KUU
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{T43}} 2686
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes|text=}} 0 || 0.33 || 1.27 ||
|-
! {{T43p}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cyes|text=}} 0 || || ||
|-
! {{T60}}
| {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 7 || 0.32 || ||
|-
! {{T60p}} 8743-CTO
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes|text=}} 1 || 0.32 || ||
|-
! {{T61}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 1 || 0.32 || || [http://ubuntuforums.org/showthread.php?p=3146719 ref]
|-
! {{T61p}} 6457-7XG
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 1 || 0.32 || || [http://ubuntuforums.org/showthread.php?p=3146719 ref]
|-
! colspan=11 style="text-align:center;background:#efefef;" |

=====X series=====
|-
{{tp_smapi/model_status_table_header}}
|-
! {{X20}} 2662-31G
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{X24}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{X30}}
| {{Cno}} || {{Cno}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{X31}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{X32}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{X40}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 3 || 0.32 || 2.08 || EC v1.62
|-
! {{X41}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 3 || 0.32 || ||
|-
! {{X41_Tablet}}
| {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cno|text=}} (see ref) || 0.32 || || [http://sourceforge.net/mailarchive/message.php?msg_name=4757BD30.8080808%40ugcs.caltech.edu ref] ||
|-
! {{X60}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 6 || || 2.07 || EC v1.10, 2.6.20 issue (see discussion)
|-
! {{X60s}}
| {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{X61s}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 6 / 3 || 0.32 || || [http://www.slackwiki.org/ThinkPad_X61s ref] says 3 but conflicting report received
|-
! {{X60_Tablet}}
| {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || || || [http://luke.no-ip.org/x60tablet/ ref] [http://rad.bioinfo.ulaval.ca/hardware/x60tablet ref]
|-
! {{X61_Tablet}}
| {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cyes}} || {{Cno|text=}} 6 || 0.32 || ||
|-
! colspan=11 style="text-align:center;background:#efefef;" |

=====Z series=====
|-
{{tp_smapi/model_status_table_header}}
|-
! {{Z60m}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{Z60t}}
| {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || || ||
|-
! {{Z61m}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes|text=}} 0 || 0.32 || ||
|-
! {{Z61t}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || || || [https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/45014 ref]
|-
! {{Z61p}}
| {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || || ||
|}
</div>

SMAPI capabilities may depend on the BIOS version as well, so upgrading to the latest version of the BIOS might provide more SMAPI functions (especially true for long-lived BIOS with lots of releases, like the TP-1R).

Please update the above and report your experience on the [[Talk:tp_smapi|discussion]] page. If the module loads but gives a "<tt>not supported</tt>" or "<tt>not implementeded</tt>" error when you try to use some specific file in {{path|/sys/devices/platform/smapi/}}, please report the <tt>dmesg</tt> output and whether the corresponding functionality is available under Windows - maybe your ThinkPad just can't do that.

While at it, you may also want to add your laptop to the [[list of DMI IDs]].

=====HDAPS axis orientation=====
1 The HDAPS axis orientation is set using the <tt>invert</tt> module parameter (at load time) or sysfs attribute (at runtime). The tp_smapi's hdaps driver supports all 8 possible sensor orientations (inversion and swapping). You can use [[HDAPS#Visualisation_of_ThinkPad_orientation|hdaps visualisation]] to check if the settings is correct.

<tt>invert</tt> is an integer between 0 and 7, whose meaning is as follows. Let <tt>X</tt> and <tt>Y</tt> denote the hardware readouts. Let <tt>R</tt> denote the laptop's roll (tilt left/right), and let <tt>P</tt> denote the laptop's pitch (tilt forward/backward). The possible values are as follows:
invert=0: R= X P= Y (same as mainline)
invert=1: R=-X P=-Y (same as mainline)
invert=2: R=-X P= Y (new)
invert=3: R= X P=-Y (new)
invert=4: R= Y P= X (new)
invert=5: R=-Y P=-X (new)
invert=6: R=-Y P= X (new)
invert=7: R= Y P=-X (new)

[[Category:Drivers]] [[Category:Patches]]

===Tools using this driver===

The driver's interface can be accessed directly through the files under {{path|/sys/devices/platform/smapi}}, or via the following tools:
* [[KThinkBat]] - display battery status on the KDE <tt>kicker</tt> panel.
* [[gkrellm-ThinkBat]] - battery status plugin for Gkrellm2
* {{CodeRef|thinkpad-smapi.sh}} - script to display various SMAPI information using tp_smapi module.

Problems with fglrx

2006-07-22T21:17:29Z

Marcmerlin: /* Perpetual Mesa GLX Indirect on Debian */

This page discusses issues with the ATI proprietary [[fglrx]] display driver.

== Known Troubles and Solutions ==

=== X-specific issues ===

ATI proprietary drivers version 8.21.7 and later work with x.org 6.9.

If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.

After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch or upgrade.

Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. These issues have been fixed with later ATI drivers (> 8.21.7) so you can simply upgrade if you are running a more modern kernel.

=== No hardware acceleration ===

====Acceleration lost after driver update====
If you lose hardware acceleration after a driver update this can be caused by an old fglrx kernel module being loaded.

Check out {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=grep fglrx modules.dep}}. 
If grep finds multiple lines you nailed down the problem. All you have to do now is to delete any versions of the module (look at the filedate) but the most current one. Then run {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.

To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|yum install libstdc++.so.5}}

====radeonfb framebuffer====
Another possible cause for broken hardware acceleration (2D and 3D) is the radeonfb framebuffer: Switching to vesafb or vesafb-tng is reported to solve the problem on some systems. Also it has proven helpful to not perform {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.

====Perpetual Mesa GLX Indirect on Debian====
If you've done everything right and you're still seeing:

$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.4.1)

try this:

# mkdir -p /usr/X11R6/lib/modules/dri
# ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri

Thanks to Maciej Matysiak for the clear debug [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
gandalf:~$ LIBGL_DEBUG=verbose fglrxinfo
libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/fglrx_dri.so failed (/usr/X11R6/lib/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to find driver: fglrx_dri.so
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.4.2)

instead of that:
gandalf:~$ LIBGL_DEBUG=verbose fglrxinfo
libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so
libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
drmOpenByBusid: busid is PCI:1:0:0
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports PCI:1:0:0
Can't open configuration file /home/merlin/.drirc: No such file or directory.
fglrx: DPD supported.
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)
OpenGL version string: 2.0.5879 (8.26.18)

I have contacted ATI to add that info by default, the mesa guys to do that in glxinfo too, as well as the debian packager to fix the debian packaging bug (2006/07/22), so hopefully the situation will improve soon

=== Softlink hell ===
The [[fglrx]] installer replaces the standard X.org OpenGL implementation (Mesa) with its own files, potentially causing collisions with the distribution's file and package management. It is best to install the driver via a package built for your distribution, which will typically include the necessary kludges to make things work. See the [[fglrx]] page for pointers.

====Discussion====
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}

For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.

=====Gentoo=====
{{Gentoo}} has built in tools for managing the OpenGL symlinks. They seem to be replacing the old tool with a new one, so one of the following should work for you:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

<pre>
# rm /usr/lib/libGL.so*
# rm /usr/X11R6/lib/libGL.so*
# cd /usr/X11R6/lib
# cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .
# ln -s libGL.so.1.2 libGL.so.1
# ldconfig
</pre>

=== Troubles using software suspend ===
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.
The problem is acknowledged in ATI's release notes and in knowledge base entry <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=218 737-218]. Driver version 8.19.10 has "initial support for Suspend and Resume" but is working very nicely for most people (verified on T43, T43p and T42) without vbetool.

If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/etc/hibernate/hibernate.conf}}. Be aware though that it breaks suspend/resume for drivers beginning with version 8.19.10, so remember to disable it again when upgrading.

{| cellspacing="0" cellpadding="2" border="1"
|+ tested with the following configurations
!model!!distro||kernel!!fglrx!!PM!!success!!comments
|-
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||
|-
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]
|-
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||
|-
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)
|-
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool
|-
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)
|-
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled
|-
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled
|-
|{{R50p}}||???||???||8.19.10||swsusp||yes||
|-
|{{T43p}}||Debian sid||2.6.14||8.19.10||Suspend to RAM||yes||without vbetool or UseDummyXServer, those two ''break'' the resume process here, with DRI enabled
|-
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 2.6.15]||8.22.5||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled - console is garbled until switching back from X
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 2.6.15]||8.22.5||suspend2 2.2||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{T43}}||SUSE 10.1||2.6.16||8.25.18||swsusp||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{T43}}||SUSE 10.1||2.6.16||8.25.18||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{T60p}}||Kubuntu 6.06||2.6.15||8.25.18||swsusp||no||Switching to VT to suspend: no resume, X restarts; Not switching: suspend works, garbled X display on resume, later X restarts
|-
|{{T60p}}||Kubuntu 6.06 Text Mode||2.6.15||---||swsusp||yes||suspend works in textmode after rmmod fglrx.
|}

=== Troubles with large RAM ===
Version 8.14.13 (and probably earlier versions) of the driver does not seem to be able to cope with large amounts of RAM: with 512 MB it works, with 1.5 GB it crashes the machine as soon as X is started. The problem is present only if the <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.

Version 8.16.20 fixes the problem.

===Display switching ===
The switching between internal and external display doesn't work with fglrx versions <= 8.24.8, because the driver blocks messing around with the chipset via ACPI. If you want to use this feature (i.e. during presentations), you should use the <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20). Or boot notebook with CRT connected, it will automatically detect it and display on both.

===Composite Support===
ATI has not officially supported composite windowing (alpha channel) enabling hardware acclerated translucent windows (primarily for 'eye candy.') Enabling Composite in KDE and the fglrx driver results in a very pretty desktop but unacceptably slow performance on a T43p with ATI's FireGL T2. It is still unusable in its current state (as of driver 8.25.18).

ATI promises support in the future when composite is officially supported by Xorg. Discussion of current status of drivers can be found in the Rage3d forums' (http://rage3d.com/board) Linux area.

There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 7.0 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.

===Hardlock on X logout===
Up from driver version 8.19.10 you will experience a system hard lock when logging out from X, if the session manager (kdm/gdm) is not properly configured. You have to tell the session manager to restart X.

In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
AlwaysRestartServer=true

Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239

Another reason of hardlock my be using the wrong AGP driver. Make sure that you have proper drivers for your motherboard loaded before fglrx: (gentoo: {{path|/etc/modules.autoload.d/kernel-2.6}}):
intel-agp
fglrx

A common problem seems to be mistakenly using ATI Chipset drivers instead of Intel.

Information from gentoo bugtracker: http://bugs.gentoo.org/show_bug.cgi?id=113685

===Cannot switch to VT===

At least with a T60p (Mobility Fire GLV5200) on Kubuntu 6.06 and fglrx 8.25.18 it is not possible to switch to a VT from X (Using Alt+Fn); Display becomed dark and the system freezes. CTRL+ALT+BKSPCE doesn't return to console, instead X restarts (Seems to be a kdm configuration feature from Kubuntu). When trying to do console login only every second attempt succeeds, otherwise it yields a black display.

http://ati.cchtml.com/show_bug.cgi?id=37

===Flickering Display===

Some people have reported problems with their display flickering when using ati-drivers newer than 8.14.13. The problem is unclear
(possibly associated with an incorrect modeline setting) and no known solution exists except to use the open source radeon drivers.
You can follow this problem here: http://ati.cchtml.com/show_bug.cgi?id=248

===Error messages in system log===

If you find something like the following in {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

try to execute the following line and reload the fglrx module:

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].

===Hang when logging out===

A common problem is that when logging out from X, instead of gettign the KDM or GDM prompt, the system hangs.

This is discussed, including workarounds here: http://ati.cchtml.com/show_bug.cgi?id=239

===No power saving when CRT in use===

When both CRT and LCD are in use, power saving cannot be enabled.

This is reported here: http://ati.cchtml.com/show_bug.cgi?id=304

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]