Date: Tue, 21 Apr 1998 11:26:48 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: obrien@NUXI.com Cc: pantzer@ludd.luth.se, hans@artcom.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI-Disk hot-swappability? Message-ID: <199804211726.LAA23796@panzer.plutotech.com> In-Reply-To: <19980421100403.15807@nuxi.com> from David O'Brien at "Apr 21, 98 10:04:03 am"
next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote...
> > > The sd driver seems to be prepared for this, but the necessary changes to
> > > scsiconf.c do not seem to be there. We'd also need a set of utilities to
> > > make the kernel reprobe a given SCSI device.
>
> I'm not sure which of these gave me re-probability, but...
>
> ls /dev/*scsi*
> crw------- 1 root wheel 18, 0 Nov 4 23:55 scsisuper
>
> In my kernel config file:
> # These are only for watching for bitrot in old SCSI code.
> # also need to execute: ``(umask 077; mknod /dev/scsisuper c 18 0)''
> pseudo-device su #scsi user
> pseudo-device ssc #super scsi
>
> Then run (assuming you didn't swap out your boot drive):
> /sbin/scsi -f /dev/rsd0.ctl -r
>
> And to test, do an inquiry of the device just added (say sd2):
> /sbin/scsi -f /dev/rsd2.ctl -c "12 0 0 0 v 0" 0x40 -i 64 "s8 z8 z16 z4"
For what it's worth, CAM has built-in hot swap capability. Here's
how it works:
- Plug a disk in your hot-swap chassis
- Type 'camcontrol -r bus', where bus is the number of the SCSI bus
that the disk is on. If you know the target/lun of the drive,
you can do something like: 'camcontrol -r 3:1:0' to rescan bus 3,
target 1.
- If the disk is spun down, it will be automatically spun up by the
probe code, and you'll see a probe message, like the one that
comes up at boot, e.g.:
da1 at ahc0 bus 0 target 1 lun 0
da1: <QUANTUM XP34550W LXY4> Fixed Direct Access SCSI2 device
da1: Serial Number PCB=2011300001 ; HDA=184704011751
da1: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled
da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C)
And the code works for pulling devices out as well. If you pull a
drive out, turn one off, etc., and then do I/O to the device, the selection
timeout will cause the device to be invalidated. You can also rescan the
bus so the kernel will see that the device is gone. Once the device is
finally closed, it will completely go away. For instance:
I have an Exabyte Eliant on my test box.
sa2 at adv1 bus 0 target 2 lun 0
sa2: <EXABYTE EXB-85058HE-0000 0076> Removable Sequential Access SCSI2 device
sa2: Serial Number 16012000
sa2: 5.0MB/s transfers (5.0MHz, offset 15)
Now, I turn it off, and try to do a mt status:
{bladerunner:/usr/home/ken:20:0} mt -f /dev/nrsa2 status
mt: /dev/nrsa2: Device not configured
and the following message pops up on the console:
(sa2:adv1:0:2:0): lost device
(sa2:adv1:0:2:0): removing device entry
"lost device" is printed when the kernel notices that the device is
gone, either via a selection timeout, or a manual rescan.
Now, I turn the drive back on, and rescan bus 2:
{bladerunner:/usr/home/ken:22:0} camcontrol -r 2
Re-scan of bus 2 was successful
And the following pops up on the console:
sa2 at adv1 bus 0 target 2 lun 0
sa2: <EXABYTE EXB-85058HE-0000 0076> Removable Sequential Access SCSI2 device
sa2: Serial Number 16012000
sa2: 5.0MB/s transfers (5.0MHz, offset 15)
Losing devices affects all peripheral drivers attached to a
particular physical device. So, when the tape drive went away, the
tape driver and the passthrough driver for that drive both went away. The
passthrough driver's messages are hidden behind bootverbose, so the kernel
won't be excessively chatty. (otherwise, you'd get two peripheral driver
probe messages for every SCSI device in the system)
Ken
--
Kenneth Merry
ken@plutotech.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804211726.LAA23796>