Subject: Re: scsi subsystem information wanted...
To: Monroe Williams <>
From: Mats O Jansson <>
List: current-users
Date: 06/02/1995 14:28:45
On Fri, 2 Jun 1995, Monroe Williams wrote:

> Hi all...
> What is the relationship between the file /usr/src/sys/scsi/README and
> reality?  It mentions a number of interesting things I haven't found
> anywhere else, including a program /sbin/scsi which supposedly allows
> probing for new scsi devices without rebooting.  Does this program
> actually exist?  (It's not apparent in the -current source tree.)
> Also, is anyone out there using removable-media scsi devices?  I've
> been able to use a cd-rom and a 128MB optical drive pretty reliably,
> but I haven't figured out how to change the media in the drive without
> rebooting.  Is there some way to convince the kernel to let go of the
> media (i.e. send an "allow media removal" command to the drive), and
> lock it down again later?  
> FWIW, I'm running the mac68k port.  (The relevant parts of scsi should
> be architecture-independent, I think.)
> Thanks for any info,
> - monroe
> -------------------------------------------------------------------------
> Monroe Williams    aka    aka

Appended on this message is a mail from middle of february that might be


Mats O Jansson, CelsiusTech Systems, Jaerfaella, Sweden
email: (or

>From owner-current-users@NetBSD.ORG Mon Feb 20 20:40:45 1995
>Message-Id: <>
>From: (Michael L. Hitch)
>Date: Mon, 20 Feb 1995 11:05:48 -0700
>In-Reply-To: Olaf Seibert's message of Feb 20, 12:10pm
>X-Mailer: Mail User's Shell (7.2.5 10/14/92)
>To: Olaf Seibert <>, current-users@NetBSD.ORG
>Subject: Re: scsi tapes
>Sender: owner-current-users@NetBSD.ORG
>Precedence: list
>X-Loop: current-users@NetBSD.ORG
>Status: RO
>On Feb 20, 12:10pm, Olaf Seibert wrote:
>} But what if you have a scsi tape unit that's mostly turned off (because
>} you don't need it very often) and so you reboot without the tape unit
>} being turned on. With Linux you absolutely need to reboot before you
>} can use your tape.
>} Could NetBSD do better? (Not only for scsi buses necessarily but on any
>} bus that could potentially have devices that are not switched on at
>} boot time)
>} I realise that the dynamic mapping of scsi targets to devices (st*
>} at scsibus? target ? lun ? ) could not work, but a fixed mapping could.
>} (Or am I being silly and it works already - I cannot try this myself).
>  NetBSD already supports reprobing the SCSI bus(es).  I have an external
>CDROM that I normally don't have turned on.  I write a simple program
>to do a reprobe of the SCSI system so that I could connect the CDROM
>without needing to reboot.  By default, the program will reprobe all
>logical units on all targets on all SCSI adapters.  It will use /dev/rsd0c
>as the SCSI device to open to do the ioctl.  It will take an argument
>of the form "device[:bus[:target[:lun]]]" to specify a different
>device and to limit the bus, target, or logical unit to reprobe.  I
>do "scsireprobe sd1:1:0:1" with my Adaptec ACB400A MFF-SCSI adapter
>to get the second disk configured (the ACB400A connects 2 MFM drives
>and uses the logical unit to address the drives), since the initial
>probe only gets the first logical unit it finds on each target.
------------------------  scsireprobe.c ------------------------------
#include <stdio.h>
#include <string.h>
#include <sys/fcntl.h>
#include <sys/scsiio.h>

int fd;

main (argc, argv)
int argc;
char *argv[];
	char *devname;
	char namebuf[128];
	char *np;
	struct scsi_addr zzz = {-1, -1, -1};

	if (argc > 1)
		devname = argv[1];
		devname = "/dev/rsd0c";
	np = strchr (devname, ':');
	if (np) {
		*np++ = 0;
		zzz.scbus = atoi (np);
		np = strchr (np, ':');
		if (np) { = atoi (++np);
			np = strchr (np, ':');
			if (np)
				zzz.lun = atoi (++np);
	if (*devname != '/') {
		sprintf (namebuf, "/dev/r%sc", devname);
		devname = namebuf;
	fd = open (devname, O_RDONLY);
	if (fd < 0)
	else {
		printf ("reprobing %s:%d:%d:%d\n", devname,
		    zzz.scbus,, zzz.lun);
		if (ioctl (fd, SCIOCREPROBE, &zzz) < 0)
	close (fd);
>Michael L. Hitch			INTERNET:
>Computer Consultant
>Office of Systems and Computing Services
>Montana State University	Bozeman, MT	USA