Updated: 2022/Sep/29
Please read Privacy Policy. It's for your privacy.
SCSI(4) Device Drivers Manual SCSI(4)
NAME
scsi, scsibus - Small Computer Systems Interface (SCSI) bus driver
SYNOPSIS
scsibus* at scsi?
atapibus* at atapi?
options SCSIDEBUG
options SCSIVERBOSE
DESCRIPTION
The scsi driver is the top, machine-independent layer of the two-layer
software system that provides an interface for the implementation of
drivers to control various SCSI or ATAPI bus devices, and to use
different SCSI bus host adapters or EIDE controllers. SCSI bus is
capable of supporting a wide variety of peripherals, including hard
disks, removable disks, CD-ROMs, scanners, tape drives, and other
miscellaneous high-speed devices.
The bottom layer is composed of the drivers for individual EIDE or SCSI
bus controller chips (e.g. NCR 5380), accessed through various host bus
interfaces, including, but not limited to PCI, ISA, Sbus, TURBOchannel,
and NuBus. These individual devices are referred to as "host adaptors"
in SCSI terminology, because they connect the SCSI bus to the host
computer.
When NetBSD probes the SCSI busses, it "attaches" any devices it finds to
the appropriate drivers.
sd(4) hard disks
cd(4) CD-ROM drives
st(4) tape drives
ch(4) media changers
ss(4) scanners
If no specific driver matches the device, then scsi attaches the device
to the uk(4) driver so that user level SCSI ioctl(2) calls may still be
performed against the device. Currently, only sd(4), cd(4), st(4), and
uk(4) can attach to an atapi bus.
Please see the intro(4) manual page to see which SCSI bus host adaptors
are supported by NetBSD on your computer system.
KERNEL CONFIGURATION
The scsi software supports some NetBSD kernel config(1) options. They
are:
SCSIDEBUG Compile in a wide variety of printf() statements that can be
turned on by ioctl(2).
SCSIVERBOSE Enable additional and more descriptive error and status
messages from the scsi software.
All devices and the SCSI busses support boot time allocation so that an
upper number of devices and controllers does not need to be configured.
The devices are either wired so they appear at a particular device unit
number or counted so that they appear as the next available unused unit
number.
To configure a driver in the kernel without wiring down the device use a
config line similar to
ch* at scsibus? target ? lun ?
to include the ch(4) changer driver.
To wire down a unit use a config line similar to
ch1 at scsibus0 target 4 lun 0
to assign changer 1 as the changer with SCSI ID 4, logical unit 0, on bus
0. Individual SCSI busses can be wired down to specific controllers with
a config line similar to
scsibus0 at ahc0
which assigns SCSI bus 0 to the first unit using the ahc(4) driver.
When you have a mixture of wired down and counted devices then the
counting begins with the first non-wired down unit for a particular type.
That is, if you have a disk wired down as
sd1 at scsibus0 target 1 lun 0
then the first non-wired disk shall come on line as sd2.
IOCTLS
There are a number of ioctl(2) calls that work on any SCSI device. They
are defined in sys/scsiio.h and can be applied against any SCSI device
that permits them. For the tape, it must be applied against the control
device. See the manual page for each device type for more information
about how generic SCSI ioctl(2) calls may be applied to a specific
device.
SCIOCRESET Reset a SCSI device.
SCIOCDEBUG Turn on debugging. All SCSI operations originating from
this device's driver will be traced to the console, along
with other information. Debugging is controlled by four
bits, described in the header file. If no debugging is
configured into the kernel, debugging will have no
effect. SCSI debugging is controlled by the
configuration option SCSIDEBUG.
SCIOCCOMMAND Take a SCSI command and data from a user process and
apply them to the SCSI device. Return all status
information and return data to the process. The ioctl(2)
call will return a successful status even if the device
rejected the command. As all status is returned to the
user, it is up to the user process to examine this
information to decide the success of the command.
SCIOCIDENTIFY Ask the driver what its bus, target and LUN are.
SCIOCDECONFIG Ask the device to disappear. This may not happen if the
device is in use.
ADAPTERS
The system allows common device drivers to work through many different
types of adapters. The adapters take requests from the upper layers and
do all IO between the SCSI bus and the system. The maximum size of a
transfer is governed by the adapter. Most adapters can transfer 64KB in
a single operation, however many can transfer larger amounts.
TARGET MODE
Some adapters support Target Mode in which the system is capable of
operating as a device, responding to operations initiated by another
system. Target Mode will be supported for some host adapters, but is not
yet complete for this version of the SCSI system.
DIAGNOSTICS
When the kernel is compiled with option SCSIDEBUG, the SCIOCDEBUG
ioctl(2) can be used to enable various amounts of tracing information on
any specific device. Devices not being traced will not produce trace
information. The four bits that make up the debug level, each control
certain types of debugging information.
Bit 0 shows all SCSI bus operations including SCSI commands, error
information and the first 48 bytes of any data transferred.
Bit 1 shows routines called.
Bit 2 shows information about what branches are taken and often some of
the return values of functions.
Bit 3 shows more detailed information including DMA scatter-gather logs.
SEE ALSO
config(1), ioctl(2), ata(4), cd(4), ch(4), intro(4), sd(4), se(4), ss(4),
st(4), uk(4), scsictl(8)
HISTORY
This scsi system appeared in MACH 2.5 at TRW.
This man page was originally written by Julian Elischer
<julian@freebsd.org> for FreeBSD and extensively modified by Erik Fair
<fair@NetBSD.org> for NetBSD.
BUGS
Not every device obeys the SCSI specification as faithfully as it should.
As such devices are discovered by the NetBSD Project, their names are
added to a quirk list compiled into the scsi driver along a list of flags
indicating which particular bad behaviors the device exhibits (and that
the driver should be prepared to work around).
NetBSD 10.99 August 18, 2019 NetBSD 10.99