SCSI(4)                 NetBSD Kernel Interfaces Manual                SCSI(4)

     scsi, scsibus -- Small Computer Systems Interface (SCSI) bus driver

     scsibus* at scsi?
     atapibus* at atapi?
     options SCSIDEBUG
     options SCSIVERBOSE

     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 differ-
     ent 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

     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 com-

     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.

     The scsi software supports some NetBSD kernel config(1) options.  They

     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 mes-
                  sages from the scsi software.

     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

     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.

     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.

     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

     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 configura-
                     tion option SCSIDEBUG.

     SCIOCCOMMAND    Take a SCSI command and data from a user process and
                     apply them to the SCSI device.  Return all status infor-
                     mation 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 infor-
                     mation 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.

     The system allows common device drivers to work through many different
     a single operation, however many can transfer larger amounts.

     Some adapters support Target Mode in which the system is capable of oper-
     Target Mode will be supported for some host adapters, but is not yet com-
     plete for this version of the SCSI system.

     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.

     config(1), ioctl(2), ata(4), cd(4), ch(4), intro(4), sd(4), se(4), ss(4),
     st(4), uk(4)

     This scsi system appeared in MACH 2.5 at TRW.

     This man page was originally written by Julian Elischer
     <> for FreeBSD and extensively modified by Erik Fair
     <> for NetBSD.

     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 5.0_RC4                   July 26, 2006                  NetBSD 5.0_RC4




©1994 Man-cgi 1.15, Panagiotis Christias
©1996-2019 Modified for NetBSD by Kimmo Suominen