scsi vs ata ?
|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
 |
scsi vs ata ?
by Dan Sawyer
::
Rate this Message:
All,
Which is the more common mapping for hard drives in current distributions, hda or sda? I am trying to make ultra bay hot swap to work. Does it depend on an hda or sda mapping? Is it independent of hda versue sda? Thanks, Dan -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Dmitry E. Mikhailov
::
Rate this Message:
On Thursday 19 June 2008 07:45:31 pm Dan Sawyer wrote:
> All, > > Which is the more common mapping for hard drives in current > distributions, hda or sda? I am trying to make ultra bay hot swap to > work. Does it depend on an hda or sda mapping? Is it independent of hda > versue sda? > > Thanks, > Dan Almost all current distributions use SCSI subsystem. To be more correct, they use SATA subsystem even for PATA disks, and SATA is SCSI subsystem. So you'd get something like SDA. With PATA subsystem, disks were named HDx, where 'x' is 'a' for primary master, 'b' for primary slave, 'c' for secondary master, 'd' for secondary slave. With SCSI subsystem disks are enumerated one-by-one according to their place on the bus. If we got initially 3 disks: 1st SCSI card - 1st and 2nd disk and 2nd SCSI card, 1st disk: we got sda (1-1), sdb (1-2), sdc (2-1). If disk 1-2 is removed, after reboot we got sda (1-1) and sdb (2-1). So you'd better use EXT3 filesystem's labels. [root@ibm ~]# cat /etc/fstab LABEL=/ / ext3 rw,noatime 1 1 LABEL=/boot /boot ext3 defaults 1 2 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 LABEL=SWAP-sda2 swap swap defaults 0 0 [root@ibm ~]# e2label /dev/sda1 /boot [root@ibm ~]# e2label Usage: e2label device [newlabel] Best regards, Dmitry -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Tino Keitel-3
::
Rate this Message:
On Thu, Jun 19, 2008 at 06:45:31 -0700, Dan Sawyer wrote:
> All, > > Which is the more common mapping for hard drives in current > distributions, hda or sda? I am trying to make ultra bay hot swap to > work. Does it depend on an hda or sda mapping? Is it independent of hda > versue sda? I works way better (no DMA problems and such) with the libata, which you see as sda. See http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices for details. Regards, Tino -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Dan Sawyer
::
Rate this Message:
Yes, the motivation was ultra bay hot swap. This works on DVD and CD
drives. Hard drive installs work. However hard drive removal result in
a hard kernel hang. The script gets to the beep successfully but then
the hard hang. Unfortunately there are no log entries. (the latest
kernel patches are installed)
Is there a way to debug this? Thanks - Dan Tino Keitel wrote: On Thu, Jun 19, 2008 at 06:45:31 -0700, Dan Sawyer wrote: |
|
|
Re: scsi vs ata ?
by Dmitry E. Mikhailov
::
Rate this Message:
On Friday 20 June 2008 08:17:10 am Dan Sawyer wrote:
> Yes, the motivation was ultra bay hot swap. This works on DVD and CD > drives. Hard drive installs work. However hard drive removal result in a > hard kernel hang. The script gets to the beep successfully but then the > hard hang. Unfortunately there are no log entries. (the latest kernel > patches are installed) > > Is there a way to debug this? Hot remove isn't just hardware. It's software too. 1) close files on this drive 2)unmount filesystems 3)flush caches 4)instruct kernel to remove SCSI device 5)do hardware steps to remove If you don't do any of steps 1-4, kernel would wait for HDD forever and HDD wouldn't respond because it is just not there. As you wrote, there's some sort of script. Please let me see it. Post here as an attachment or provide a link. Best regards, Dmitry -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Jon Dowland-19
::
Rate this Message:
On Thu, Jun 19, 2008 at 06:45:31AM -0700, Dan Sawyer wrote:
> All, > > Which is the more common mapping for hard drives in > current distributions, hda or sda? I am trying to make > ultra bay hot swap to work. Does it depend on an hda or > sda mapping? Is it independent of hda versue sda? I'm also working on ultrabay hot swap (as a patch for acpi-support in Debian/Ubuntu): please see <http://bugs.debian.org/388160>. I think some important libata fixes have gone into the kernel in >= 2.6.26. With 2.6.25, I cannot convince libata to let go of the bay device. If you're finding that you are going to hard-code /dev/[sh]d? into a script I think you may want to rethink how you are doing it. -- Jon Dowland -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Dan Sawyer
::
Rate this Message:
Thanks for the reply,
I am using the scripts at: http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices The eject gets to the beep at the end of the script. No files have been loaded so the only relevant steps are 4 and 5. Are they part of the scrip? Thanks - Dan Dmitry E. Mikhailov wrote: On Friday 20 June 2008 08:17:10 am Dan Sawyer wrote: |
|
|
Re: scsi vs ata ?
by Dan Sawyer
::
Rate this Message:
Jon,
This has been tried both with and without patches previously posted on this list. Have you tried the .26 kernel? Dan Jon Dowland wrote: On Thu, Jun 19, 2008 at 06:45:31AM -0700, Dan Sawyer wrote: |
|
|
Re: scsi vs ata ?
by Jon Dowland-19
::
Rate this Message:
On Fri, Jun 20, 2008 at 06:51:03PM -0700, Dan Sawyer wrote:
> This has been tried both with and without patches previously posted on > this list. Have you tried the .26 kernel? Not until today, I'm just about to try a git HEAD from yesterday. Unfortunately I've been waylaid by regressions in pm-utils and xorg (being unable to see my display after suspend and unable to type my passphrase due to keymap issues I haven't had a chance to actually get back to the dock/bay stuff :( ) I'm surprised to see that thinkwiki page being up-to-date wrt those patches. Last time I looked it was still talking about ibm-acpi and hdparm's idectl tool. -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Jon Dowland-19
::
Rate this Message:
On Sat, Jun 21, 2008 at 05:01:20PM +0100, Jon Dowland wrote:
> Not until today, I'm just about to try a git HEAD from yesterday. It worked! booted machine with the bay in with a dvd-rom it was picked up by libata I believe - hard drive was sd* and dvd-rom was sg*. Temporary diversion to label all my filesystems and correct /etc/fstab undock instruction cut off the sg device without spewing death all over the dmesg redock picked it up, automounted and started playing the dvd inside I don't currently have a hard drive for that bay but I am thinking of picking up an adaptor and a drive and giving it a go. -- Jon Dowland -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Dmitry E. Mikhailov
::
Rate this Message:
On Saturday 21 June 2008 07:17:18 am Dan Sawyer wrote:
> Thanks for the reply, > > I am using the scripts at: > > http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices Really nice script! > The eject gets to the beep at the end of the script. No files have been > loaded so the only relevant steps are 4 and 5. Are they part of the scrip? I think the best way to test is doing everything by hand. So, 1st is to connect bay with HDD to the laptop. It doesn't matter what's on that HDD, we wouldn't even try mounting it. Boot single-user: add option 'single' (with no quotes) to your kernel parameters at boot time. That would allow us to remove any possible interference from automount services etc. Once you got root commandline, check that you have ata_piix module: [root@ibm ~]# lsmod|grep piix ata_piix 20996 3 libata 140752 1 ata_piix Take an initial look at your /dev/ dir. It could look like this: [root@ibm ~]# ls /dev/sd* /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 Then flush caches and instruct kernel (SCSI hostadapter1) to detect the drive. [root@ibm ~]# sync [root@ibm ~]# echo 0 0 0 > /sys/class/scsi_host/host1/scan Then take a look at /dev again: it should find new sdb: [root@ibm ~]# ls /dev/sd* /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sdb /dev/sdb1 If /dev/sdb exists, then drive is found. It's time to try hot-removing it. We'll skip the part of script which unmounts filesystems because we don't mount it. Now instruct kernel to remove the drive. [root@ibm ~]# echo 1 > /sys/class/scsi_device/1:0:0:0/device/delete Check /dev to be sure the drive is removed. It should look just like the initial one: [root@ibm ~]# ls /dev/sd* /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 If /dev/sdb dissapeared, it's time to pray and trigger dock removal. [root@ibm ~]# echo eject > /proc/acpi/ibm/bay my laptop has no bay device compiled into custom kernel, so I got this: -bash: /proc/acpi/ibm/bay: No such file or directory If you got the same, you also don't have it so don't try to physically remove the drive. You need to recompile the kernel. Otherwise try undocking. And post the results. After issuing dock eject command, but before physically undocking the drive, save your kernel messages (you can't post them immediately because in single user mode you won't get Xwin or network). [root@ibm scsi_host]# dmesg>/dmesg Of cource, you'd find kernel messages in /dmesg file. Happy trying, Dmitry > Dmitry E. Mikhailov wrote: > > On Friday 20 June 2008 08:17:10 am Dan Sawyer wrote: > >> Yes, the motivation was ultra bay hot swap. This works on DVD and CD > >> drives. Hard drive installs work. However hard drive removal result in a > >> hard kernel hang. The script gets to the beep successfully but then the > >> hard hang. Unfortunately there are no log entries. (the latest kernel > >> patches are installed) > >> > >> Is there a way to debug this? > > > > Hot remove isn't just hardware. It's software too. > > > > 1) close files on this drive > > 2)unmount filesystems > > 3)flush caches > > 4)instruct kernel to remove SCSI device > > 5)do hardware steps to remove > > > > If you don't do any of steps 1-4, kernel would wait for HDD forever and > > HDD wouldn't respond because it is just not there. > > > > As you wrote, there's some sort of script. Please let me see it. Post > > here as an attachment or provide a link. > > > > > > Best regards, Dmitry -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Dan Sawyer
::
Rate this Message:
If I execute the echo > /sys/.../delete and then run the script it works. However if I run the script it hangs. I have put echo writes in and even with the hang it completes the script. Dan Dmitry E. Mikhailov wrote: On Saturday 21 June 2008 07:17:18 am Dan Sawyer wrote:Thanks for the reply, I am using the scripts at: http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devicesReally nice script! |
|
|
Re: scsi vs ata ?
by Dmitry E. Mikhailov
::
Rate this Message:
> Thanks for the instructions! Those all work, except there is no libata.
> The unload works. Great. Hardware is Ok, just as your kernel. There's a problem in the script. > If I execute the echo > /sys/.../delete and then run the script it works. It looks like truth. If we don't notify the kernel that HDD was removed, it'll wait for it forever. Let's look through the script. #!/bin/bash ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device' #DMITRY: it looks like true shopt -s nullglob # Umount the filesystem(s) backed by the given major:minor device(s) #DMITRY: this procedure would be invoked later. #DMITRY: it's not important because we don't mount filesystems in our test. 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 #DMITRY: don't know if this procedure works, but it's not really important 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 #DMITRY: if exists and is a directory sync # Unmount filesystems backed by this device #DMITRY: we don't mount so it doesn't matter. # 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 #DMITRY: what if we don't power it down? # DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE # Let HAL+KDE notice the unmount and let the disk spin down # sleep 0.5 # Unregister this SCSI device: sync echo 1 > $ULTRABAY_SYSDIR/delete fi sync # Turn off power to the UltraBay: if [ -d /sys/devices/platform/bay.0 ]; then echo 1 > /sys/devices/platform/bay.0/eject elif [ -e /proc/acpi/ibm/bay ]; then echo eject > /proc/acpi/ibm/bay fi # Tell the user we're OK echo 12 > /proc/acpi/ibm/beep Now the minimalistic version (no powerdowns, no unmounts) of the script is that: #!/bin/bash ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device' #DMITRY: it looks like true shopt -s nullglob if [ -d $ULTRABAY_SYSDIR ]; then sync echo 1 > $ULTRABAY_SYSDIR/delete fi sync # Turn off power to the UltraBay: if [ -d /sys/devices/platform/bay.0 ]; then echo 1 > /sys/devices/platform/bay.0/eject elif [ -e /proc/acpi/ibm/bay ]; then echo eject > /proc/acpi/ibm/bay fi Check that is works. Best regards, Dmitry. > Dmitry E. Mikhailov wrote: > > On Saturday 21 June 2008 07:17:18 am Dan Sawyer wrote: > >> Thanks for the reply, > >> > >> I am using the scripts at: > >> > >> http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices > > > > Really nice script! > > > >> The eject gets to the beep at the end of the script. No files have been > >> loaded so the only relevant steps are 4 and 5. Are they part of the > >> scrip? > > > > I think the best way to test is doing everything by hand. > > > > So, 1st is to connect bay with HDD to the laptop. It doesn't matter > > what's on that HDD, we wouldn't even try mounting it. > > > > Boot single-user: add option 'single' (with no quotes) to your kernel > > parameters at boot time. That would allow us to remove any possible > > interference from automount services etc. > > > > Once you got root commandline, check that you have ata_piix module: > > [root@ibm ~]# lsmod|grep piix > > ata_piix 20996 3 > > libata 140752 1 ata_piix > > > > Take an initial look at your /dev/ dir. It could look like this: > > [root@ibm ~]# ls /dev/sd* > > /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 > > > > Then flush caches and instruct kernel (SCSI hostadapter1) to detect the > > drive. [root@ibm ~]# sync > > [root@ibm ~]# echo 0 0 0 > /sys/class/scsi_host/host1/scan > > > > Then take a look at /dev again: it should find new sdb: > > [root@ibm ~]# ls /dev/sd* > > /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sdb /dev/sdb1 > > > > If /dev/sdb exists, then drive is found. It's time to try hot-removing > > it. > > > > We'll skip the part of script which unmounts filesystems because we don't > > mount it. > > > > Now instruct kernel to remove the drive. > > > > [root@ibm ~]# echo 1 > /sys/class/scsi_device/1:0:0:0/device/delete > > > > Check /dev to be sure the drive is removed. It should look just like the > > initial one: > > [root@ibm ~]# ls /dev/sd* > > /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 > > > > If /dev/sdb dissapeared, it's time to pray and trigger dock removal. > > [root@ibm ~]# echo eject > /proc/acpi/ibm/bay > > > > my laptop has no bay device compiled into custom kernel, so I got this: > > -bash: /proc/acpi/ibm/bay: No such file or directory > > If you got the same, you also don't have it so don't try to physically > > remove the drive. You need to recompile the kernel. Otherwise try > > undocking. And post the results. After issuing dock eject command, but > > before physically undocking the drive, save your kernel messages (you > > can't post them immediately because in single user mode you won't get > > Xwin or network). [root@ibm scsi_host]# dmesg>/dmesg > > > > Of cource, you'd find kernel messages in /dmesg file. > > > > Happy trying, > > Dmitry The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ?
by Dan Sawyer
::
Rate this Message:
Thanks again. That worked. The script removed the devices and powered
off the ultrabay. The remove leaver then triggered the original script,
but with the devices removed and the power off the original script
worked as well.
Dan Dmitry E. Mikhailov wrote:
|
|
|
Re: scsi vs ata ?
by Dmitry E. Mikhailov
::
Rate this Message:
> Thanks again. That worked.
Let's fix the script. Back to the original. Let's try to skip 'nicely' powering down the HDD. I think it could be a problem. Try the next one: #!/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 #DMITRY: Let's try NOT to 'nicely' power off the HDD # Nicely power off the device # DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE # Let HAL+KDE notice the unmount and let the disk spin down # sleep 0.5 # Unregister this SCSI device: sync echo 1 > $ULTRABAY_SYSDIR/delete fi sync # Turn off power to the UltraBay: if [ -d /sys/devices/platform/bay.0 ]; then echo 1 > /sys/devices/platform/bay.0/eject elif [ -e /proc/acpi/ibm/bay ]; then echo eject > /proc/acpi/ibm/bay fi # Tell the user we're OK echo 12 > /proc/acpi/ibm/beep > Dmitry E. Mikhailov wrote: > >> Thanks for the instructions! Those all work, except there is no libata. > >> The unload works. > > > > Great. Hardware is Ok, just as your kernel. There's a problem in the > > script. > > > >> If I execute the echo > /sys/.../delete and then run the script it > >> works. > > > > It looks like truth. If we don't notify the kernel that HDD was removed, > > it'll wait for it forever. > > > > Let's look through the script. > > > > #!/bin/bash > > ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device' > > #DMITRY: it looks like true > > shopt -s nullglob > > > > # Umount the filesystem(s) backed by the given major:minor device(s) > > #DMITRY: this procedure would be invoked later. > > #DMITRY: it's not important because we don't mount filesystems in our > > test. 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 > > #DMITRY: don't know if this procedure works, but it's not really > > important 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 #DMITRY: if exists and is a directory > > sync > > # Unmount filesystems backed by this device > > #DMITRY: we don't mount so it doesn't matter. > > # 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 > > #DMITRY: what if we don't power it down? > > # DEVNODE=`ultrabay_dev_node` && hdparm -Y $DEVNODE > > # Let HAL+KDE notice the unmount and let the disk spin down > > # sleep 0.5 > > # Unregister this SCSI device: > > sync > > echo 1 > $ULTRABAY_SYSDIR/delete > > fi > > sync > > # Turn off power to the UltraBay: > > if [ -d /sys/devices/platform/bay.0 ]; then > > echo 1 > /sys/devices/platform/bay.0/eject > > elif [ -e /proc/acpi/ibm/bay ]; then > > echo eject > /proc/acpi/ibm/bay > > fi > > # Tell the user we're OK > > echo 12 > /proc/acpi/ibm/beep > > > > > > > > Now the minimalistic version (no powerdowns, no unmounts) of the script > > is that: > > > > #!/bin/bash > > ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device' > > #DMITRY: it looks like true > > shopt -s nullglob > > if [ -d $ULTRABAY_SYSDIR ]; then > > sync > > echo 1 > $ULTRABAY_SYSDIR/delete > > fi > > sync > > # Turn off power to the UltraBay: > > if [ -d /sys/devices/platform/bay.0 ]; then > > echo 1 > /sys/devices/platform/bay.0/eject > > elif [ -e /proc/acpi/ibm/bay ]; then > > echo eject > /proc/acpi/ibm/bay > > fi > > > > Check that is works. > > > > Best regards, Dmitry. The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad |
|
|
Re: scsi vs ata ? |
