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>