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)
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).