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.
-
-
SCIOCREPROBE
- Ask the system to probe the SCSI busses for any new
devices. If it finds any, they will be attached to the appropriate
drivers. The search can be narrowed to a specific bus, target or Logical
Unit Number (LUN). The new device may or may not be related to the device
on which the ioctl was performed.
-
-
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).