7304 lines
161 KiB
HTML
7304 lines
161 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||
<HTML
|
||
><HEAD
|
||
><TITLE
|
||
>The Linux 2.4 SCSI subsystem HOWTO</TITLE
|
||
><META
|
||
NAME="GENERATOR"
|
||
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
|
||
><BODY
|
||
CLASS="book"
|
||
BGCOLOR="#FFFFFF"
|
||
TEXT="#000000"
|
||
LINK="#0000FF"
|
||
VLINK="#840084"
|
||
ALINK="#0000FF"
|
||
><DIV
|
||
CLASS="BOOK"
|
||
><A
|
||
NAME="index"
|
||
></A
|
||
><DIV
|
||
CLASS="TITLEPAGE"
|
||
><H1
|
||
CLASS="title"
|
||
><A
|
||
NAME="AEN2"
|
||
></A
|
||
>The Linux 2.4 SCSI subsystem HOWTO</H1
|
||
><H3
|
||
CLASS="author"
|
||
><A
|
||
NAME="AEN5"
|
||
></A
|
||
>Douglas Gilbert</H3
|
||
><DIV
|
||
CLASS="affiliation"
|
||
><DIV
|
||
CLASS="address"
|
||
><P
|
||
CLASS="address"
|
||
><br>
|
||
<TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:dgilbert at interlog dot com"
|
||
>dgilbert at interlog dot com</A
|
||
>></TT
|
||
><br>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><P
|
||
CLASS="copyright"
|
||
>Copyright © 2001, 2002, 2003, 2004 Douglas Gilbert</P
|
||
><P
|
||
CLASS="pubdate"
|
||
>2003-08-24<BR></P
|
||
><DIV
|
||
CLASS="revhistory"
|
||
><TABLE
|
||
WIDTH="100%"
|
||
BORDER="0"
|
||
><TR
|
||
><TH
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
COLSPAN="3"
|
||
><B
|
||
>Revision History</B
|
||
></TH
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 2.1</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2004-08-24</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>scsihosts change -> run mkinitrd, lk 2.4.21,22</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 2.0</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2003-05-04</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>lk2.4.20, linuxdoc->tldp, sATA and SAS, last sector on raw devs,
|
||
blockdev</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.9</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2002-11-20</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>convert to xml, lk2.4.19, spelling</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.8</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2002-05-05</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>scsihosts comma delimiter, grub+lilo</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.7</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2002-04-27</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>mkinitrd, scsi_debug, 2.4.18, more ATAPI</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.6</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2002-01-26</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>ATAPI cdrom selection</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.5</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2001-12-21</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>16 byte SCSI commands, SCSI_IOCTL_GET_PCI</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.4</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2001-08-26</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>spelling, dd_rescue, mkinitrd example, lk 2.4 changes, 1394.</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.3</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2001-08-26</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>ATAPI CDROM section, alter title, U320, iSCSI.</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.2</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2001-03-25</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>Information about scu, dt, "Alt" sequences, more notes.</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revision 1.1</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>2001-01-22</TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
>Revised by: dpg</TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
COLSPAN="3"
|
||
>Add osst description, _EXTRA_DEVS limitations.</TD
|
||
></TR
|
||
></TABLE
|
||
></DIV
|
||
><DIV
|
||
><DIV
|
||
CLASS="abstract"
|
||
><A
|
||
NAME="AEN79"
|
||
></A
|
||
><P
|
||
></P
|
||
><P
|
||
> This document describes the SCSI subsystem as the Linux kernel
|
||
enters the 2.4 production series.
|
||
An external view of the SCSI subsystem is the main theme.
|
||
Material is included to help the system administration of the
|
||
Linux SCSI subsystem. There are also brief descriptions of
|
||
ioctl()s and interfaces that may be relevant to those writing
|
||
applications that use this subsystem.
|
||
</P
|
||
><P
|
||
></P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="legalnotice"
|
||
><A
|
||
NAME="AEN74"
|
||
></A
|
||
><P
|
||
></P
|
||
><P
|
||
> Permission is granted to copy, distribute and/or modify this document
|
||
under the terms of the GNU Free Documentation License, Version 1.1
|
||
or any later version published by the Free Software Foundation;
|
||
with no Invariant Sections, with no Front-Cover Texts, and with
|
||
no Back-Cover Texts.
|
||
</P
|
||
><P
|
||
> For an online copy of the license see
|
||
<A
|
||
HREF="http://www.fsf.org/copyleft/fdl.html"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.fsf.org/copyleft/fdl.html</TT
|
||
></A
|
||
>.
|
||
</P
|
||
><P
|
||
></P
|
||
></DIV
|
||
><HR></DIV
|
||
><DIV
|
||
CLASS="TOC"
|
||
><DL
|
||
><DT
|
||
><B
|
||
>Table of Contents</B
|
||
></DT
|
||
><DT
|
||
>1. <A
|
||
HREF="#intro"
|
||
>Introduction</A
|
||
></DT
|
||
><DT
|
||
>2. <A
|
||
HREF="#arch"
|
||
>Architectural Overview</A
|
||
></DT
|
||
><DT
|
||
>3. <A
|
||
HREF="#names"
|
||
>Names and Addresses</A
|
||
></DT
|
||
><DD
|
||
><DL
|
||
><DT
|
||
>3.1. <A
|
||
HREF="#scsiaddr"
|
||
>SCSI Addressing</A
|
||
></DT
|
||
><DT
|
||
>3.2. <A
|
||
HREF="#dnames"
|
||
>Device Names</A
|
||
></DT
|
||
><DT
|
||
>3.3. <A
|
||
HREF="#dnamesdevfs"
|
||
>Device Names in devfs</A
|
||
></DT
|
||
><DT
|
||
>3.4. <A
|
||
HREF="#dnamesscsidev"
|
||
>Device Names in scsidev</A
|
||
></DT
|
||
></DL
|
||
></DD
|
||
><DT
|
||
>4. <A
|
||
HREF="#kconfig"
|
||
>Kernel Configuration</A
|
||
></DT
|
||
><DT
|
||
>5. <A
|
||
HREF="#bparams"
|
||
>Boot Parameters</A
|
||
></DT
|
||
><DT
|
||
>6. <A
|
||
HREF="#modparams"
|
||
>Modules and their Parameters</A
|
||
></DT
|
||
><DT
|
||
>7. <A
|
||
HREF="#procfs"
|
||
>Proc pseudo file system</A
|
||
></DT
|
||
><DT
|
||
>8. <A
|
||
HREF="#mlevel"
|
||
>Mid Level, Unifying layer</A
|
||
></DT
|
||
><DD
|
||
><DL
|
||
><DT
|
||
>8.1. <A
|
||
HREF="#mlbparams"
|
||
>boot parameters</A
|
||
></DT
|
||
><DT
|
||
>8.2. <A
|
||
HREF="#mlmparams"
|
||
>module parameters</A
|
||
></DT
|
||
><DT
|
||
>8.3. <A
|
||
HREF="#mlproc"
|
||
>proc interface</A
|
||
></DT
|
||
></DL
|
||
></DD
|
||
><DT
|
||
>9. <A
|
||
HREF="#ulevel"
|
||
>Upper level drivers</A
|
||
></DT
|
||
><DD
|
||
><DL
|
||
><DT
|
||
>9.1. <A
|
||
HREF="#sd"
|
||
>Disk driver (sd)</A
|
||
></DT
|
||
><DT
|
||
>9.2. <A
|
||
HREF="#sr"
|
||
>CDROM driver (sr or scd)</A
|
||
></DT
|
||
><DT
|
||
>9.3. <A
|
||
HREF="#st"
|
||
>Tape driver (st)</A
|
||
></DT
|
||
><DT
|
||
>9.4. <A
|
||
HREF="#sg"
|
||
>Generic driver (sg)</A
|
||
></DT
|
||
></DL
|
||
></DD
|
||
><DT
|
||
>10. <A
|
||
HREF="#llevel"
|
||
>Lower Level drivers</A
|
||
></DT
|
||
><DD
|
||
><DL
|
||
><DT
|
||
>10.1. <A
|
||
HREF="#llevelpseudo"
|
||
>Pseudo drivers</A
|
||
></DT
|
||
></DL
|
||
></DD
|
||
><DT
|
||
>11. <A
|
||
HREF="#rawdev"
|
||
>Raw devices</A
|
||
></DT
|
||
><DT
|
||
>12. <A
|
||
HREF="#devfs"
|
||
>Devfs pseudo file system</A
|
||
></DT
|
||
><DT
|
||
>A. <A
|
||
HREF="#scsibus"
|
||
>Common bus types (SCSI and other)</A
|
||
></DT
|
||
><DT
|
||
>B. <A
|
||
HREF="#changes"
|
||
>Changes between lk 2.2 and (during) 2.4</A
|
||
></DT
|
||
><DD
|
||
><DL
|
||
><DT
|
||
>B.1. <A
|
||
HREF="#chgml"
|
||
>Mid level changes</A
|
||
></DT
|
||
><DT
|
||
>B.2. <A
|
||
HREF="#chgsd"
|
||
>sd changes</A
|
||
></DT
|
||
><DT
|
||
>B.3. <A
|
||
HREF="#chgsr"
|
||
>sr changes</A
|
||
></DT
|
||
><DT
|
||
>B.4. <A
|
||
HREF="#chgst"
|
||
>st changes</A
|
||
></DT
|
||
><DT
|
||
>B.5. <A
|
||
HREF="#chgsg"
|
||
>sg changes</A
|
||
></DT
|
||
><DT
|
||
>B.6. <A
|
||
HREF="#chg24"
|
||
>Changes during the lk 2.4 series</A
|
||
></DT
|
||
></DL
|
||
></DD
|
||
><DT
|
||
>C. <A
|
||
HREF="#trouble"
|
||
>Troubleshooting</A
|
||
></DT
|
||
><DT
|
||
>D. <A
|
||
HREF="#perform"
|
||
>Performance, Test and Debugging tools</A
|
||
></DT
|
||
><DT
|
||
>E. <A
|
||
HREF="#compileopt"
|
||
>Compile options and System calls including ioctls</A
|
||
></DT
|
||
><DD
|
||
><DL
|
||
><DT
|
||
>E.1. <A
|
||
HREF="#coml"
|
||
>Mid level</A
|
||
></DT
|
||
><DT
|
||
>E.2. <A
|
||
HREF="#cosd"
|
||
>sd driver</A
|
||
></DT
|
||
><DT
|
||
>E.3. <A
|
||
HREF="#cosr"
|
||
>sr driver</A
|
||
></DT
|
||
><DT
|
||
>E.4. <A
|
||
HREF="#cost"
|
||
>st driver</A
|
||
></DT
|
||
><DT
|
||
>E.5. <A
|
||
HREF="#cosg"
|
||
>sg driver</A
|
||
></DT
|
||
></DL
|
||
></DD
|
||
><DT
|
||
>F. <A
|
||
HREF="#refs"
|
||
>References, Credits and Corrections</A
|
||
></DT
|
||
></DL
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="intro"
|
||
></A
|
||
>Chapter 1. Introduction</H1
|
||
><P
|
||
> This document describes the SCSI subsystem as the Linux kernel
|
||
enters the 2.4 production series.
|
||
</P
|
||
><P
|
||
> An external view of the SCSI subsystem is the main theme.
|
||
Material is included to help the system administration of the Linux SCSI
|
||
subsystem. There are also brief descriptions of ioctl()s and interfaces
|
||
that may be relevant to those writing applications that use this subsystem.
|
||
However internal data structures and design issues are not addressed
|
||
[see reference <A
|
||
HREF="#W2"
|
||
>W2</A
|
||
>]. To unclutter the presentation,
|
||
compile options and system calls (including ioctl()s) have been placed in
|
||
<A
|
||
HREF="#compileopt"
|
||
>Appendix E</A
|
||
>. Although not strictly part of the SCSI
|
||
subsystem, there is also a description of raw devices in
|
||
<A
|
||
HREF="#rawdev"
|
||
>Chapter 11</A
|
||
>.
|
||
</P
|
||
><P
|
||
> For those who have no interest in the SCSI subsystem and just want to get
|
||
their ATAPI cd writer going, see <A
|
||
HREF="#sratapi"
|
||
>Section 9.2.4</A
|
||
>.
|
||
It may also be useful to browse <A
|
||
HREF="#arch"
|
||
>Chapter 2</A
|
||
>.
|
||
</P
|
||
><P
|
||
> This document follows on from one written five years ago by Drew
|
||
Eckhardt called the SCSI-HOWTO [see reference <A
|
||
HREF="#W7"
|
||
>W7</A
|
||
>].
|
||
That document described the SCSI subsystem in Linux kernel 1.2 and 1.3
|
||
series. It is still available from the Linux Documentation Project
|
||
[LDP, see reference <A
|
||
HREF="#W8"
|
||
>W8</A
|
||
>] in its "unmaintained"
|
||
section. Both documents have roughly similar structures although Drew's
|
||
document has a lot of information on the adapter drivers.
|
||
</P
|
||
><P
|
||
> This document can be found in electronic form at
|
||
<A
|
||
HREF="http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.tldp.org/HOWTO/SCSI-2.4-HOWTO</TT
|
||
></A
|
||
>.
|
||
The home site and perhaps the most up to date version of this
|
||
document can be found at
|
||
<A
|
||
HREF="http://www.torque.net/scsi/SCSI-2.4-HOWTO"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.torque.net/scsi/SCSI-2.4-HOWTO</TT
|
||
></A
|
||
> (this is
|
||
the multi-page html version).
|
||
At that location this document is rendered in txt, pdf, ps, a single
|
||
(long) page of html as well as multi-page html. For example, a pdf
|
||
version is at <A
|
||
HREF="http://www.torque.net/scsi/SCSI-2.4-HOWTO.pdf"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.torque.net/scsi/SCSI-2.4-HOWTO.pdf</TT
|
||
></A
|
||
>).
|
||
</P
|
||
><P
|
||
> This document was last altered on 24th August 2004.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="arch"
|
||
></A
|
||
>Chapter 2. Architectural Overview</H1
|
||
><P
|
||
> The SCSI subsystem has a 3 level architecture with the "upper" level
|
||
being closest to the user/kernel interface while the "lower" level
|
||
is closest to the hardware. The upper level drivers are commonly known
|
||
by a terse two letter abbreviation (e.g. "sd" for SCSI disk driver).
|
||
The names of the corresponding module drivers which, for historical
|
||
reasons, sometimes differ from the built in driver names are shown in
|
||
braces in the following diagram.
|
||
</P
|
||
><DIV
|
||
CLASS="mediaobject"
|
||
><P
|
||
><IMG
|
||
SRC="scsi-arch.jpg"><DIV
|
||
CLASS="caption"
|
||
><P
|
||
> The 3 level driver architecture of the SCSI subsystem.
|
||
</P
|
||
></DIV
|
||
></P
|
||
></DIV
|
||
><P
|
||
> The upper level supports the user-kernel interface. In the case of sd and sr
|
||
this is a block device interface while for st and sg this is a character
|
||
device interface. Any operation using the SCSI subsystem (e.g. reading a
|
||
sector from a disk) involves one driver at each of the 3 levels (e.g. sd,
|
||
SCSI mid level and aic7xxx drivers).
|
||
</P
|
||
><P
|
||
> As can be seen from the diagram, the SCSI mid level is common to all
|
||
operations. The SCSI mid level defines internal interfaces and provides
|
||
common services to the upper and lower level drivers. Ioctls provided by
|
||
the mid level are available to the file descriptors belonging to any of
|
||
the 4 upper level drivers.
|
||
</P
|
||
><P
|
||
> The most common operation on a block device is to "mount" a
|
||
file system. For a sd device typically a partition is mounted
|
||
(e.g. <B
|
||
CLASS="command"
|
||
>mount -t ext2 /dev/sda6 /home</B
|
||
>). For a
|
||
sr device usually the whole device is mounted (e.g. <B
|
||
CLASS="command"
|
||
> mount -t iso9660 /dev/sr0 /mnt/cdrom</B
|
||
>). The <B
|
||
CLASS="command"
|
||
>dd
|
||
</B
|
||
> command can be used to read or write from block devices.
|
||
In this case the block size argument ("bs") needs to be set to
|
||
the block size of the device (e.g. 512 bytes for most disks)
|
||
or an integral multiple of that device block size (e.g. 8192 bytes).
|
||
A recent addition to the block subsystem allows a device (or partition)
|
||
to be mounted more than once, at different mount points.
|
||
</P
|
||
><P
|
||
> Sd is a member of the generic disk family, as is the hd device from the
|
||
IDE subsystem. Apart from mounting sd devices, the <B
|
||
CLASS="command"
|
||
>fdisk
|
||
</B
|
||
> command is available to view or modify a disk's
|
||
partition table. Although the <B
|
||
CLASS="command"
|
||
>hdparm</B
|
||
> command is
|
||
primarily intended for ATA disks (also known as IDE or EIDE disks), some
|
||
options work on SCSI disks.
|
||
</P
|
||
><P
|
||
> Sr is a member of the CD-ROM subsystem. Apart from mounting file
|
||
systems (e.g. iso9660), audio CDs can also be read. The latter
|
||
action does <EM
|
||
>not</EM
|
||
> involve mounting a file
|
||
system but typically by invoking some ioctls. General
|
||
purpose Linux commands such as <B
|
||
CLASS="command"
|
||
>dd</B
|
||
> cannot be
|
||
used on audio CDs.
|
||
</P
|
||
><P
|
||
> St is a char device for reading and writing tapes. Typically the
|
||
<B
|
||
CLASS="command"
|
||
>mt</B
|
||
> command is used to perform data transfers and
|
||
other control functions.
|
||
</P
|
||
><P
|
||
> Sg is a SCSI command pass through device that uses a char device
|
||
interface. General purpose Linux commands should <EM
|
||
>not
|
||
</EM
|
||
> be used on sg devices. Applications such
|
||
as SANE (for scanners), <B
|
||
CLASS="command"
|
||
>cdrecord</B
|
||
> and
|
||
<B
|
||
CLASS="command"
|
||
>cdrdao</B
|
||
> (for cd writers) and
|
||
<B
|
||
CLASS="command"
|
||
>cdparanoia</B
|
||
> (for reading audio CDs digitally) use sg.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="names"
|
||
></A
|
||
>Chapter 3. Names and Addresses</H1
|
||
><P
|
||
> This section covers the various naming schemes that exist in Linux
|
||
and the SCSI worlds and how they interact.
|
||
</P
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="scsiaddr"
|
||
></A
|
||
>3.1. SCSI Addressing</H1
|
||
><P
|
||
> Linux has a four level hierarchical addressing scheme for SCSI devices:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>SCSI adapter number [host]</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>channel number [bus]</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>id number [target]</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>lun [lun]</P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><P
|
||
> "Lun" is the common SCSI abbreviation of Logical Unit Number. The terms
|
||
in brackets are the name conventions used by device pseudo file system
|
||
(devfs). "Bus" is used in preference to "channel" in the description below.
|
||
</P
|
||
><P
|
||
> The SCSI adapter number is typically an arbitrary numbering of the adapter
|
||
cards on the internal IO buses (e.g. PCI, PCMCIA, ISA etc) of the computer.
|
||
Such adapters are sometimes termed as HBAs (host bus adapters).
|
||
SCSI adapter numbers are issued by the kernel in ascending order starting
|
||
with 0.
|
||
</P
|
||
><P
|
||
> Each HBA may control one or more SCSI buses. The various types of SCSI
|
||
buses are listed in <A
|
||
HREF="#scsibus"
|
||
>Appendix A</A
|
||
>.
|
||
</P
|
||
><P
|
||
> Each SCSI bus can have multiple SCSI devices connected to it. In SCSI
|
||
parlance the HBA is called the "initiator" and takes up one SCSI id
|
||
number (typically 7). The initiator
|
||
<A
|
||
NAME="AEN152"
|
||
HREF="#FTN.AEN152"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[1]</SPAN
|
||
></A
|
||
>
|
||
talks to targets which are commonly
|
||
known as SCSI devices (e.g. disks). On SCSI parallel buses the number
|
||
of ids is related to the width. 8 bit buses (sometimes called "narrow")
|
||
can have 8 SCSI ids of which 1 is taken by the HBA leaving 7 for SCSI
|
||
devices. Wide SCSI buses are 16 bits wide and can have a maximum of 15
|
||
SCSI devices (targets) attached. The SCSI 3 draft standard allows a
|
||
large number of ids to be present on a SCSI bus.
|
||
</P
|
||
><P
|
||
> Each SCSI device can contain multiple Logical Unit Numbers (LUNs). These
|
||
are typically used by sophisticated tape and cdrom units that support
|
||
multiple media.
|
||
</P
|
||
><P
|
||
> So Linux's flavour of SCSI addressing is a four level hierarchy:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> <scsi(_adapter_number), channel, id, lun>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
Using the naming conventions of devfs this becomes:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> <host, bus, target, lun>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="dnames"
|
||
></A
|
||
>3.2. Device Names</H1
|
||
><P
|
||
> A device name can be thought of as a gateway to a kernel driver that
|
||
controls a device rather than the device itself. Hence there can be
|
||
multiple device names some of which may offer slightly different
|
||
characteristics, all mapping to the same actual device.
|
||
</P
|
||
><P
|
||
> The device names of the various SCSI devices are found within the
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev</TT
|
||
> directory. Traditionally in Linux, SCSI
|
||
devices have been identified by their major and minor device number
|
||
rather than their SCSI bus addresses (e.g. SCSI target id and LUN).
|
||
The device pseudo file system (devfs) moves away from the major and
|
||
minor device number scheme and for the SCSI subsystem uses device names
|
||
based on the SCSI bus addresses [discussed later in
|
||
<A
|
||
HREF="#dnamesdevfs"
|
||
>Section 3.3</A
|
||
> and see reference: <A
|
||
HREF="#W5"
|
||
>W5</A
|
||
>].
|
||
Alternatively, there is a utility called <B
|
||
CLASS="command"
|
||
>scsidev</B
|
||
>
|
||
which addresses this issue within the scope of the Linux SCSI subsystem
|
||
and thus does not have the same system wide impact as devfs. Scsidev is
|
||
discussed later in <A
|
||
HREF="#dnamesscsidev"
|
||
>Section 3.4</A
|
||
> and ref:
|
||
<A
|
||
HREF="#W6"
|
||
>W6</A
|
||
>.
|
||
</P
|
||
><P
|
||
> Eight block major numbers are reserved for SCSI disks: 8, 65, 66, 67, 68,
|
||
69, 70 and 71. Each major can accommodate 256 minor numbers which, in the
|
||
case of SCSI disks, are subdivided as follows:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> [b,8,0] /dev/sda
|
||
[b,8,1] /dev/sda1
|
||
....
|
||
[b,8,15] /dev/sda15
|
||
[b,8,16] /dev/sdb
|
||
[b,8,17] /dev/sdb1
|
||
....
|
||
[b,8,255] /dev/sdp15
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The disk device names without a trailing digit refer to the whole disk
|
||
(e.g. <TT
|
||
CLASS="filename"
|
||
>/dev/sda</TT
|
||
>)
|
||
while those with a trailing digit refer to one of the 15 allowable
|
||
partitions
|
||
<A
|
||
NAME="AEN172"
|
||
HREF="#FTN.AEN172"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[2]</SPAN
|
||
></A
|
||
>
|
||
within that disk.
|
||
</P
|
||
><P
|
||
> The remaining 7 SCSI disk block major numbers follow a similar pattern:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> [b,65,0] /dev/sdq
|
||
[b,65,1] /dev/sdq1
|
||
....
|
||
[b,65,159] /dev/sdz15
|
||
[b,65,160] /dev/sdaa
|
||
[b,65,161] /dev/sdaa1
|
||
....
|
||
[b,65,255] /dev/sdaf15
|
||
[b,66,0] /dev/sdag
|
||
[b,66,1] /dev/sdag1
|
||
....
|
||
[b,66,255] /dev/sdav15
|
||
....
|
||
[b,71,255] /dev/sddx15
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> So there are 128 possible disks (i.e. <TT
|
||
CLASS="filename"
|
||
>/dev/sda</TT
|
||
> to
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/sddx</TT
|
||
>) each having up
|
||
to 15 partitions. By way of contrast, the IDE subsystem allows 20 disks
|
||
(10 controllers each with 1 master and 1 slave) which can have up to 63
|
||
partitions each.
|
||
</P
|
||
><P
|
||
> SCSI CD-ROM devices are allocated the block major number of 11. Traditionally
|
||
<TT
|
||
CLASS="filename"
|
||
>sr</TT
|
||
> has been the device name but <TT
|
||
CLASS="filename"
|
||
>scd</TT
|
||
>
|
||
probably is more recognizable and is
|
||
favoured by several recent distributions. 256 SCSI CD-ROM devices are
|
||
allowed:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> [b,11,0] /dev/scd0 [or /dev/sr0]
|
||
[b,11,255] /dev/scd255 [or /dev/sr255]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> SCSI tape devices are allocated the char major number of 9. Up to 32 tape
|
||
devices are supported each of which can be accessed in one of four modes
|
||
(0, 1, 2 and 3), with or without rewind. The devices are allocated as
|
||
follows:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> [c,9,0] /dev/st0 [tape 0, mode 0, rewind]
|
||
[c,9,1] /dev/st1 [tape 1, mode 0, rewind]
|
||
....
|
||
[c,9,31] /dev/st31 [tape 31, mode 0, rewind]
|
||
[c,9,32] /dev/st0l [tape 0, mode 1, rewind]
|
||
....
|
||
[c,9,63] /dev/st31l [tape 31, mode 1, rewind]
|
||
[c,9,64] /dev/st0m [tape 0, mode 2, rewind]
|
||
....
|
||
[c,9,96] /dev/st0a [tape 0, mode 3, rewind]
|
||
....
|
||
[c,9,127] /dev/st31a [tape 31, mode 3, rewind]
|
||
[c,9,128] /dev/nst0 [tape 0, mode 0, no rewind]
|
||
....
|
||
[c,9,160] /dev/nst0l [tape 0, mode 1, no rewind]
|
||
....
|
||
[c,9,192] /dev/nst0m [tape 0, mode 2, no rewind]
|
||
....
|
||
[c,9,224] /dev/nst0a [tape 0, mode 3, no rewind]
|
||
....
|
||
[c,9,255] /dev/nst31a [tape 31, mode 3, no rewind]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The SCSI generic (sg) devices are allocated the char major number of 21.
|
||
There are 256 possible SCSI generic (sg) devices:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> [c,21,0] /dev/sg0
|
||
[c,21,1] /dev/sg1
|
||
....
|
||
[c,21,255] /dev/sg255
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Note that the SCSI generic device name's use of a trailing letter (e.g.
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/sgc</TT
|
||
>) is deprecated.
|
||
</P
|
||
><P
|
||
> Each SCSI disk (but not each partition), each SCSI CD-ROM and each SCSI
|
||
tape is mapped to an sg device. SCSI devices that don't fit into these
|
||
three categories (e.g. scanners) also appear as sg devices.
|
||
</P
|
||
><P
|
||
> Pseudo devices [see <A
|
||
HREF="#llevelpseudo"
|
||
>Section 10.1</A
|
||
>] can cause devices
|
||
that are usually not considered as SCSI to appear as SCSI device names.
|
||
For example an ATAPI CD-ROM may be picked up by the ide-scsi pseudo
|
||
driver and mapped to <TT
|
||
CLASS="filename"
|
||
>/dev/scd0</TT
|
||
> .
|
||
</P
|
||
><P
|
||
> The <TT
|
||
CLASS="filename"
|
||
>linux/Documentation/devices.txt</TT
|
||
> file supplied
|
||
within the kernel source is the definitive reference for Linux device
|
||
names and their corresponding major and minor number allocations.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="dnamesdevfs"
|
||
></A
|
||
>3.3. Device Names in devfs</H1
|
||
><P
|
||
> The device pseudo file system can be mounted as <TT
|
||
CLASS="filename"
|
||
>/dev</TT
|
||
> in
|
||
which case it replaces the traditional Linux device subdirectory.
|
||
Alternatively it can be mounted elsewhere (e.g. <TT
|
||
CLASS="filename"
|
||
>/devfs</TT
|
||
>)
|
||
and supplement the existing device structure.
|
||
</P
|
||
><P
|
||
> Without devfs, devices names are typically maintained in the
|
||
<TT
|
||
CLASS="filename"
|
||
>dev</TT
|
||
> directory
|
||
of the root partition. Hence the device names (and their associated
|
||
permissions) have file system persistence. The existence of a device name
|
||
does not necessarily imply such a device (or even its driver) is present. To
|
||
save users having to create device name entries (with the <B
|
||
CLASS="command"
|
||
>mknod
|
||
</B
|
||
> command) most Linux distributions come with thousands of device
|
||
names defined in the <TT
|
||
CLASS="filename"
|
||
>/dev</TT
|
||
> directory. When applications
|
||
try to open() the device name then an errno value of ENODEV indicates there
|
||
is no corresponding device (or driver) currently available.
|
||
</P
|
||
><P
|
||
> Devfs takes a different approach in which the existence of the device name
|
||
is directly related to the presence of the corresponding device (and its
|
||
driver).
|
||
</P
|
||
><P
|
||
> Assuming devfs is mounted on <TT
|
||
CLASS="filename"
|
||
>/dev</TT
|
||
> then SCSI devices
|
||
have primary device names that might look like this:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> /dev/scsi/host0/bus0/target1/lun0/disc [whole disk]
|
||
/dev/scsi/host0/bus0/target1/lun0/part6 [partition 6]
|
||
/dev/scsi/host0/bus0/target1/lun0/generic [sg device for disk]
|
||
|
||
/dev/scsi/host1/bus0/target2/lun0/cd [CD reader or writer]
|
||
/dev/scsi/host1/bus0/target2/lun0/generic [sg device for cd]
|
||
|
||
/dev/scsi/host2/bus0/target0/lun0/mt [tape mode 0 rewind]
|
||
/dev/scsi/host2/bus0/target0/lun0/mtan [tape mode 3 no rewind]
|
||
/dev/scsi/host2/bus0/target0/lun0/generic [sg device for tape]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
The sg device on the third line corresponds to the "whole disk" on the
|
||
first line since they have the same SCSI address (i.e.
|
||
<TT
|
||
CLASS="filename"
|
||
>host0/bus0/target1/lun0</TT
|
||
>). If the sg driver is a module
|
||
and it has not yet been loaded (or it has been unloaded) then the
|
||
"generic" device names in the above list will not be present.
|
||
</P
|
||
><P
|
||
> [Notice the spelling of "disc" as the devfs author favours English spelling
|
||
over the American variant.] It can be seen that devfs's naming scheme
|
||
closely matches the SCSI addressing discussed in
|
||
<A
|
||
HREF="#scsiaddr"
|
||
>Section 3.1</A
|
||
>. It is worth noting that the IDE subsystem uses
|
||
a similar devfs device naming scheme with the word "scsi" replaced with
|
||
"ide". Devfs is discussed further in <A
|
||
HREF="#devfs"
|
||
>Chapter 12</A
|
||
>.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="dnamesscsidev"
|
||
></A
|
||
>3.4. Device Names in scsidev</H1
|
||
><P
|
||
> A utility program called <B
|
||
CLASS="command"
|
||
>scsidev</B
|
||
> adds device names to
|
||
the <TT
|
||
CLASS="filename"
|
||
>/dev/scsi</TT
|
||
> directory that reflect the SCSI address
|
||
of each device. The first 2 letters of the name are the upper level SCSI
|
||
driver name (i.e. either sd, sr, st or sg). The number following the "h"
|
||
is the host number while the number following the "-" is meant for
|
||
host identification purposes. For PCI adapters this seems to be always
|
||
0 while for ISA adapters it is their IO address. [Perhaps this field
|
||
could be made more informative or dropped.] The numbers following
|
||
the "c", "i" and "l" are channel (bus), target id and lun values
|
||
respectively. Raw disks are shown without a trailing partition number
|
||
while partitions contained within them are shown with the partition
|
||
number following a "p".
|
||
</P
|
||
><P
|
||
> The <B
|
||
CLASS="command"
|
||
>scsidev</B
|
||
> would typically be run as part of the
|
||
boot up sequence. It may also be useful to run it after the SCSI
|
||
configuration has changed (e.g. adding or removing lower level driver
|
||
modules, or the use of the add/remove-single-device command). After
|
||
<B
|
||
CLASS="command"
|
||
>scsidev</B
|
||
> has been run on my system which contains
|
||
2 disks, a cd reader and writer plus a scanner, then the following
|
||
names were added in the <TT
|
||
CLASS="filename"
|
||
>/dev/scsi</TT
|
||
> directory:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> $ ls -l /dev/scsi/ # abridged
|
||
total 0
|
||
brw------- 8, 0 Sep 2 11:56 sdh0-0c0i0l0
|
||
brw------- 8, 1 Sep 2 11:56 sdh0-0c0i0l0p1
|
||
...
|
||
brw------- 8, 8 Sep 2 11:56 sdh0-0c0i0l0p8
|
||
brw------- 8, 16 Sep 2 11:56 sdh0-0c0i1l0
|
||
brw------- 8, 17 Sep 2 11:56 sdh0-0c0i1l0p1
|
||
...
|
||
brw------- 8, 24 Sep 2 11:56 sdh0-0c0i1l0p8
|
||
crw------- 21, 0 Sep 2 11:56 sgh0-0c0i0l0
|
||
crw------- 21, 1 Sep 2 11:56 sgh0-0c0i1l0
|
||
crw------- 21, 2 Sep 2 11:56 sgh1-0c0i2l0
|
||
crw------- 21, 3 Sep 2 11:56 sgh1-0c0i5l0
|
||
crw------- 21, 4 Sep 2 11:56 sgh1-0c0i6l0
|
||
br-------- 11, 0 Sep 2 11:56 srh1-0c0i2l0
|
||
br-------- 11, 1 Sep 2 11:56 srh1-0c0i6l0
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
The mapping between the SCSI generic device names (sg) and their corresponding
|
||
names when controlled by other upper level drivers (i.e. sd, sr or st) can
|
||
be seen by looking for name matches when the second letter is ignored.
|
||
Hence "sdh0-0c0i0l0" and "sgh0-0c0i0l0" refer to the same device. By process
|
||
of elimination the "sgh1-0c0i5l0" filename is the scanner since that class
|
||
of devices can only be accessed via the sg interface.
|
||
</P
|
||
><P
|
||
> The scsidev package also includes the ability to introduce names like
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/scsi/scanner</TT
|
||
> by manipulating the <TT
|
||
CLASS="filename"
|
||
> /etc/scsi.alias</TT
|
||
> configuration file. The package also includes
|
||
the useful <B
|
||
CLASS="command"
|
||
>rescan-scsi-bus.sh</B
|
||
> utility.
|
||
For further information about <B
|
||
CLASS="command"
|
||
>scsidev</B
|
||
> see
|
||
<A
|
||
HREF="#W6"
|
||
>W6</A
|
||
>. On my system, both devfs and scsidev
|
||
co-exist happily.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="kconfig"
|
||
></A
|
||
>Chapter 4. Kernel Configuration</H1
|
||
><P
|
||
> The Linux kernel configuration is usually found in the kernel source in
|
||
the file: <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/.config</TT
|
||
> . It is not
|
||
recommended to edit this file directly but to use one of these configuration
|
||
options:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
><B
|
||
CLASS="command"
|
||
>make config</B
|
||
> - starts a character based
|
||
questions and answer session</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
><B
|
||
CLASS="command"
|
||
>make menuconfig</B
|
||
> - starts a
|
||
terminal-oriented configuration tool (using ncurses)</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
><B
|
||
CLASS="command"
|
||
>make xconfig</B
|
||
> - starts a
|
||
X based configuration tool</P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><P
|
||
> The descriptions of these selections that is displayed by the associated
|
||
help button can be found in the flat ASCII file:
|
||
<TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/Documentation/Configure.help</TT
|
||
>
|
||
</P
|
||
><P
|
||
> Ultimately these configuration tools edit the <TT
|
||
CLASS="filename"
|
||
>.config</TT
|
||
>
|
||
file. An option will either indicate some driver is built into the
|
||
kernel ("=y") or will be built as a module ("=m") or is not selected.
|
||
The unselected state can either be indicated by a line starting with
|
||
"#" (e.g. "# CONFIG_SCSI is not set") or by the absence of the relevant
|
||
line from the <TT
|
||
CLASS="filename"
|
||
>.config</TT
|
||
> file.
|
||
</P
|
||
><P
|
||
> The 3 states of the main selection option for the SCSI subsystem (which
|
||
actually selects the SCSI mid level driver) follow. Only one of these
|
||
should appear in an actual <TT
|
||
CLASS="filename"
|
||
>.config</TT
|
||
> file:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> CONFIG_SCSI=y
|
||
CONFIG_SCSI=m
|
||
# CONFIG_SCSI is not set
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Some other common SCSI configuration options are:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> CONFIG_BLK_DEV_SD [disk (sd) driver]
|
||
CONFIG_SD_EXTRA_DEVS [extra slots for disks added later]
|
||
CONFIG_BLK_DEV_SR [SCSI cdrom (sr) driver]
|
||
CONFIG_BLK_DEV_SR_VENDOR [allow vendor specific cdrom commands]
|
||
CONFIG_SR_EXTRA_DEVS [extra slots for cdroms added later]
|
||
CONFIG_CHR_DEV_ST [tape (st) driver]
|
||
CONFIG_CHR_DEV_OSST [OnSteam tape (osst) driver]
|
||
CONFIG_CHR_DEV_SG [SCSI generic (sg) driver]
|
||
CONFIG_DEBUG_QUEUES [for debugging multiple queues]
|
||
CONFIG_SCSI_MULTI_LUN [allow probes above lun 0]
|
||
CONFIG_SCSI_CONSTANTS [symbolic decode of SCSI errors]
|
||
CONFIG_SCSI_LOGGING [allow logging to be runtime selected]
|
||
|
||
CONFIG_SCSI_<ll_driver> [numerous lower level adapter drivers]
|
||
CONFIG_SCSI_DEBUG [lower level driver for debugging]
|
||
|
||
CONFIG_SCSI_PPA [older parallel port zip drives]
|
||
CONFIG_SCSI_IMM [newer parallel port zip drives]
|
||
|
||
CONFIG_BLK_DEV_IDESCSI [ide-scsi pseudo adapter]
|
||
CONFIG_I2O_SCSI [scsi command set over i2o bus]
|
||
CONFIG_SCSI_PCMCIA [for SCSI HBAs on PCMCIA bus]
|
||
CONFIG_USB_STORAGE [usb "mass storage" type]
|
||
|
||
CONFIG_MAGIC_SYSRQ [Alt+SysRq+S for emergency sync]
|
||
[Alt+SyrRq+U for emergency remount ro]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> If the root file system is on a SCSI disk then it makes sense
|
||
to build into the kernel the SCSI mid level, the sd driver and
|
||
the host adapter driver that the disk is connected to. In most cases
|
||
it is usually safe to build the sr, st and sg drivers as modules so
|
||
that they are loaded as required. If a device like a scanner is on
|
||
a separate adapter then its driver may well be built as a module. In
|
||
this case, that adapter driver will need to be loaded before the
|
||
scanner will be recognized.
|
||
</P
|
||
><P
|
||
> Linux distributions have many of the SCSI subsystem drivers built as
|
||
modules since building all of them in would lead to a very
|
||
large kernel that would exceed the capabilities of the boot loader.
|
||
This leads to a "chicken and the egg" problem in which the SCSI
|
||
drivers are needed to load the root file system and vice versa. The
|
||
2 phase load used by the initrd device addresses this problem
|
||
(see <A
|
||
HREF="#modparams"
|
||
>Chapter 6</A
|
||
> for more details).
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="bparams"
|
||
></A
|
||
>Chapter 5. Boot Parameters</H1
|
||
><P
|
||
> On a PC the motherboard's BIOS together with the SCSI BIOS provided
|
||
by most SCSI host adapters takes care of the problem of loading the
|
||
boot loader's image from a SCSI disk into memory and executing it. This
|
||
may require some settings to be changed in the motherboard's BIOS. When
|
||
more than one SCSI adapter is involved, the SCSI BIOS settings may need
|
||
to change to indicate which one contains the disk with the boot image.
|
||
The boot image make also come from an ATA (IDE) disk, a bootable CD-ROM or
|
||
a floppy.
|
||
</P
|
||
><P
|
||
> Both <EM
|
||
>lilo</EM
|
||
> and <EM
|
||
>grub</EM
|
||
> are commonly
|
||
used boot loaders with Linux. Their configuration files are in
|
||
<TT
|
||
CLASS="filename"
|
||
>/etc/lilo.conf</TT
|
||
> and <TT
|
||
CLASS="filename"
|
||
>/etc/grub.conf</TT
|
||
>
|
||
<A
|
||
NAME="AEN264"
|
||
HREF="#FTN.AEN264"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[3]</SPAN
|
||
></A
|
||
>
|
||
respectively. One difference is that after changing lilo's configuration the
|
||
<B
|
||
CLASS="command"
|
||
>lilo</B
|
||
> command must be executed for the changes to take
|
||
effect (and there is no equivalent requirement for grub). See their "man"
|
||
pages for usage information. An excellent paper on lilo and the Linux bootup
|
||
sequence can be found
|
||
<A
|
||
HREF="ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz</TT
|
||
></A
|
||
>.
|
||
For further information on grub see
|
||
<A
|
||
HREF="http://www.gnu.org/software/grub"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.gnu.org/software/grub</TT
|
||
></A
|
||
>.
|
||
</P
|
||
><P
|
||
> Some boot parameters related to the SCSI subsystem:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> single [enter single user mode]
|
||
<n> [enter run level <n> {0..6}]
|
||
root=/dev/sda6 [*]
|
||
root=/dev/scsi/host0/bus0/target0/lun0/part6 [*]
|
||
root=/dev/sd/c0b0t0u0p6 [*]
|
||
devfs=mount [overrides CONFIG_DEVFS_MOUNT=n]
|
||
devfs=nomount [overrides CONFIG_DEVFS_MOUNT=y]
|
||
init=<command> [executes <command> rather than init]
|
||
quiet [reduce output to console during boot]
|
||
debug [increase output to console during boot]
|
||
nmi_watchdog=0 [turn off NMI watchdog on a SMP machine]
|
||
max_scsi_luns=1 [limits SCSI bus scans to lun==0]
|
||
scsi_allow_ghost_devices=<n>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
* When devfs is in use the initial read-only mount
|
||
of the root partition can be done via the old
|
||
/dev/sd<a><n> notation or the new devfs
|
||
notation (and two of these are shown).
|
||
The joint "root=/dev/sda6 single" may be useful
|
||
when disk or adapter changes have broken the
|
||
kernel boot load.
|
||
</P
|
||
><P
|
||
> The "root=" argument may also be a hex number. For example, if the root
|
||
partition is on <TT
|
||
CLASS="filename"
|
||
>/dev/sda3</TT
|
||
> then "root=803" is
|
||
appropriate. The last two digits are the minor device number discussed
|
||
in an earlier section.
|
||
</P
|
||
><P
|
||
> The default argument to the "init" parameter is <TT
|
||
CLASS="filename"
|
||
>/sbin/init
|
||
</TT
|
||
> (see man (8) init). If files such as <TT
|
||
CLASS="filename"
|
||
>/etc/fstab
|
||
</TT
|
||
> have incorrect entries, it may be useful to drop directly
|
||
into a shell with "init=/bin/bash". However if shared libraries files
|
||
or their paths are inappropriate this may also fail. That leaves
|
||
"init=/sbin/sash" which is a statically linked shell with many useful
|
||
commands (for repairing a system) built in (see man (8) sash).
|
||
</P
|
||
><P
|
||
> When Linux fails to boot after reporting a message like:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> VFS: Cannot open root device 08:02
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
then the kernel expected to find a root partition on device
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/sda2</TT
|
||
> and did not. The numbers in the
|
||
error message are major and minor device numbers (in hex)
|
||
[see <A
|
||
HREF="#dnames"
|
||
>Section 3.2</A
|
||
> for
|
||
the mapping to device names]. In such situations the "root" boot option
|
||
can be useful (also the <B
|
||
CLASS="command"
|
||
>rdev</B
|
||
> command can be used to
|
||
modify where the boot image looks for the root partition).
|
||
</P
|
||
><P
|
||
> Lilo's configuration file <TT
|
||
CLASS="filename"
|
||
>/etc/lilo.conf</TT
|
||
>
|
||
can take the "root=" option in two ways. The normal way is a line
|
||
like: 'root=/dev/sda2'.
|
||
In this case <TT
|
||
CLASS="filename"
|
||
>/dev/sda2</TT
|
||
> is converted into major
|
||
and minor numbers based on the state of the system <EM
|
||
>when
|
||
</EM
|
||
> the <B
|
||
CLASS="command"
|
||
>lilo</B
|
||
> command is executed. This can be
|
||
a nuisance, especially if hardware is going to be re-arranged.
|
||
The other way is a line of the form: 'append="root=/dev/sda2"'
|
||
In this case the <TT
|
||
CLASS="filename"
|
||
>/dev/sda2</TT
|
||
> is passed through
|
||
to the kernel the next time it is started. This is the same as
|
||
giving the "root=/dev/sda2" string at the kernel boot time prompt.
|
||
It is interpreted by the kernel at startup (once the HBAs and their
|
||
attached devices have been recognized) and thus is more flexible.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="modparams"
|
||
></A
|
||
>Chapter 6. Modules and their Parameters</H1
|
||
><P
|
||
> There are many SCSI related modules. The mid and upper level modules
|
||
are listed below:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> scsi_mod.o </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> sd_mod.o </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> sr_mod.o </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> st.o [osst.o] </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> sg.o </P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><P
|
||
> Notice that the first 3 have "_mod" appended to their normal driver names.
|
||
Lower level drivers tend to use the name (or an abbreviation) of the
|
||
HBA's manufacturer (e.g. advansys)
|
||
plus optionally the chip number of the major controller chip (e.g.
|
||
sym53c8xx for symbios controllers based on the NCR 53c8?? family of chips).
|
||
</P
|
||
><P
|
||
> All SCSI modules depend on the mid level. This means if the SCSI mid
|
||
level is not built into the kernel and if <TT
|
||
CLASS="filename"
|
||
>scsi_mod.o</TT
|
||
>
|
||
has not already been loaded then a command like <B
|
||
CLASS="command"
|
||
>modprobe st</B
|
||
>
|
||
will cause the <TT
|
||
CLASS="filename"
|
||
>scsi_mod.o</TT
|
||
> module to be loaded. There
|
||
could well be other dependencies, for example <B
|
||
CLASS="command"
|
||
>modprobe sr_mod
|
||
</B
|
||
> will also cause the cdrom module to be loaded if it hasn't been
|
||
already. Also if the SCSI mid level is a module, then all other SCSI
|
||
subsystem drivers must be modules (this is enforced by the kernel build
|
||
configuration tools).
|
||
</P
|
||
><P
|
||
> Modules can be loaded with the <B
|
||
CLASS="command"
|
||
>modprobe <module_name>
|
||
</B
|
||
> command which will try to load any modules that the
|
||
nominated <module_name> depends on.
|
||
Also <module_name> does not need the trailing ".o" extension which
|
||
is assumed if not given. The <B
|
||
CLASS="command"
|
||
>insmod <module_name></B
|
||
>
|
||
command will also try
|
||
and load <module_name> but without first loading modules it depends on.
|
||
Rules for how modules can cause other modules to be loaded (with
|
||
appropriate parameters appended) are usually placed in the file
|
||
<TT
|
||
CLASS="filename"
|
||
>/etc/modules.conf</TT
|
||
>. [Note that in earlier Linux kernels
|
||
this file was often called <TT
|
||
CLASS="filename"
|
||
>/etc/conf.modules</TT
|
||
>.]
|
||
For further information about the format of this file try
|
||
<B
|
||
CLASS="command"
|
||
>man modules.conf</B
|
||
>.
|
||
</P
|
||
><P
|
||
> Any module can have its allowable command line parameters queried with
|
||
this command: <B
|
||
CLASS="command"
|
||
>modinfo -p <module_name></B
|
||
>.
|
||
</P
|
||
><P
|
||
> When upper level drivers are initialized and if there are no hosts active
|
||
then the mid level will attempt to load a module called "scsi_hostadapter".
|
||
An "alias" can then be used to associate "scsi_hostadapter" with the actual
|
||
name of the lower level (adapter) driver.
|
||
For example, a line like "alias scsi_hostadapter aic7xxx" in the
|
||
<TT
|
||
CLASS="filename"
|
||
>/etc/modules.conf</TT
|
||
> file would cause the aic7xxx module
|
||
to be loaded (if there were no lower level drivers already active).
|
||
<A
|
||
NAME="AEN322"
|
||
HREF="#FTN.AEN322"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[4]</SPAN
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> There is a special relationship between the module parameter
|
||
"scsi_hostadapter" and the initrd file system. For more information see
|
||
<B
|
||
CLASS="command"
|
||
>man initrd</B
|
||
> and <B
|
||
CLASS="command"
|
||
>man mkinitrd</B
|
||
>.
|
||
<A
|
||
NAME="AEN328"
|
||
HREF="#FTN.AEN328"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[5]</SPAN
|
||
></A
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="procfs"
|
||
></A
|
||
>Chapter 7. Proc pseudo file system</H1
|
||
><P
|
||
> The proc pseudo file system provides some useful information about the
|
||
SCSI subsystem. The kernel configuration option that selects "proc_fs"
|
||
is CONFIG_PROC_FS and in almost all cases it should be selected. SCSI
|
||
specific information
|
||
is found under the directory <TT
|
||
CLASS="filename"
|
||
>/proc/scsi</TT
|
||
>. Probably
|
||
the most commonly accessed entry is <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/scsi</B
|
||
>
|
||
which lists the attached SCSI devices. See
|
||
<A
|
||
HREF="#mlproc"
|
||
>Section 8.3</A
|
||
> for more details.
|
||
</P
|
||
><P
|
||
> The lower level drivers are allocated proc_fs entries of the form:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> /proc/scsi/<driver_name>/<scsi_adapter_number>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
where the <driver_name> is something like "aic7xxx" or "BusLogic". The
|
||
<scsi_adapter_number> (also known as the host number) is the same number
|
||
that was discussed in <A
|
||
HREF="#scsiaddr"
|
||
>Section 3.1</A
|
||
>. Note that one driver
|
||
may control one or more hosts.
|
||
What is stored in this file is lower level driver dependent (and in the
|
||
case of some adapter drivers it
|
||
is possible to set parameters via this file). When reporting problems
|
||
to newsgroups or maintainers it is useful to include the output of this
|
||
file (e.g. <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/aic7xxx/0 </B
|
||
>).
|
||
</P
|
||
><P
|
||
> The cdrom driver provides information about attached cdrom devices
|
||
in the <TT
|
||
CLASS="filename"
|
||
>/proc/sys/dev/cdrom</TT
|
||
> directory. This will
|
||
include both SCSI devices (i.e. those controlled by the sr driver) and
|
||
IDE devices (i.e. those controlled by the ide-cd driver).
|
||
See <A
|
||
HREF="#srproc"
|
||
>Section 9.2.3</A
|
||
>.
|
||
</P
|
||
><P
|
||
> The sg driver provides information about its state and attached hosts and
|
||
devices in the <TT
|
||
CLASS="filename"
|
||
>/proc/scsi/sg</TT
|
||
> directory.
|
||
See <A
|
||
HREF="#sgproc"
|
||
>Section 9.4.3</A
|
||
>.
|
||
</P
|
||
><P
|
||
> More general information on the proc pseudo file system can be found in
|
||
the kernel source file:
|
||
<TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/Documentation/filesystems/proc.txt</TT
|
||
>.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="mlevel"
|
||
></A
|
||
>Chapter 8. Mid Level, Unifying layer</H1
|
||
><P
|
||
> The SCSI mid level is common to all usage of the SCSI subsystem. Probably
|
||
its most important role is to define internal interfaces and services that
|
||
are used by all other SCSI drivers. These internal mechanisms are not
|
||
discussed in this document [see ref: <A
|
||
HREF="#W2"
|
||
>W2</A
|
||
>].
|
||
</P
|
||
><P
|
||
> The primary kernel configuration parameter "CONFIG_SCSI" determines whether
|
||
the mid level is built in (when "=y") or a module (when "=m"). If
|
||
"CONFIG_SCSI=m" then all other SCSI subsystem drivers must also be modules.
|
||
</P
|
||
><P
|
||
> When the mid level is built as a module then it probably never needs to be
|
||
loaded explicitly because using 'modprobe' to load any other SCSI subsystem
|
||
module will cause the mid level to be loaded first (if it is not already).
|
||
</P
|
||
><P
|
||
> Some upper and lower level drivers do not (fully) load if there are no
|
||
devices for that driver to control. Sometimes the report is loud as in
|
||
this case for the imm driver which controls zip drives connected to a
|
||
parallel port:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> $ modprobe imm
|
||
imm.o: init_module: No such device
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
<B
|
||
CLASS="command"
|
||
>lsmod</B
|
||
> will not show the "imm" module as loaded.
|
||
In other cases the result is more subtle. For example, if the sg driver
|
||
is loaded in a system with no (real or pseudo) scsi devices then the
|
||
<TT
|
||
CLASS="filename"
|
||
>/proc/scsi/sg</TT
|
||
> directory will not appear. [It will
|
||
be created when the first scsi device is recognized.]
|
||
</P
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="mlbparams"
|
||
></A
|
||
>8.1. boot parameters</H1
|
||
><P
|
||
> SCSI drivers that are built into the kernel are checked in a pre-determined
|
||
order to see if HBAs that they can control are present. The user has no
|
||
control over this order which in most cases is
|
||
arbitrary but in the case of some older ISA adapters is required to stop
|
||
misidentification
|
||
<A
|
||
NAME="AEN371"
|
||
HREF="#FTN.AEN371"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[6]</SPAN
|
||
></A
|
||
>
|
||
.
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
scsi_logging=<n>
|
||
where <n> is 0 to turn logging off
|
||
where <n> is non-zero to turn logging on
|
||
|
||
max_scsi_luns=<n>
|
||
where <n> is a number between 1 and 8 (< lk 2.4.7),
|
||
>= lk 2.4.7 the upper limit can be much larger
|
||
|
||
scsi_allow_ghost_devices=<n>
|
||
where (<n> - 1) is the maximum lu number to ghost if the
|
||
the corresponding device is offline. When <n>==0
|
||
(default) then don't ghost any devices (in lk 2.4.26
|
||
and later)
|
||
|
||
scsihosts=host0:hosts1::host3
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The recently introduced devfs defines a "scsihosts"
|
||
boot time parameter to give the user some control over this. See the
|
||
devfs documentation [ref: <A
|
||
HREF="#W5"
|
||
>W5</A
|
||
>] for a description.
|
||
The host names given in the list to the "scsihosts" boot option are
|
||
the names of lower level drivers (e.g. "scsihosts=advansys:imm::ide-scsi").
|
||
<A
|
||
NAME="AEN377"
|
||
HREF="#FTN.AEN377"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[7]</SPAN
|
||
></A
|
||
>
|
||
<A
|
||
NAME="AEN383"
|
||
HREF="#FTN.AEN383"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[8]</SPAN
|
||
></A
|
||
>
|
||
Devfs does not need to be present for "scsihosts" to be used. The
|
||
"scsihosts" parameter, if given, is echoed during in the boot up messages.
|
||
For example:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> scsi: host order: advansys:imm::ide-scsi
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
Also if multiple HBA are present in a system then they are scanned in
|
||
a fixed order (see footnote). The "scsihosts" parameter only effects how
|
||
these HBAs are indexed (i.e. which SCSI adapter numbers are associated with
|
||
them by the kernel). In the above example, if the "imm" driver is not found
|
||
during boot up, then the scsi adapter number "1" is not allocated. If the
|
||
"imm" driver is later loaded as a module, then it will adopt scsi adapter
|
||
number "1". If a driver that is not named in "scsihosts" is found, then
|
||
it will get the next available scsi adapter number (e.g. a built in
|
||
aic7xxx driver would get scsi adapter number "2" in the above example).
|
||
</P
|
||
><P
|
||
> A full list of kernel parameters with some explanations can be found
|
||
in the file <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/Documentation/kernel-parameters.txt
|
||
</TT
|
||
>.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="mlmparams"
|
||
></A
|
||
>8.2. module parameters</H1
|
||
><P
|
||
> If SCSI disks are present in the system then it usually is better to
|
||
build the mid level driver into the kernel. However if the SCSI
|
||
subsystem is only being used periodically (e.g. to burn CD-Rs on
|
||
an ATAPI CD writer) then building the mid level as a module is fine.
|
||
The module load time options are the same as the driver's built in
|
||
options:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> scsi_logging_level=<n>
|
||
where <n> is the logging level mask (0 for logging off)
|
||
max_scsi_luns=<n>
|
||
scsihosts=host0::host2
|
||
scsi_allow_ghost_devices=<n>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="mlproc"
|
||
></A
|
||
>8.3. proc interface</H1
|
||
><P
|
||
> To display the SCSI devices currently attached (and recognized) by the SCSI
|
||
subsystem use <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/scsi</B
|
||
>.
|
||
</P
|
||
><P
|
||
> The output looks like this:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> Attached devices:
|
||
Host: scsi0 Channel: 00 Id: 02 Lun: 00
|
||
Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10
|
||
Type: CD-ROM ANSI SCSI revision: 02
|
||
Host: scsi1 Channel: 00 Id: 00 Lun: 00
|
||
Vendor: IBM Model: DNES-309170W Rev: SA30
|
||
Type: Direct-Access ANSI SCSI revision: 03
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> After the "Attached devices:" line there are 3 lines for each recognized
|
||
device. The first of these lines is SCSI address information discussed in
|
||
<A
|
||
HREF="#scsiaddr"
|
||
>Section 3.1</A
|
||
>. The following 2 lines of data are
|
||
obtained from a INQUIRY
|
||
command that was performed on the device when it was attached. See
|
||
<A
|
||
HREF="#sg"
|
||
>Section 9.4</A
|
||
> for the relationship between the ordering of these
|
||
devices compared with the sg driver's ordering (which most of the time is
|
||
the same).
|
||
</P
|
||
><P
|
||
> Existing devices can be removed using <B
|
||
CLASS="command"
|
||
> echo "scsi remove-single-device <h> <b> <t> <l>"
|
||
> /proc/scsi/scsi</B
|
||
>
|
||
where the variables are host, bus (channel), target (scsi id) and lun. The
|
||
success (or otherwise) of this command can be determined by sending a
|
||
subsequent <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/scsi</B
|
||
> command. The removal
|
||
will fail if the
|
||
device is busy (e.g. if a file system on the device is mounted).
|
||
</P
|
||
><P
|
||
> New devices can be added using <B
|
||
CLASS="command"
|
||
> echo "scsi add-single-device <h> <b> <t> <l>"
|
||
> /proc/scsi/scsi</B
|
||
>
|
||
where the variables are host, bus (channel), target (scsi id) and lun. The
|
||
success (or otherwise) of this command can be determined by sending a
|
||
subsequent <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/scsi</B
|
||
> command.
|
||
<A
|
||
NAME="AEN407"
|
||
HREF="#FTN.AEN407"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[9]</SPAN
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> The SCSI subsystem does not support hot-plugging of SCSI devices (there may
|
||
also be electrical issues on the associated SCSI parallel bus). It is
|
||
recommended that those who use add+remove-single-device make sure that
|
||
other devices on that SCSI bus are inactive if re-plugging is going to
|
||
take place.
|
||
</P
|
||
><P
|
||
> To output a list of internal SCSI command blocks use <B
|
||
CLASS="command"
|
||
> echo "scsi dump <n>" > /proc/scsi/scsi</B
|
||
>
|
||
where the numeric value of <n> doesn't matter. This is probably only of
|
||
interest to people chasing down bugs within the SCSI subsystem.
|
||
</P
|
||
><P
|
||
> To start (or stop) logging information being sent to the console/log use
|
||
<B
|
||
CLASS="command"
|
||
> echo "scsi log <token> <n>" > /proc/scsi/scsi
|
||
</B
|
||
>
|
||
where <token> is one of: {all, none, error, timeout, scan, mlqueue,
|
||
mlcomplete, llqueue, llcomplete, hlqueue, hlcomplete, ioctl}
|
||
and <n> is a number between 0 and 7. The tokens "all" and "none" don't
|
||
take an <n> argument. Prefix meanings:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> hl upper level drivers [exception: sg uses "timeout"]
|
||
ml mid level
|
||
ll lower level drivers
|
||
[adapter drivers often have there own flags]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
The value "0" turns off logging while "7" maximizes the volume of output.
|
||
Logging information will only be output if CONFIG_SCSI_LOGGING was selected
|
||
in the kernel build.
|
||
</P
|
||
><DIV
|
||
CLASS="warning"
|
||
><P
|
||
></P
|
||
><TABLE
|
||
CLASS="warning"
|
||
WIDTH="100%"
|
||
BORDER="0"
|
||
><TR
|
||
><TD
|
||
WIDTH="25"
|
||
ALIGN="CENTER"
|
||
VALIGN="TOP"
|
||
><IMG
|
||
SRC="../images/warning.gif"
|
||
HSPACE="5"
|
||
ALT="Warning"></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
><P
|
||
> Warning: "scsi log all" (and several other variants) can cause a logging
|
||
infinite loop if the log file (typically <TT
|
||
CLASS="filename"
|
||
>/var/log/messages
|
||
</TT
|
||
>) lies on a SCSI disk. Either turn off the kernel logging
|
||
daemon or direct its output to a non SCSI device.
|
||
</P
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
></DIV
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="ulevel"
|
||
></A
|
||
>Chapter 9. Upper level drivers</H1
|
||
><P
|
||
> The upper level drivers maintain the kernel side of the OS interface
|
||
for the logical class of devices they represent (e.g. disks). They
|
||
are also responsible for managing certain kernel and SCSI subsystem
|
||
resources such as kernel memory and SCSI command structures.
|
||
Applications in the user space access these drivers by opening a special
|
||
file (block or char) typically found in the <TT
|
||
CLASS="filename"
|
||
>/dev
|
||
</TT
|
||
> directory tree.
|
||
</P
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="sd"
|
||
></A
|
||
>9.1. Disk driver (sd)</H1
|
||
><P
|
||
> Two types of SCSI devices are accessible via the sd driver:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>"direct access" devices which are usually magnetic disks.
|
||
[SCSI peripheral device code is 0]</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>"Optical memory devices" which are often called MOD
|
||
disks. [SCSI peripheral device code is 7]</P
|
||
></LI
|
||
></UL
|
||
>
|
||
The sd driver is a block device which means that it is closely associated
|
||
with the block subsystem. It also supports the concept of partitions.
|
||
[<B
|
||
CLASS="command"
|
||
>man sd</B
|
||
> dates from 1992.]
|
||
</P
|
||
><P
|
||
> The sd driver is capable of recognizing 128 disks when it is loaded
|
||
at kernel boot time or later as a module. However, once it is loaded,
|
||
it will only recognize a fixed number of additional disks. The number
|
||
of additional disks that can be accommodated is set by the kernel
|
||
configuration parameter CONFIG_SD_EXTRA_DEVS whose default value is 40.
|
||
</P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="sdbparams"
|
||
></A
|
||
>9.1.1. sd boot parameters</H2
|
||
><P
|
||
> None.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="sdmparams"
|
||
></A
|
||
>9.1.2. sd module parameters</H2
|
||
><P
|
||
> The sd driver takes no parameters when loaded as a module. Note that
|
||
its module name is <TT
|
||
CLASS="filename"
|
||
>sd_mod.o</TT
|
||
>.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="sr"
|
||
></A
|
||
>9.2. CDROM driver (sr or scd)</H1
|
||
><P
|
||
> CDROM and DVD drives (and WORM devices) are accessible via the sr upper
|
||
level device driver.
|
||
While "sr" is the device driver name, "sr_mod" is its module name.
|
||
The device file name is either <TT
|
||
CLASS="filename"
|
||
>/dev/sr<n></TT
|
||
> or
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/scd<n></TT
|
||
>.
|
||
</P
|
||
><P
|
||
> Following is a diagram illustrating the CDROM subsystem of which sr is a
|
||
part:
|
||
</P
|
||
><DIV
|
||
CLASS="mediaobject"
|
||
><P
|
||
><IMG
|
||
SRC="cdrom.jpg"><DIV
|
||
CLASS="caption"
|
||
><P
|
||
> The architecture of the CD-ROM subsystem.
|
||
</P
|
||
></DIV
|
||
></P
|
||
></DIV
|
||
><P
|
||
> This diagram glosses over some of the differences between the
|
||
protocol stacks. CDROM device names are <EM
|
||
>not</EM
|
||
> maintained
|
||
by the uniform CDROM layer but rather by each individual protocol stack.
|
||
In the case of the SCSI subsystem, device names are maintained by the
|
||
sr driver while the IDE subsystem maintains device names with its
|
||
central "ide" driver (i.e. not by the ide-cd driver). USB and IEEE1394
|
||
cd devices names are maintained by their respective stacks. This may
|
||
partially explain why the <TT
|
||
CLASS="filename"
|
||
>/dev/cdrom</TT
|
||
> is often a
|
||
symbolic link to the appropriate subsystem's device name.
|
||
</P
|
||
><P
|
||
> Two types of SCSI devices are accessible via the sr driver:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>CD-ROM devices (including DVD players)
|
||
[SCSI peripheral device code is 5]</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>"Write-once read-multiple" devices which are known as WORMs.
|
||
[SCSI peripheral device code is 4]</P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><P
|
||
> The sr driver is capable of recognizing 256 CDROM/DVD drives when it is
|
||
loaded at kernel boot time or later as a module. However, once it is
|
||
loaded, it will only recognize a fixed number of additional drives. The
|
||
number of additional drives that can be accommodated is set by the kernel
|
||
configuration parameter CONFIG_SR_EXTRA_DEVS whose default value is 2.
|
||
</P
|
||
><P
|
||
> People often use the <B
|
||
CLASS="command"
|
||
>dd</B
|
||
> command to read a data CDROM
|
||
containing an iso9660 file system. If a count argument is not given then
|
||
the <B
|
||
CLASS="command"
|
||
>dd</B
|
||
> command will read the number of 2048 byte sectors
|
||
indicated by the SCSI Read Capacity command. Unfortunately this can
|
||
include unwritten (or "run out") sectors at the end of the image that can
|
||
cause I/O errors. Use the <B
|
||
CLASS="command"
|
||
>isosize</B
|
||
> command (see its man
|
||
page) to find the true length of the iso9660 image and use that in the
|
||
"count=" argument given to the <B
|
||
CLASS="command"
|
||
>dd</B
|
||
> command.
|
||
</P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="srbparams"
|
||
></A
|
||
>9.2.1. sr boot parameters</H2
|
||
><P
|
||
> None.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="srmparams"
|
||
></A
|
||
>9.2.2. sr module parameters</H2
|
||
><P
|
||
> Doing a test to find out if a cdrom drive supports XA mode (mode 2) triggers
|
||
firmware bugs on some drives. Consequently the check for XA mode support is
|
||
turned off by default. The following module parameter is provided:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> xa_test=<0|1>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
to override the default. [Currently there seems to be no way to turn on
|
||
XA mode testing when the sr driver is built into the kernel.]
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="srproc"
|
||
></A
|
||
>9.2.3. sr proc interface</H2
|
||
><P
|
||
> All the following files are readable by all and produce ASCII output
|
||
when read:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> /proc/sys/dev/cdrom/autoclose
|
||
/proc/sys/dev/cdrom/autoeject
|
||
/proc/sys/dev/cdrom/check_media
|
||
/proc/sys/dev/cdrom/debug
|
||
/proc/sys/dev/cdrom/info
|
||
/proc/sys/dev/cdrom/lock
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
They reflect the current state of the CDROM subsystem. This location
|
||
is part of the procfs's window through to the sysctl configuration
|
||
mechanism (see <B
|
||
CLASS="command"
|
||
>man sysctl</B
|
||
>). All but
|
||
<TT
|
||
CLASS="filename"
|
||
>info</TT
|
||
> are writable by the superuser. There is
|
||
a column for each CDROM and DVD player in the system in
|
||
<TT
|
||
CLASS="filename"
|
||
>info</TT
|
||
> (not just SCSI devices).
|
||
</P
|
||
><P
|
||
> As an
|
||
example, the auto eject feature can be turned on by the superuser with
|
||
the command <B
|
||
CLASS="command"
|
||
>echo "1" > /proc/sys/dev/cdrom/autoeject</B
|
||
>.
|
||
This will cause cdroms to be ejected from the drive when unmounted.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="sratapi"
|
||
></A
|
||
>9.2.4. ATAPI cdroms</H2
|
||
><P
|
||
> Many Linux users have no SCSI devices (or adapters) in their systems. They
|
||
become a little perplexed as to why cd writer software (e.g.
|
||
<B
|
||
CLASS="command"
|
||
>cdrecord</B
|
||
> and <B
|
||
CLASS="command"
|
||
>cdrdao</B
|
||
>)
|
||
and cd music reading programs (e.g. <B
|
||
CLASS="command"
|
||
>cdparanoia</B
|
||
>) use
|
||
the Linux SCSI subsystem. The answer is that these programs need lower level
|
||
access to these devices. ATAPI (ATA Packet Interface) is essentially
|
||
a SCSI command set sent over an ATA
|
||
<A
|
||
NAME="AEN489"
|
||
HREF="#FTN.AEN489"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[10]</SPAN
|
||
></A
|
||
>
|
||
transport. [The discussion in this section is also applicable to ATAPI
|
||
tape drives and ATAPI floppy drives.]
|
||
</P
|
||
><P
|
||
> Currently both <B
|
||
CLASS="command"
|
||
>cdrecord</B
|
||
> and <B
|
||
CLASS="command"
|
||
>cdparanoia</B
|
||
>
|
||
interface to the SCSI generic driver (sg) and, in the case of ATAPI
|
||
cd devices, use the ide-scsi pseudo device driver to access the hardware.
|
||
This may change in the future as in the 2.4 series kernels a packet
|
||
interface ioctl has been added to the uniform cdrom layer (see the diagram
|
||
in <A
|
||
HREF="#sr"
|
||
>Section 9.2</A
|
||
> above).
|
||
<A
|
||
NAME="AEN495"
|
||
HREF="#FTN.AEN495"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[11]</SPAN
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> The default action of the IDE subsystem in Linux is to claim all ATA
|
||
devices for its built-in drivers. In the case of an ATAPI cd writer, it
|
||
will be claimed by the built-in ide-cd driver. Once this has happened,
|
||
the SCSI subsystem is unable to get control over an ATAPI device. The
|
||
ide-scsi (pseudo lower level SCSI) driver can only register ATAPI devices
|
||
in the SCSI subsystem that have <EM
|
||
>not</EM
|
||
> already been
|
||
claimed by the IDE subsystem.
|
||
</P
|
||
><P
|
||
> Notice the <EM
|
||
>built-in</EM
|
||
> qualification in the previous
|
||
paragraph. If both the ide-cd and ide-scsi drivers are modules then the
|
||
first one loaded will claim the ATAPI cd devices (e.g. cd/dvd readers and
|
||
writers). Furthermore you can switch the controlling driver module by
|
||
<B
|
||
CLASS="command"
|
||
>rmmod</B
|
||
>-ing one and <B
|
||
CLASS="command"
|
||
>modprobe</B
|
||
>-ing the
|
||
other.
|
||
</P
|
||
><P
|
||
> Probably the most flexible way to instruct the IDE core driver that you
|
||
want the cd writer at <TT
|
||
CLASS="filename"
|
||
>/dev/hdd</TT
|
||
> accessible to
|
||
<B
|
||
CLASS="command"
|
||
>cdrecord</B
|
||
> is to use the kernel boot option:
|
||
"hdd=ide-scsi". This will cause the ide-cd driver to bypass
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/hdd</TT
|
||
> (irrespective of whether ide-cd driver is
|
||
built-in or a module). As long as the ide-scsi driver is built-in or a
|
||
module then it will "capture" the cd writer
|
||
at <TT
|
||
CLASS="filename"
|
||
>/dev/hdd</TT
|
||
> (with the IDE core driver loading the
|
||
ide-scsi module if required).
|
||
</P
|
||
><P
|
||
> The ide-cd driver module can be instructed to ignore certain ATA devices
|
||
with the following syntax:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> modprobe ide-cd ignore='hdc hdd'
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
In this case the ide-cd driver will ignore the devices at
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/hdc</TT
|
||
> and <TT
|
||
CLASS="filename"
|
||
>/dev/hdd</TT
|
||
> .
|
||
This effect can also be accomplished by placing a line like this:
|
||
"options ide-cd ignore=hdd" in the <TT
|
||
CLASS="filename"
|
||
>/etc/modules.conf</TT
|
||
>
|
||
file.
|
||
</P
|
||
><P
|
||
> A new option added in the lk 2.4 series is of the form "hdd=scsi".
|
||
This option seems to have a similar function to the "hdd=ide-scsi"
|
||
option discussed above. Furthermore "hdd=scsi" can only be used if
|
||
both the SCSI mid-level and the ide-scsi drivers are built into the
|
||
kernel (otherwise "BAD OPTION" is reported by the ide_setup function).
|
||
</P
|
||
><P
|
||
> To find out whether an ATAPI cd device is "owned" by the SCSI subsystem,
|
||
the output of <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/scsi</B
|
||
> can be checked.
|
||
Another technique is to observe the "drive name:" line of
|
||
<B
|
||
CLASS="command"
|
||
>cat /proc/sys/dev/cdrom/info</B
|
||
> for "sr" entries. The
|
||
following output is from my system:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> $ cat /proc/sys/dev/cdrom/info
|
||
CD-ROM information, Id: cdrom.c 3.12 2000/10/18
|
||
|
||
drive name: sr1 sr0
|
||
drive speed: 16 0
|
||
drive # of slots: 1 1
|
||
Can close tray: 1 1
|
||
Can open tray: 1 1
|
||
Can lock tray: 1 1
|
||
Can change speed: 1 1
|
||
Can select disk: 0 0
|
||
Can read multisession: 1 1
|
||
Can read MCN: 1 1
|
||
Reports media changed: 1 1
|
||
Can play audio: 1 1
|
||
Can write CD-R: 1 0
|
||
Can write CD-RW: 1 0
|
||
Can read DVD: 0 1
|
||
Can write DVD-R: 0 0
|
||
Can write DVD-RAM: 0 0
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Once an ATAPI cd writer at /dev/hdd has been registered by the SCSI
|
||
subsystem, then cdroms should be mounted via the "scd" device name
|
||
and cd players should also use the "scd" device. Strangely the
|
||
<B
|
||
CLASS="command"
|
||
>hdparm</B
|
||
> command should still use the <TT
|
||
CLASS="filename"
|
||
> /dev/hdd</TT
|
||
> device file (or the "echo ... > /proc/ide/hdd/settings"
|
||
method described in this <A
|
||
HREF="#idescsi"
|
||
>section</A
|
||
>).
|
||
<A
|
||
NAME="AEN523"
|
||
HREF="#FTN.AEN523"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[12]</SPAN
|
||
></A
|
||
>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="st"
|
||
></A
|
||
>9.3. Tape driver (st)</H1
|
||
><P
|
||
> The tape driver interface is documented in the file
|
||
<TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/drivers/scsi/README.st</TT
|
||
> and on the
|
||
st(4) man page (type <B
|
||
CLASS="command"
|
||
>man st</B
|
||
>). The file
|
||
<TT
|
||
CLASS="filename"
|
||
>README.st</TT
|
||
> also documents the different parameters and
|
||
options of the driver together with the basic mechanisms used in the driver.
|
||
</P
|
||
><P
|
||
> The tape driver is usually accessed via the <B
|
||
CLASS="command"
|
||
>mt</B
|
||
> command
|
||
(see <B
|
||
CLASS="command"
|
||
>man mt</B
|
||
>). <B
|
||
CLASS="command"
|
||
>mtx</B
|
||
> is an associated
|
||
program for controlling tape autoloaders
|
||
(see <A
|
||
HREF="http://mtx.sourceforge.net"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>mtx.sourceforge.net</TT
|
||
></A
|
||
>).
|
||
</P
|
||
><P
|
||
> The st driver detects those SCSI devices whose peripheral device type
|
||
is "Sequential-access" (code number 1) unless they appear on the
|
||
driver's "reject_list". [Currently the OnStream tape drives (described
|
||
in a following section) are the only entry in this reject_list.]
|
||
</P
|
||
><P
|
||
> The st driver is capable of recognizing 32 tape drives. There are
|
||
8 device file names for each tape drive: a rewind and non-rewind
|
||
variant for each of 4 modes (numbered 0 to 3). See the tape device
|
||
file name examples in <A
|
||
HREF="#dnames"
|
||
>Section 3.2</A
|
||
> on device names. Any number of
|
||
tape drives (up to the overall limit of 32) can be added after the st
|
||
driver is loaded.
|
||
</P
|
||
><P
|
||
> ATAPI tape drives can be controlled by this driver with help from the
|
||
ide-scsi pseudo adapter driver. The discussion in <A
|
||
HREF="#sratapi"
|
||
>Section 9.2.4</A
|
||
>
|
||
also applies for ATAPI tape drives (and ATAPI floppies).
|
||
</P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="stbparams"
|
||
></A
|
||
>9.3.1. st boot parameters</H2
|
||
><P
|
||
> <TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> st=xxx[,yyy] where xxx is one of the following:
|
||
buffer_kbs:<n>
|
||
write_threshold_kbs:<n>
|
||
max_buffers:<n>
|
||
max_sg_segs:<n>
|
||
|
||
(The old boot parameters st=aa[,bb[,cc[,dd]]] supported but deprecated)
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The default driver buffer size (buffer_kbs) is 32 (i.e. 32 KB).
|
||
The default asynchronous write threshold (write_threshold_kbs) is 30
|
||
(i.e. 30 KB).
|
||
The default number of buffers allocated at initialization (max_buffers)
|
||
is 4.
|
||
The default number of scatter/gather segments to use (max_sg_segs) is
|
||
32.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="stmparams"
|
||
></A
|
||
>9.3.2. st module parameters</H2
|
||
><P
|
||
> <TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> buffer_kbs=<n>
|
||
write_threshold_kbs=<n>
|
||
max_buffers=<n>
|
||
max_sg_segs=<n>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="stproc"
|
||
></A
|
||
>9.3.3. st proc interface</H2
|
||
><P
|
||
> None.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="stosst"
|
||
></A
|
||
>9.3.4. osst driver for OnStream devices</H2
|
||
><P
|
||
> There is an auxiliary tape driver for tape drives manufactured by
|
||
OnStream. It is an additional upper level driver and can co-exist with
|
||
the st driver. Its driver name is "osst" (as is its module name).
|
||
</P
|
||
><P
|
||
> The OnStream SC-x0 SCSI tape drives can not be driven by the
|
||
standard st driver, but instead need this special osst driver and
|
||
use the <TT
|
||
CLASS="filename"
|
||
>/dev/osst<x></TT
|
||
> char device nodes (major 206).
|
||
[Where <x> follows the same naming scheme as st devices outlined
|
||
in <A
|
||
HREF="#dnames"
|
||
>Section 3.2</A
|
||
>.]
|
||
Via usb-storage and ide-scsi, you may be able to drive the USB-x0
|
||
and DI-x0 drives as well. Note that there is also a second generation
|
||
of OnStream tape drives (ADR-x0) that supports the standard SCSI-2
|
||
commands for tapes (QIC-157) and can be driven by the standard
|
||
driver st. For more information, you may have a look at the kernel
|
||
source file <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/drivers/scsi/README.osst</TT
|
||
>.
|
||
More info on the OnStream driver may be found on
|
||
<A
|
||
HREF="http://linux1.onstream.nl/test/"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>linux1.onstream.nl/test/</TT
|
||
></A
|
||
>.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="sg"
|
||
></A
|
||
>9.4. Generic driver (sg)</H1
|
||
><P
|
||
> All types of SCSI devices are accessible via the sg driver. This means
|
||
devices such as CDROM drives can be accessed both via the sr and sg
|
||
drivers. Other SCSI devices such as scanners can only be accessed
|
||
via the sg driver.
|
||
The sg driver is capable of recognizing 256 SCSI devices. Any number of
|
||
devices (up to the overall limit of 256) can be added after the sg
|
||
driver is loaded.
|
||
</P
|
||
><P
|
||
> See reference <A
|
||
HREF="#W4"
|
||
>W4</A
|
||
> for the SCSI Generic (sg) driver
|
||
documentation (also found there is the sg_utils package).
|
||
For SCSI standards see reference <A
|
||
HREF="#W1"
|
||
>W1</A
|
||
> and for a
|
||
book on the subject of SCSI programming and pass through mechanisms see
|
||
reference <A
|
||
HREF="#B3"
|
||
>B3</A
|
||
>.
|
||
</P
|
||
><P
|
||
> The sg driver in lk 2.4 is "version 3" which adds an additional interface
|
||
structure and some new ioctl()s. The most interesting new ioctl()
|
||
is SG_IO which sends a SCSI command and waits for its response.
|
||
See the Linux Documentation Project site:
|
||
<A
|
||
HREF="http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.tldp.org/HOWTO/SCSI-Generic-HOWTO/</TT
|
||
></A
|
||
>
|
||
for a full description of the sg driver.
|
||
A (possibly later) version of this document can be found at
|
||
<A
|
||
HREF="http://www.torque.net/sg/p/sg_v3_ho.html"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.torque.net/sg/p/sg_v3_ho.html</TT
|
||
></A
|
||
>.
|
||
</P
|
||
><P
|
||
> The abbreviation "sg" is used within the kernel to refer both to the
|
||
SCSI generic driver and the scatter-gather capability offered by many
|
||
modern IO devices (usually associated with DMA). The context usually
|
||
makes it clear which one is being referred to. As an example, note the
|
||
contorted sg ioctl() named SG_GET_SG_TABLESIZE where the second "SG"
|
||
refers to scatter gather.
|
||
</P
|
||
><P
|
||
> The public interface for sg is found in the file: <TT
|
||
CLASS="filename"
|
||
> /usr/src/linux/include/scsi/sg.h</TT
|
||
>. Depending on the distribution
|
||
this may or may not contain the same information as <TT
|
||
CLASS="filename"
|
||
> /usr/include/scsi/sg.h</TT
|
||
> which is controlled by the GNU library
|
||
maintainers. If these 2 files are not the same use the former header
|
||
file. Those writing applications based on sg should see its documentation
|
||
for more on this matter.
|
||
</P
|
||
><P
|
||
> The sg driver registers all SCSI devices (with a current maximum of 256)
|
||
as they are seen. Each newly registered SCSI device gets allocated the
|
||
next available minor device number. At least initially this will be the
|
||
same sequence that devices are displayed in mid level's <B
|
||
CLASS="command"
|
||
> cat /proc/scsi/scsi</B
|
||
>. The sg devices device mapping can be
|
||
seen with <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/sg/devices</B
|
||
> or <B
|
||
CLASS="command"
|
||
> cat /proc/scsi/sg/device_strs</B
|
||
>. Differences between
|
||
<B
|
||
CLASS="command"
|
||
>cat /proc/scsi/scsi</B
|
||
> and sg orderings will appear when
|
||
a low level driver is removed (e.g. <B
|
||
CLASS="command"
|
||
>rmmod aha1542</B
|
||
>) or
|
||
when a device is removed with remove-single-device.
|
||
The sg driver will leave remaining SCSI device mapping to minor device
|
||
numbers unchanged. This potentially leaves a "hole" in the sg mapping.
|
||
An example follows:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> $ cat /proc/scsi/scsi
|
||
Attached devices:
|
||
Host: scsi0 Channel: 00 Id: 00 Lun: 00
|
||
Vendor: IBM Model: DNES-309170W Rev: SA30
|
||
Type: Direct-Access ANSI SCSI revision: 03
|
||
Host: scsi1 Channel: 00 Id: 02 Lun: 00
|
||
Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10
|
||
Type: CD-ROM ANSI SCSI revision: 02
|
||
Host: scsi1 Channel: 00 Id: 06 Lun: 00
|
||
Vendor: YAMAHA Model: CRW4416S Rev: 1.0g
|
||
Type: CD-ROM ANSI SCSI revision: 02
|
||
|
||
$ cat /proc/scsi/sg/device_strs
|
||
IBM DNES-309170W SA30
|
||
PIONEER DVD-ROM DVD-303 1.10
|
||
YAMAHA CRW4416S 1.0g
|
||
|
||
$ echo "scsi remove-single-device 1 0 2 0" > /proc/scsi/scsi
|
||
|
||
$ cat /proc/scsi/scsi
|
||
Attached devices:
|
||
Host: scsi0 Channel: 00 Id: 00 Lun: 00
|
||
Vendor: IBM Model: DNES-309170W Rev: SA30
|
||
Type: Direct-Access ANSI SCSI revision: 03
|
||
Host: scsi1 Channel: 00 Id: 06 Lun: 00
|
||
Vendor: YAMAHA Model: CRW4416S Rev: 1.0g
|
||
Type: CD-ROM ANSI SCSI revision: 02
|
||
|
||
$ cat /proc/scsi/sg/device_strs
|
||
IBM DNES-309170W SA30
|
||
<no active device>
|
||
YAMAHA CRW4416S 1.0g
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
Notice how the sg driver maintains the row positions of the remaining
|
||
devices in the "device_strs" output. So when the Pioneer
|
||
dvd player is removed, a hole opens up in the sg device mapping
|
||
which is not reflected in the <B
|
||
CLASS="command"
|
||
>cat /proc/scsi/scsi</B
|
||
>
|
||
output. That "hole" corresponds to the device name <TT
|
||
CLASS="filename"
|
||
> /dev/sg1</TT
|
||
>.
|
||
</P
|
||
><P
|
||
> The new sg_io_hdr interface includes a data transfer residual count
|
||
field called "resid". Only some lower level adapters support this
|
||
feature and those that don't always yield zero in this field. At
|
||
the time of writing the advansys, aha152x and the sym53c8xx
|
||
drivers support this feature.
|
||
</P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="sgbparams"
|
||
></A
|
||
>9.4.1. sg boot parameters</H2
|
||
><P
|
||
> The sg driver maintains a reserved buffer for each open file descriptor.
|
||
The purpose is to guarantee applications that data transfers up to the
|
||
size of the reserved buffer will not fail for lack of kernel memory. This
|
||
is important for applications like cdrecord that cannot easily recover
|
||
(the CDR) from a ENOMEM error.
|
||
</P
|
||
><P
|
||
> In the absence of the boot parameter 'sg_def_reserved_size' or the sg module
|
||
parameter 'def_reserved_size', then each time a sg file descriptor is opened
|
||
the reserved buffer size is inherited from SG_DEF_RESERVED_SIZE which is
|
||
defined in <TT
|
||
CLASS="filename"
|
||
>include/linux/sg.h</TT
|
||
>.
|
||
</P
|
||
><P
|
||
> The SG_DEF_RESERVED_SIZE define value can be overridden by this kernel boot
|
||
option:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> sg_def_reserved_size=<n>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="sgmparams"
|
||
></A
|
||
>9.4.2. sg module parameters</H2
|
||
><P
|
||
> When the sg module is loaded the SG_DEF_RESERVED_SIZE define value can be
|
||
overridden by supplying this option:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> def_reserved_size=<n>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="sgproc"
|
||
></A
|
||
>9.4.3. sg proc interface</H2
|
||
><P
|
||
> All the following files are readable by all and produce ASCII output
|
||
when read. The file
|
||
'def_reserved_size' is also writable by root. The ASCII output has been
|
||
formatted in such a way as to be human and machine readable (and hence
|
||
a compromise). Use Unix commands of the form <B
|
||
CLASS="command"
|
||
>cat device_hdrs devices
|
||
</B
|
||
> to see the output of tables.
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
/proc/scsi/sg/debug [internal state of sg driver]
|
||
/proc/scsi/sg/def_reserved_size
|
||
[like boot/module load parameter]
|
||
/proc/scsi/sg/devices [table of numeric device data]
|
||
/proc/scsi/sg/device_hdr [column headers for sg/devices]
|
||
/proc/scsi/sg/device_strs [table of strings from INQUIRY]
|
||
/proc/scsi/sg/hosts [table of numeric host data]
|
||
/proc/scsi/sg/host_hdr [column headers for sg/hosts]
|
||
/proc/scsi/sg/host_strs [table of string ids for hosts]
|
||
/proc/scsi/sg/version [sg version number and date]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
All the above files are owned by root and readable by all while
|
||
<TT
|
||
CLASS="filename"
|
||
>def_reserved_size</TT
|
||
> is writable by root. For the
|
||
<TT
|
||
CLASS="filename"
|
||
>devices</TT
|
||
> and <TT
|
||
CLASS="filename"
|
||
>device_strs</TT
|
||
> files
|
||
the first row output corresponds to <TT
|
||
CLASS="filename"
|
||
>/dev/sg0</TT
|
||
>
|
||
(sg minor device number 0). The second row output corresponds to
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/sg1</TT
|
||
>, etc.
|
||
For the <TT
|
||
CLASS="filename"
|
||
>hosts</TT
|
||
> and <TT
|
||
CLASS="filename"
|
||
>host_strs</TT
|
||
>
|
||
files the first row output corresponds to host (adapter number) 0, etc.
|
||
For numeric tables a missing device or host is indicated by a row
|
||
of "-1" values. For string tables a missing device or host is indicated
|
||
by a row containing "<no active device/host>".
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="llevel"
|
||
></A
|
||
>Chapter 10. Lower Level drivers</H1
|
||
><P
|
||
> There are too many SCSI low level drivers to detail in this document.
|
||
As an alternative to giving any superficial overview here, the reader is
|
||
given suggestions of places to look for further information.
|
||
</P
|
||
><P
|
||
> The source directory for the SCSI subsystem in the Linux kernel is a good place
|
||
to start: <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/drivers/scsi</TT
|
||
>. Several drivers
|
||
have information in a "readme" file: <TT
|
||
CLASS="filename"
|
||
>README.<driver_name>
|
||
</TT
|
||
>. Others have extensive information at the top of their ".c" file
|
||
This information often includes a version number, change logs and kernel
|
||
boot time and module load
|
||
time options. Often the latter information can be found in the installation
|
||
guides of the various Linux distributions. Sometimes the driver maintainer will
|
||
have a web site containing the most recent bug fix information. Official
|
||
maintainers are listed in the <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/MAINTAINERS</TT
|
||
>
|
||
file. If there is nothing there, look in the relevant ".c" file in the SCSI
|
||
subsystem directory. Some old drivers have no active maintainers. In such cases
|
||
posting to the linux-scsi newsgroup may help [see <A
|
||
HREF="#N1"
|
||
>N1
|
||
</A
|
||
>].
|
||
</P
|
||
><P
|
||
> For an overview of the drivers supplied with the kernel source tree,
|
||
use one of the kernel configuration programs (e.g.
|
||
<B
|
||
CLASS="command"
|
||
>cd /usr/src/linux; make menuconfig</B
|
||
>). The help
|
||
information associated with each selection can be found together in one
|
||
(large) flat file at
|
||
<TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/Documentation/Configure.help</TT
|
||
>.
|
||
Drivers can be obtained from other places. It is unlikely that a SCSI
|
||
driver made for the lk 2.2 series (or before) will build or operate
|
||
successfully in the lk 2.4 series. [From a programmatic viewpoint
|
||
there are not a lot of things that need changing.] Drivers may even
|
||
be only available in binary form, in which case make sure that you
|
||
trust the provider and follow their instructions closely.
|
||
</P
|
||
><P
|
||
> Lower level drivers can support either of 2 error handling strategies.
|
||
The older one is considered obsolete while the newer one is often called
|
||
"new_eh". The advantage of "new_eh" is that it uses a separate kernel
|
||
thread per host (named "scsi_eh_<n>" where <n> is the host number) to
|
||
facilitate error recovery. Both error handling strategies were also
|
||
available in the lk 2.2 series in which very few adapter drivers used
|
||
"new_eh". In the lk 2.4 series, more
|
||
drivers are using it and the plan for the forthcoming lk 2.5 development
|
||
series is to drop mid level support for the older, obsolete error strategy.
|
||
</P
|
||
><P
|
||
> Drew Eckhardt's SCSI-HOWTO document [see reference <A
|
||
HREF="#W7"
|
||
>W7
|
||
</A
|
||
>] goes into much more detail about lower level (adapter) drivers
|
||
than this document. Since that SCSI-HOWTO is 5 years old, many things
|
||
have changed and more drivers have been added.
|
||
</P
|
||
><P
|
||
> There is a lower level driver called <EM
|
||
>scsi_debug</EM
|
||
>
|
||
that simulates one or more "direct access" devices (i.e. disk(s)) using
|
||
the computer's memory. From lk 2.4.17 it acts as a "ram disk". While there
|
||
are many ram disk implementations available in Linux (e.g. ramfs),
|
||
scsi_debug may help to isolate a defective scsi driver in a problematic
|
||
installation. See <TT
|
||
CLASS="filename"
|
||
>scsi_debug.c</TT
|
||
> for further information.
|
||
</P
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="llevelpseudo"
|
||
></A
|
||
>10.1. Pseudo drivers</H1
|
||
><P
|
||
> SCSI can be viewed as a command set and a set of hardware buses that convey
|
||
that command set. Those hardware buses can be further divided into those
|
||
used exclusively for SCSI (e.g. ultra wide), those shared with other
|
||
protocols (e.g. USB, IEEE 1394) and those buses not defined by the various
|
||
SCSI standards. In the final category there are several interesting examples
|
||
including ATAPI CD writers and PC parallel bus ZIP drives. Such devices
|
||
use the SCSI command set (or something very close to it) over a foreign bus.
|
||
</P
|
||
><P
|
||
> This section briefly outlines various pseudo lower level drivers which essentially
|
||
communicate with other Linux subsystems in order to send the SCSI command set
|
||
to devices controlled by those other subsystems. This raises some ownership
|
||
issues that often confuse users and result in many questions to the
|
||
maintainers.
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>IDE-SCSI. </B
|
||
>
|
||
<A
|
||
NAME="idescsi"
|
||
></A
|
||
>
|
||
From configuration point of view, ide-scsi will grab and try to control
|
||
every ATA (a.k.a. IDE) device which doesn't have a "native"
|
||
driver attached (such as ide-cd, ide-tape, etc). So for example, if
|
||
both ide-cd and ide-scsi are compiled into the kernel in a system
|
||
which has an ATAPI cdrom, ide-cd will get to control it. If only
|
||
ide-scsi is compiled in, it will get the device. There are some
|
||
kernel boot time parameters to control which driver gets which device.
|
||
</P
|
||
></DIV
|
||
><P
|
||
> The preferences of the IDE subsystem can be overridden with one of these
|
||
kernel boot time parameters (of which the first is most interesting for
|
||
this subsystem):
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> hdx=ide-scsi
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> hdx=ide-cdrom
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> hdx=ide-floppy
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
[The term <EM
|
||
>hdx</EM
|
||
> is used
|
||
to refer to one of the IDE/ATA devices in {hda, hdb, hdc ...}.]
|
||
In the 2.4 series "hdx=scsi" was added but it is not very useful, see
|
||
see <A
|
||
HREF="#sratapi"
|
||
>Section 9.2.4</A
|
||
>.
|
||
</P
|
||
><P
|
||
> When the driver is running, the device will be accessible using
|
||
the SCSI device (<TT
|
||
CLASS="filename"
|
||
>/dev/sda</TT
|
||
>, <TT
|
||
CLASS="filename"
|
||
>/dev/sr0
|
||
</TT
|
||
>, etc), and not through the corresponding <TT
|
||
CLASS="filename"
|
||
> /dev/hdx</TT
|
||
> device. Still, the <TT
|
||
CLASS="filename"
|
||
>/dev/hdx
|
||
</TT
|
||
> device will be available, but only for configuration.
|
||
</P
|
||
><P
|
||
> All the generic IDE configuration parameters (DMA on/off, 32-bit
|
||
I/O, unmasking irq's, etc) are available by using the <TT
|
||
CLASS="filename"
|
||
> /dev/hdx</TT
|
||
> device, for example to enable DMA:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> hdparm -d1 /dev/hdx
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
<A
|
||
NAME="AEN659"
|
||
HREF="#FTN.AEN659"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[13]</SPAN
|
||
></A
|
||
>
|
||
Using <B
|
||
CLASS="command"
|
||
>cat /proc/ide/hdx/settings</B
|
||
> will show the
|
||
available settings.
|
||
All the generic IDE driver settings will be available there, as well
|
||
as the following "ide-scsi specific" settings:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>bios_cyl</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>bios_head</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>bios_sect</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>transform</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>log</P
|
||
></LI
|
||
></UL
|
||
>
|
||
The first three choose the virtual geometry that the drive will
|
||
return to the sd driver, in case it's a disk drive (ZIP, etc).
|
||
"transform" will configure/enable/disable the SCSI to ATAPI CDB
|
||
transformation layer:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>bit 0: Enable(1)/Disable(0) transformation for
|
||
commands not originated from the sg driver.</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>bit 1: Enable/Disable transformation for commands
|
||
issued using the sg driver.</P
|
||
></LI
|
||
></UL
|
||
>
|
||
"log" will log debugging information. This is useful also to debug
|
||
user-space programs using the sg driver, as it will list the CDB
|
||
traffic on the bus -- each issued command, along with its completion
|
||
status.
|
||
To enable/disable a specific settings, use something like:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> echo "log:1" > /proc/ide/hdx/settings
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
To turn off the "using_dma" flag use:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> echo "using_dma:0" > /proc/ide/hdx/settings
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>PPA + IMM. </B
|
||
>
|
||
Iomega ZIP drives come in a variety of flavours including parallel
|
||
port, SCSI, and ATAPI. The parallel port versions (both old and new)
|
||
are driven by ppa and imm respectively.
|
||
</P
|
||
></DIV
|
||
><P
|
||
> The parallel port ZIP drives are actually SCSI devices which tunnel
|
||
SCSI commands over the parallel port using interfaces called VPI0
|
||
(older-style) and VPI2 (newer-style). The ppa driver is the VPI0 host
|
||
implementation and the imm driver is the VPI2 host implementation.
|
||
</P
|
||
><P
|
||
> The way it works is that the HBA is a chip inside the ZIP drive, so
|
||
that the host adapter and the peripheral are in the same actual case.
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>PPSCSI. </B
|
||
>
|
||
The new, not-yet-integrated, architecture for devices that use SCSI
|
||
over a parallel port cable is ppscsi. The ppscsi module provides the
|
||
boiler plate code and makes it easy to write implementations for
|
||
different interfaces.
|
||
</P
|
||
></DIV
|
||
><P
|
||
> Each ppscsi protocol module registers itself with the ppscsi module,
|
||
passing in a list of entry points for the various things that are
|
||
common to all protocol drivers.
|
||
</P
|
||
><DIV
|
||
CLASS="mediaobject"
|
||
><P
|
||
><IMG
|
||
SRC="ppscsi.jpg"><DIV
|
||
CLASS="caption"
|
||
><P
|
||
> The structure of the PPSCSI drivers.
|
||
</P
|
||
></DIV
|
||
></P
|
||
></DIV
|
||
><P
|
||
> The plan is that the ppscsi architecture will absorb both the ppa and
|
||
imm drivers and protocol modules; only vpi0 has been written so far.
|
||
See <A
|
||
HREF="http://www.torque.net/parport/ppscsi.html"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.torque.net/parport/ppscsi.html</TT
|
||
></A
|
||
>.
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>USB. </B
|
||
>
|
||
USB classifies a group of devices as "mass storage" (e.g. disks) and
|
||
interacts with these using the SCSI command set. The module name is
|
||
"usb-storage".
|
||
See <A
|
||
HREF="http://www.one-eyed-alien.net/~mdharm/linux-usb"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.one-eyed-alien.net/~mdharm/linux-usb</TT
|
||
></A
|
||
>.
|
||
</P
|
||
></DIV
|
||
><P
|
||
> There is also the usb/microtek driver for controlling X6 USB scanners
|
||
from Microtek. When configured, the SANE application uses the sg
|
||
driver to send SCSI commands over USB to control this scanner.
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>I2O. </B
|
||
>
|
||
See kernel source file <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/drivers/i2o/io2_scsi.c
|
||
</TT
|
||
>.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>IEEE 1394. </B
|
||
>
|
||
Support for IEEE 1394 devices that use the SBP-2 protocol is now
|
||
available (lk 2.4.7). See the IEEE 1394 paragraph in this
|
||
<A
|
||
HREF="#ieee1394"
|
||
>section</A
|
||
> for more information.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>iSCSI. </B
|
||
>
|
||
An IETF draft is taking shape for iSCSI. This sends the SCSI command
|
||
set over a TCP network connection. iSCSI seems to be gaining popularity
|
||
quickly and there are several implementations for Linux taking shape.
|
||
One implementation is at
|
||
<A
|
||
HREF="http://sourceforge.net/projects/intel-iscsi/"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>sourceforge.net/projects/intel-iscsi/</TT
|
||
></A
|
||
>.
|
||
Use your favourite search engine to find other projects.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="rawdev"
|
||
></A
|
||
>Chapter 11. Raw devices</H1
|
||
><P
|
||
> A raw device can be bound to an existing block device (e.g. a disk) and be
|
||
used to perform "raw" IO with that existing block device. Such "raw" IO
|
||
bypasses the caching that is normally associated with block devices.
|
||
Hence a raw device offers a more "direct" route to the physical device
|
||
and allows an application more control over the timing of IO to that
|
||
physical device. This makes raw devices suitable for complex applications
|
||
like Database Management Systems that typically do their own caching.
|
||
</P
|
||
><P
|
||
> Raw devices are character devices (major number 162). The first
|
||
minor number (i.e. 0) is reserved as a control interface and is usually
|
||
found at <TT
|
||
CLASS="filename"
|
||
>/dev/rawctl</TT
|
||
>. A utility called <B
|
||
CLASS="command"
|
||
>raw
|
||
</B
|
||
> (see <B
|
||
CLASS="command"
|
||
>man raw</B
|
||
>) can be used to bind a raw
|
||
device to an existing block device. These "existing block devices" may be
|
||
disks or cdroms/dvds whose underlying interface can be anything supported
|
||
by Linux (e.g. IDE/ATA or SCSI).
|
||
</P
|
||
><P
|
||
> A sequence of commands listing the raw devices and then binding
|
||
a SCSI disk partition followed by binding the whole disk looks
|
||
like this on my system:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> $ ls -lR /dev/raw*
|
||
crw-r--r-- 1 root root 162, 0 Dec 6 06:54 /dev/rawctl
|
||
|
||
/dev/raw:
|
||
total 0
|
||
crw-r--r-- 1 root root 162, 1 Dec 6 06:54 raw1
|
||
crw-r--r-- 1 root root 162, 2 Dec 6 06:54 raw2
|
||
crw-r--r-- 1 root root 162, 3 Dec 6 06:54 raw3
|
||
crw-r--r-- 1 root root 162, 4 Dec 6 06:54 raw4
|
||
$
|
||
$ raw -qa
|
||
$
|
||
$ raw /dev/raw/raw1 /dev/sda3
|
||
/dev/raw/raw1: bound to major 8, minor 3
|
||
$ raw /dev/raw/raw2 /dev/sda
|
||
/dev/raw/raw2: bound to major 8, minor 0
|
||
$ raw -qa
|
||
/dev/raw/raw1: bound to major 8, minor 3
|
||
/dev/raw/raw2: bound to major 8, minor 0
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The normal array of system calls for character devices are available on
|
||
raw devices. The size of the transfer for read(2) and write(2) must be
|
||
an integral multiple of the physical device's block size. For a disk
|
||
this will be its sector size which is normally 512 bytes. The data buffer
|
||
given to read() and write() system calls must be aligned to the block
|
||
size. The lseek(2) call needs to align its file read/write offset to a block
|
||
boundary as well. The pread(3) call (see <B
|
||
CLASS="command"
|
||
>man pread</B
|
||
>)
|
||
combines a read() and an lseek() and can be useful with raw devices (ditto with
|
||
pwrite() ). Care should be taken with offsets greater than 2 GB (or perhaps
|
||
4 GB) on 32 bit architectures where the "off_t" type is 32 bits long.
|
||
One solution is to use the _llseek() call (see <B
|
||
CLASS="command"
|
||
>man llseek</B
|
||
>).
|
||
</P
|
||
><P
|
||
> Unix utilities such as recent versions of <B
|
||
CLASS="command"
|
||
>dd</B
|
||
> and
|
||
<B
|
||
CLASS="command"
|
||
>lmdd</B
|
||
> (from the lmbench suite of programs) can be used
|
||
to move data to and from "raw" devices as they meet the above-mentioned
|
||
block alignment requirements. Recent versions of the <B
|
||
CLASS="command"
|
||
>sg_dd</B
|
||
>
|
||
command in the sg_utils package can access both raw and sg devices.
|
||
</P
|
||
><P
|
||
> Also note that if the physical device has an odd number of sectors (as
|
||
shown by <B
|
||
CLASS="command"
|
||
>blockdev --getsize /dev/raw/raw*</B
|
||
>), the last
|
||
sector will not be accessible using raw IO.
|
||
</P
|
||
><DIV
|
||
CLASS="warning"
|
||
><P
|
||
></P
|
||
><TABLE
|
||
CLASS="warning"
|
||
WIDTH="100%"
|
||
BORDER="0"
|
||
><TR
|
||
><TD
|
||
WIDTH="25"
|
||
ALIGN="CENTER"
|
||
VALIGN="TOP"
|
||
><IMG
|
||
SRC="../images/warning.gif"
|
||
HSPACE="5"
|
||
ALT="Warning"></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
><P
|
||
> If a block device is being accessed via a bound raw device and also via
|
||
its normal block interface then there is no cache coherency between the
|
||
two access mechanisms. For example if <TT
|
||
CLASS="filename"
|
||
>/dev/sda1</TT
|
||
> was
|
||
both mounted and being accessed via a bound raw device then there could be
|
||
data inconsistencies.
|
||
</P
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="chapter"
|
||
><HR><H1
|
||
><A
|
||
NAME="devfs"
|
||
></A
|
||
>Chapter 12. Devfs pseudo file system</H1
|
||
><P
|
||
> The main documentation for devfs can be found at: reference
|
||
<A
|
||
HREF="#W5"
|
||
>W5</A
|
||
>. The devfs name conventions for the
|
||
SCSI subsystem are outlined in <A
|
||
HREF="#dnamesdevfs"
|
||
>Section 3.3</A
|
||
>.
|
||
Devfs is selected by the kernel build option CONFIG_DEVFS_FS and whether
|
||
it is mounted at boot time (as <TT
|
||
CLASS="filename"
|
||
>/dev</TT
|
||
>) or not is
|
||
controlled by the kernel build option CONFIG_DEVFS_MOUNT. The latter option
|
||
can be overridden by the kernel boot time options "devfs=mount" or
|
||
"devfs=nomount", whichever is appropriate.
|
||
</P
|
||
><P
|
||
> The devfs SCSI node names with their default permissions are:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> disc rw------- whole disk including mbr
|
||
part1 rw------- first partition {...p1}
|
||
...
|
||
part15 rw------- 15th partition {...p15}
|
||
cd rw-rw-rw- cd or dvd devices
|
||
mt rw-rw-rw- tape mode 0 with rewind {...m0}
|
||
mtl rw-rw-rw- tape mode 1 with rewind {...m1}
|
||
mtm rw-rw-rw- tape mode 2 with rewind {...m2}
|
||
mta rw-rw-rw- tape mode 3 with rewind {...m3}
|
||
mtn rw-rw-rw- tape mode 0 with no rewind {...m0n}
|
||
mtln rw-rw-rw- tape mode 1 with no rewind {...m1n}
|
||
mtmn rw-rw-rw- tape mode 2 with no rewind {...m2n}
|
||
mtan rw-rw-rw- tape mode 3 with no rewind {...m3n}
|
||
generic rw-r-----
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> These node names are only present if the corresponding device (or sub-entities
|
||
of the device (e.g. partitions)) and driver are present. For example if
|
||
there is no sg driver present then there is no "generic" device name. The
|
||
strings that appear above in braces are appended to the abridged "c0b0t0u0"
|
||
notations outlined below as appropriate.
|
||
</P
|
||
><P
|
||
> The devfs file names that are block or character special files will be
|
||
called the primary device names in this description. The devfs daemon, called
|
||
devfsd, introduces many symbolic links to those primary device names. This is
|
||
done both for backward compatibility and convenience. These symbolic links
|
||
will be called secondary device names.
|
||
</P
|
||
><P
|
||
> The secondary device names are controlled by the devfsd configuration file
|
||
usually found in <TT
|
||
CLASS="filename"
|
||
>/etc/devfsd.conf</TT
|
||
> . Following is a
|
||
list of secondary device names when the default devfsd.conf file is used:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
Secondary name slink to this primary device name
|
||
--------------------------------------------------------------
|
||
/dev/sda /dev/scsi/host0/bus0/target2/lun0/disc
|
||
/dev/sda1 /dev/scsi/host0/bus0/target2/lun0/part1
|
||
/dev/sd/c0b0t2u0 /dev/scsi/host0/bus0/target2/lun0/disc
|
||
/dev/sd/c0b0t2u0p1 /dev/scsi/host0/bus0/target2/lun0/part1
|
||
/dev/sr0 /dev/scsi/host0/bus0/target4/lun0/cd
|
||
/dev/sr/c0b0t4u0 /dev/scsi/host0/bus0/target4/lun0/cd
|
||
/dev/st0 /dev/scsi/host1/bus0/target0/lun0/mt
|
||
/dev/nst0a /dev/scsi/host1/bus0/target0/lun0/mtan
|
||
/dev/st/c1b0t0u0m0 /dev/scsi/host1/bus0/target0/lun0/mt
|
||
/dev/st/c1b0t0u0m3n /dev/scsi/host1/bus0/target0/lun0/mtan
|
||
/dev/sg0 /dev/scsi/host0/bus0/target2/lun0/generic
|
||
/dev/sg1 /dev/scsi/host0/bus0/target4/lun0/generic
|
||
/dev/sg2 /dev/scsi/host1/bus0/target0/lun0/generic
|
||
/dev/sg/c0b0t2u0 /dev/scsi/host0/bus0/target2/lun0/generic
|
||
/dev/sg/c0b0t4u0 /dev/scsi/host0/bus0/target4/lun0/generic
|
||
/dev/sg/c1b0t0u0 /dev/scsi/host1/bus0/target0/lun0/generic
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Note that the more common <TT
|
||
CLASS="filename"
|
||
>/dev/scd0</TT
|
||
> variant for SCSI
|
||
cdroms is not supported. There are also <TT
|
||
CLASS="filename"
|
||
>/dev/discs</TT
|
||
>,
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/cdroms</TT
|
||
> and <TT
|
||
CLASS="filename"
|
||
>/dev/tapes</TT
|
||
>
|
||
directories that contain symbolic links to all devices (i.e. not just
|
||
SCSI devices) that fall into that categorization:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
Secondary name slink to this primary device
|
||
------------------------------------------------------------
|
||
/dev/discs/disc0 /dev/ide/host0/bus0/target0/lun0 *
|
||
/dev/discs/disc1 /dev/scsi/host0/bus0/target2/lun0 *
|
||
/dev/cdroms/cdrom0 /dev/ide/host0/bus1/target1/lun0/cd
|
||
/dev/cdroms/cdrom1 /dev/scsi/host0/bus0/target4/lun0/cd
|
||
/dev/tapes/tape0 /dev/scsi/host1/bus0/target0/lun0 *
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Those entries marked with "*" are directories containing the primary devices.
|
||
Note that IDE/ATA devices are listed before SCSI devices. These secondary device
|
||
names mimic the same persistence rules as the primary device names. So when
|
||
a SCSI device (?), or its lower level driver or its upper level driver are
|
||
removed then so are the primary and secondary device names associated with it.
|
||
</P
|
||
><P
|
||
> When devfs is mounted as <TT
|
||
CLASS="filename"
|
||
>/dev</TT
|
||
>, the old
|
||
"<TT
|
||
CLASS="filename"
|
||
>/dev/sda6</TT
|
||
>" type can still be used
|
||
in some contexts. This may be convenient if typing is required at the
|
||
kernel boot time prompt. For example if a user wants to change the root
|
||
partition on a "devfs" machine then any of the following examples
|
||
may be used as a kernel boot time option:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> root=/dev/sda6
|
||
root=/dev/scsi/host0/bus0/target0/lun0/part6
|
||
root=/dev/sd/c0b0t0u0p6
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> There are many device scanning programs that expect to see the pre-devfs
|
||
device names present and it will some time before they become devfs aware.
|
||
Also some programs rely on a open of <TT
|
||
CLASS="filename"
|
||
>/dev/sg0</TT
|
||
>
|
||
(for example) to load the
|
||
sg driver (assuming it is a module and not already loaded). This can
|
||
be arranged by an entry in <TT
|
||
CLASS="filename"
|
||
>/etc/devfsd.conf</TT
|
||
> file of:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> LOOKUP sg.* MODLOAD
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
and the following in <TT
|
||
CLASS="filename"
|
||
>/etc/modules.devfs</TT
|
||
> :
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> probeall /dev/sg scsi-hosts sg
|
||
alias /dev/sg* /dev/sg
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The sg device permissions can be changed with this entry in the
|
||
<TT
|
||
CLASS="filename"
|
||
>/etc/devfsd.conf</TT
|
||
> file:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> REGISTER scsi/host.*/bus.*/target.*/lun.*/generic
|
||
PERMISSIONS 0.0 rw-rw-rw-
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
See "man devfsd" for more information.
|
||
</P
|
||
><P
|
||
> An application can determine whether devfs is active by the presence or
|
||
otherwise of the file <TT
|
||
CLASS="filename"
|
||
>/dev/.devfsd</TT
|
||
>.
|
||
</P
|
||
><P
|
||
> A feature of a /dev directory based on a persistent file system (e.g.
|
||
ext2) is the ability to associate permissions with a device file name
|
||
and keep them from one boot to the next. As noted above the default
|
||
action of devfs is to assign device file name permissions anew each time
|
||
a machine is booted. The PERMISSIONS action in the <TT
|
||
CLASS="filename"
|
||
> /etc/devfsd.conf</TT
|
||
> can be used to assert permissions but
|
||
this may be considered a little awkward. The devfs document
|
||
(<A
|
||
HREF="#W5"
|
||
>W5</A
|
||
>) describes a method for getting the best
|
||
of both worlds. This technique relies on the recently added feature
|
||
in lk 2.4 to mount the same file system at multiple points.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="appendix"
|
||
><HR><H1
|
||
><A
|
||
NAME="scsibus"
|
||
></A
|
||
>Appendix A. Common bus types (SCSI and other)</H1
|
||
><P
|
||
> A very good overview of the various bus types touched on in this
|
||
appendix (both SCSI and others) can be found at
|
||
<A
|
||
HREF="http://www.pctechguide.com/04disk2.htm"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.pctechguide.com/04disk2.htm</TT
|
||
></A
|
||
>.
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>SCSI. </B
|
||
>
|
||
The original SCSI 1 standard (ANSI specification X3.131-1986) introduced
|
||
an 8 bit parallel bus that was able to do asynchronous transfers at 1.5
|
||
MegaBytes/sec and synchronous transfers up to 5 MB/sec. SCSI commands are
|
||
sent at the asynchronous rate. SCSI data is transferred either at the
|
||
asynchronous rate (worst case) or a negotiated synchronous rate (with
|
||
5 MB/sec being the best case).
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>FAST SCSI. </B
|
||
>
|
||
The SCSI 2 standard raised the maximum synchronous speed to 10 MB/sec. SCSI 2
|
||
defined several parallel buses: single ended (as used by SCSI 1) and a new
|
||
differential bus. The differential bus has better noise immunity and its
|
||
maximum bus length is 25 metres (compared with single ended's 6 metres).
|
||
Tagged queuing of commands was also added by SCSI 2.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>WIDE SCSI. </B
|
||
>
|
||
The SCSI 2 standard also increased the width of the bus allowing 16 and 32 bit
|
||
"wide" variants. Very little use has been made of the 32 bit width so "wide"
|
||
usually refers to a 16 bit wide data path. The maximum number of SCSI devices
|
||
that can connect to a parallel SCSI bus is directly related to the bus width
|
||
hence "wide" buses allow a maximum of 16 SCSI devices to be connected.
|
||
[At least one of those devices must be the SCSI "initiator" which is
|
||
usually a host adapter.]
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>ULTRA SCSI. </B
|
||
>
|
||
Traditionally synchronous buses are clocked either on the rising or falling
|
||
edge of the clock (which is normally a square wave). A recent trend has been
|
||
to clock on both edges and thus double the available bandwidth. This is
|
||
how ULTRA SCSI doubles the SCSI 2 "fast" speed to 20 MB/sec.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>ULTRA WIDE SCSI. </B
|
||
>
|
||
The same "ultra" technique applied to a (16 bit) wide SCSI parallel bus yields
|
||
a bandwidth of 40 MB/sec.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>ULTRA 2 WIDE SCSI. </B
|
||
>
|
||
This variant introduces a new "low voltage" differential signalling (LVD) that
|
||
allows the synchronous clock speed to be doubled yielding 80 MB/sec when using
|
||
a (16 bit) wide bus. In this case the maximum SCSI bus length is 12 metres. To
|
||
be backward compatible with ULTRA WIDE this variant can fall back to "single
|
||
ended" operation. This leads to the abbreviation LVD/SE being used by adapter
|
||
manufacturers. One shortcoming of this approach is that the presence of one
|
||
UW device on a U2W bus will cause all other U2W devices to communicate at
|
||
the slower (i.e. UW) rate. Some adapters overcome this by having separate
|
||
LVD and SE physical buses on the same logical SCSI bus.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>ULTRA 160 SCSI. </B
|
||
>
|
||
ULTRA 160 doubles parallel SCSI bus bandwidth yet again. It uses a 16 bit
|
||
wide data path, LVD signalling (see previous entry) and double transition
|
||
clocking that increases the maximum synchronous bandwidth to 160 MB/sec.
|
||
Additional features include cyclic redundancy codes (CRC) to improve data
|
||
integrity (compared with a parity bit) and domain validation which adjusts
|
||
transfer rates if the error rate is too high.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>ULTRA 320 SCSI. </B
|
||
>
|
||
Shortly ULTRA 320 adapters will be available (disks with that interface
|
||
are already on the market). This is also a 16 bit wide LVD bus that can
|
||
fall back to slower speeds for compatibility with older devices. It extends
|
||
the features of Ultra 160 by doubling the clock speed. Packetized SCSI
|
||
which sends commands and status at full bus speed (rather than 5 MB/sec)
|
||
is included. Other improvements include "quick arbitration and selection",
|
||
"read and write data streaming" and CRC protection for command blocks as well
|
||
as data (Ultra 160 had CRC protection for data only). Note that adapter
|
||
cards using 64 bit PCI (or better: PCI-X) are required to stop the PCI bus
|
||
being a bottleneck at these speeds. More information can be found at
|
||
<A
|
||
HREF="http://www.scsita.org"
|
||
TARGET="_top"
|
||
><TT
|
||
CLASS="literal"
|
||
>www.scsita.org</TT
|
||
></A
|
||
>.
|
||
Recently an Ultra 320 HBA vendor claimed up to 105,000 IO operations
|
||
per second which implies per command SCSI bus overhead is less than 10
|
||
microseconds. There is a draft ULTRA 640 standard but that may be overtaken
|
||
by Serial Attached SCSI.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>Serial Attached SCSI (SAS). </B
|
||
>
|
||
Serial Attached SCSI (SAS) uses the same transport technology as Serial
|
||
ATA (sATA) and extends it. [sATA is described below.] SAS can use external
|
||
expanders to control up to 16000 devices from a single HBA. The data
|
||
transfer is full duplex and 1.5 Gbps or 3.0 Gbps "phys"s can be aggregated
|
||
to increase bandwidth. Cable lengths can be up to 6 meters. SAS disks are
|
||
dual ported. sATA disks can be connected to a SAS expanders (but SAS disks
|
||
can't be connected to a sATA HBA). SAS was demonstrated at CeBit recently
|
||
but won't reach the market until 2004.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>FC-AL. </B
|
||
>
|
||
This stands for Fibre Channel - Arbitrated Loop and may involve dual
|
||
2 Gigabit per second single mode fibre optic links spanning 10
|
||
kilometres with throughput of up to 400 MegaBytes per second.
|
||
Often associated with storage area networks (SANs). Up to 126
|
||
devices can be attached to a loop which in turn can be extended
|
||
to 16 million devices in public loop mode. The transmission medium
|
||
isn't necessarily fibre optic cable: copper (in the form of co-axial
|
||
cable) can also be used at lower speeds and for shorter distances.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>SRP/InfiniBand. </B
|
||
>
|
||
SRP (SCSI RDMA Protocol)
|
||
[<A
|
||
HREF="http://www.t10.org/drafts.htm#SCSI3_SRP"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>SRP_draft</TT
|
||
></A
|
||
>] is a SCSI transport for InfiniBand
|
||
[<A
|
||
HREF="http://www.infinibandta.org"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>Infiniband_trade_association</TT
|
||
></A
|
||
>], a high-performance
|
||
interconnect running at 10 and 30 Gbps. SRP driver source is available at
|
||
<A
|
||
HREF="http://infiniband.sourceforge.net/Storage/SRP/index.htm"
|
||
TARGET="_top"
|
||
>
|
||
<TT
|
||
CLASS="literal"
|
||
>infiniband.sourceforge.net/Storage/SRP</TT
|
||
></A
|
||
> .
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>IEEE 1394. </B
|
||
>
|
||
<A
|
||
NAME="ieee1394"
|
||
></A
|
||
>
|
||
This standard also goes by the name of "Fire Wire" [trademarked
|
||
by Apple] and "iLink" [trademarked by Sony]. It is a serial bus that can run
|
||
at up to 400 Megabits/sec (IEEE 1394a). A newer standard, IEEE 1394b, ups
|
||
this to 800 Megabits/sec (with extensions to 1.6 and 3.2 Gigabits/sec) with
|
||
cable runs up to 100 metres. It has a similar but more general architecture
|
||
than USB. The IEEE 1394 standard allows for the SCSI command set to be
|
||
carried over a 1394 bus. There is a "sbp2" driver now available for
|
||
the Linux IEEE 1394 stack. This sbp2 driver is also a SCSI subsystem
|
||
lower level driver (so it is functionally similar to the ide-scsi driver).
|
||
So IEEE 1394 devices that use the SBP-2 protocol (e.g. disks, cd-rw/dvd
|
||
drives, MO drives and scanners) can be accessed via the SCSI subsystem.
|
||
See <A
|
||
HREF="http://Linux1394.sourceforge.net"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>Linux1394.sourceforge.net</TT
|
||
></A
|
||
> for more information.
|
||
The sbp2 driver is now in lk 2.4.7 .
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>iSCSI. </B
|
||
>
|
||
This is a new IETF standard for sending the SCSI command set over a
|
||
TCP connection (or several of them). This permits SCSI devices (targets
|
||
such as disks) to be network appliances, accessed locally (or potentially
|
||
at a great distance) by a host machine.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>NON SCSI buses. </B
|
||
>
|
||
The following buses are not defined by the SCSI standards but are of interest
|
||
because they either can carry the SCSI command set, are in some way
|
||
related to the Linux SCSI subsystem or supply a similar functionality to
|
||
SCSI products.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>IDE/ATA (ATAPI). </B
|
||
>
|
||
IDE is the most used disk type on PC systems today. The acronym stands for
|
||
Integrated Drive Electronics and as the name suggests it places the bulk
|
||
of the IO "intelligence" on the disk controller card rather than spreading
|
||
it between the device (most often a disk) and a controller (HBA) as SCSI
|
||
does. IDE grew out of the ST506 and ESDI standards in the 1980s. EIDE
|
||
(extended IDE) is a related acronym. The modern standards that refer to
|
||
this bus architecture are known as ATA and can be found at
|
||
<A
|
||
HREF="http://www.t13.org"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.t13.org</TT
|
||
></A
|
||
>. The ATA Packet Interface (ATAPI)
|
||
extends the disk oriented command set to support CDROM and tape drives.
|
||
The ATAPI command set closely resembles the SCSI command set. The
|
||
most recent ATA technology is outlined in the next paragraph.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>ATA 133. </B
|
||
>
|
||
The ATA standards used by IDE devices have also been marching through
|
||
the adjectives (e.g. fast and ultra) and the numbers (e.g. 2, 33,
|
||
66, 100 and 133). The most recent addition is ATA 133 which supports
|
||
burst rates of 133 MB/sec and up to 2 devices per bus. [PCs typically
|
||
have 2 and often 4 ATA buses.] ATA 66, 100 and 133 need a special cable.
|
||
ATA cables are relatively short precluding IDE devices being external to
|
||
the computer. Cable lengths have previously been limited to 18 inches
|
||
although 1 metre long cables have now appeared. Coincidently 133 MB/sec
|
||
in also the maximum throughput of the normal PCI bus found in most
|
||
PCs. The are higher speed (and wider) versions of PCI but they are
|
||
relatively rare.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>Serial ATA (sATA). </B
|
||
>
|
||
Serial ATA uses 2 differential pairs to exchange data with a sATA
|
||
disk less than 1 metre away at 1.5 Gigabits per second. One pair takes data
|
||
to the disk and the other returns data from the disk. Data rates up to
|
||
150 Megabytes per second are possible (data transfer is half duplex).
|
||
sATA is a point to point connection, not a bus, so ATA's master and slave
|
||
strapping disappears. sATA cabling is less bulky and the form factor of
|
||
its plugs and sockets are smaller than parallel ATA (and the SCSI Parallel
|
||
interface). sATA devices are beginning to appear on the market. sATA-2
|
||
is a draft standard that doubles the serial data rate to 3 Gigabits per
|
||
second.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>USB. </B
|
||
>
|
||
Universal Serial Bus (USB) has a bandwidth of between 1.5 and 12
|
||
Megabits/sec (the latter speed with USB 1.1). Up to 127 devices can
|
||
be connected using a series of hubs each of which connects up to 7
|
||
devices (with a 5 metre limit). USB supplies 5 volts at 0.5 amps to
|
||
power small devices. USB is "plug and play", hot pluggable and supports
|
||
isochronous data transfers (required for audio and video devices that
|
||
need guaranteed minimum bandwidth).
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>PC Parallel port. </B
|
||
>
|
||
The original PC parallel port was uni-directional (towards the printer)
|
||
and was capable of about 10 KB/sec. The IEEE 1284 standard in 1994
|
||
introduced 5 modes of data transfer:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>Compatibility mode (forward direction)</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Nibble mode (reverse direction)</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Byte mode (reverse direction)</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>EPP mode (bi-directional)</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>ECP mode (bi-directional)</P
|
||
></LI
|
||
></UL
|
||
>
|
||
Enhanced Parallel Port (EPP) achieves transfer speeds of between 500 KB/sec
|
||
and 2 MB/sec and is targeted at CD-ROMs, tapes and hard drives. Extended
|
||
Capability Port (ECP) includes run length encoding and support for DMA.
|
||
ECP is targeted at fast printers and scanners.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>I2O. </B
|
||
>
|
||
"The I2O (Intelligent Input/Output) specification defines a standard
|
||
architecture for intelligent I/O that is independent of both the specific
|
||
device being controlled and the host operating system (OS)" [from <A
|
||
HREF="http://www.i2osig.org"
|
||
TARGET="_top"
|
||
><TT
|
||
CLASS="literal"
|
||
>www.i2osig.org</TT
|
||
></A
|
||
>].
|
||
It defines a "split driver" model in which the OS Services Module (OSM)
|
||
sits between the host OS device interface and the I2O communications layer
|
||
while the Hardware Device Module (HDM) sits between the I2O
|
||
communications layer and the hardware. The HDM may well run on a
|
||
dedicated processor (IOP).
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="appendix"
|
||
><HR><H1
|
||
><A
|
||
NAME="changes"
|
||
></A
|
||
>Appendix B. Changes between lk 2.2 and (during) 2.4</H1
|
||
><P
|
||
> Significant work has been done to change the single SCSI command queue
|
||
used in lk 2.2 to one command queue per device. To make the SCSI subsystem
|
||
more SMP friendly the granularity of the locks is much finer grained. In
|
||
lk 2.2 the whole subsystem essentially used one lock.
|
||
</P
|
||
><P
|
||
> Even though it is not part of the SCSI subsystem, the inclusion of devfs
|
||
solves many SCSI device addressing problems that existed in the past.
|
||
Associated with devfs but very useful even in its absence is the
|
||
"scsihosts" kernel boot time (and module load time) option. This option
|
||
allows users to have some control over the ordering of multiple SCSI hosts.
|
||
</P
|
||
><P
|
||
> This appendix is difficult to maintain since features and drivers that
|
||
have proven useful in lk 2.4 (and its development tree) have tended to
|
||
be back ported into the higher release numbers of the lk 2.2 series.
|
||
</P
|
||
><P
|
||
> Currently (lk 2.4.2) support for MO devices is broken. Old DOS file
|
||
systems with a block size of 2048 bytes also have been reported as broken.
|
||
The problem seems to arise with media that have a physical block size
|
||
larger than the 1 KB logical block size used by the block subsystem.
|
||
Only the sd driver has this problem (luckily not the sr driver in
|
||
which 2048 byte sectors are the norm).
|
||
</P
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="chgml"
|
||
></A
|
||
>B.1. Mid level changes</H1
|
||
><P
|
||
> <TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> SCSI_IOCTL_GET_IDLUN {ioctl, changed}
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="chgsd"
|
||
></A
|
||
>B.2. sd changes</H1
|
||
><P
|
||
> <TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> HDIO_GETGEO_BIG {ioctl, new}
|
||
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="chgsr"
|
||
></A
|
||
>B.3. sr changes</H1
|
||
><P
|
||
> No sr changes reported. As a related matter, the "hdx=scsi" kernel boot
|
||
option has been added. See <A
|
||
HREF="#sratapi"
|
||
>Section 9.2.4</A
|
||
> for more details.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="chgst"
|
||
></A
|
||
>B.4. st changes</H1
|
||
><P
|
||
> No interface changes. In lk 2.2 the maximum number of extra tape devices
|
||
that could be added after boot time was limited to 3. This limitation
|
||
has been removed (leaving a maximum of 32 tape devices as noted earlier).
|
||
</P
|
||
><P
|
||
> A variant st driver called "osst" to handle early model OnStream tape
|
||
drives has been added in lk 2.4 .
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="chgsg"
|
||
></A
|
||
>B.5. sg changes</H1
|
||
><P
|
||
> The main change is the addition of a new interface structure called
|
||
"sg_io_hdr". The existing interface structure (called "sg_header") was found
|
||
to be inflexible requiring the concatenation of raw data together with
|
||
meta-data in the read() and write() commands.
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> sg_io_hdr {new interface structure}
|
||
SG_IO {new ioctl}
|
||
direct IO {present but commented out, see ALLOW_DIO}
|
||
procfs output {new information in /proc/scsi/sg directory}
|
||
boot/module parameters {new}
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Up to 64 bytes of sense data can be obtained from the sg_io_hdr interface
|
||
structure. Also a residual count associated with the data transfer is
|
||
available (if the lower level driver supports it, if not the residual count
|
||
will be 0).
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="chg24"
|
||
></A
|
||
>B.6. Changes during the lk 2.4 series</H1
|
||
><P
|
||
> Even though the lk 2.4 production series is meant to be "stable" there
|
||
have been a significant number of changes as well as bug fixes. The
|
||
following list does not include changes to the lower level (adapter)
|
||
drivers. Each item of the list is prefixed by the kernel version that
|
||
it was introduced.
|
||
<A
|
||
NAME="AEN898"
|
||
HREF="#FTN.AEN898"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[14]</SPAN
|
||
></A
|
||
>
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> [2.4.4] added the SCSI_IOCTL_GET_PCI ioctl(),
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.7] the "lun" bits (3 bits representing lun values 0 through 7
|
||
in the SCSI 1 and SCSI 2 standards) are no longer masked into the second
|
||
byte of SCSI commands if the INQUIRY for that devices shows a SCSI level
|
||
greater than SCSI_2,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.7] the max_scsi_luns kernel (and module scsi_mod) option
|
||
previously could be 1 to 7. Now the upper value can be large. [The scan
|
||
algorithms are still doing a sequential scan rather than using REPORT_LUNS.]
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.7] both scsi_unregister_host() and scsi_unregister_module() now
|
||
return an int (previously they were void functions). They return 0 for
|
||
success, -1 for failure (typically busy),
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.7] the upper level drivers now report the correct scsi device
|
||
name when they are attached. [The log messages that started with
|
||
"Detected ..." previously sometimes reported the wrong device (e.g. sdc
|
||
rather than sdb).] Kernel boot up messages will now show SCSI devices
|
||
as "Attached ...",
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.7] 'max_sectors' was added to the Scsi_Host structure,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.8] some mid level logic was altered to retry commands if the
|
||
sense buffer indicates that logical unit is becoming ready [ASC=4, ASQ=1],
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.9] a major st update,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.9] mid level changed to retry
|
||
commands if lower level (adapter) driver returned DID_RESET,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.10] original result (including SCSI status) saved when mid level
|
||
issues a REQUEST SENSE so it can be restored afterwards,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.10] added BLKGETSIZE64, BLKBSZSET and BLKBSZGET ioctls to sd + sr,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.10] sg update that fixes generic_unplug_device() race + bumps
|
||
access_count on opens (and decrements on releases),
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.11] added MODULE_LICENSE macro in most drivers, mostly
|
||
MODULE_LICENSE("GPL"),
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.11] scsi_pid bumped for each command (why?),
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.11] st update to bump access_count. Now all upper level drivers
|
||
increment access_count on opens and decrement it on releases,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.13] scatterlist structure grows (alt_address is removed, page and
|
||
offset added),
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.13] don't probe luns > 7 for target <= SCSI_2 ,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.14] fine tuning (bug fixes) associated with scatterlist structure
|
||
changes [it broke st ?],
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.15] 16 byte SCSI commands permitted [MAX_COMMAND_SIZE changes from
|
||
12 to 16]. HBA driver must set Scsi_Host::max_cmd_len to 16 for
|
||
mid level to forward 16 byte SCSI commands,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.15] BLKGETSIZE + BLKGETSIZE64 ioctl() implementations moved out of
|
||
SCSI subsystem (and into block subsystem),
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.15] large st update,
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.15] lk 2.5.0 forks off so lk2.4.15==lk2.5.0 .
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.17] add generic_unplug_device() call to scsi_wait_req(). This stops
|
||
long waits in SCSI_IOCTL_SEND_COMMAND.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.17] fix device scanning bug where, in some cases, the scsi_level
|
||
(i.e. SCSI standard adherence) was misplaced.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.17] major sg driver update, add mmap()-ed IO
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.18] permit upper level driver "init()" functions (e.g. sd_init() )
|
||
to fail gracefully. [Add Scsi_Device::detected and scsi_unregister_module() .]
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.18] Fix for clustering (SCSI commands) on MO devices.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.18] st driver update (compression algorithms).
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.18] update Documentation/scsi.txt and scsi-generic.txt .
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.18] Revamp scsi_debug driver .
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.19] Scsi reservation and reset capability added. Reservations allow
|
||
multiple machines to share the same device (via a reserve/release mechanism).
|
||
Scsi reset (via sg) is needed to "break" a reservation held by a
|
||
non-responding machine.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.19] Introduce BLIST_LARGELUN to handle LUNs larger than 7 despite
|
||
reporting SCSI 2.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.19] Change sd and sr so RECOVERED_ERROR is not treated as a hard
|
||
error. Send warning to log/console.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.19] Zero out sg's buffers before use. [Sg version upgraded from
|
||
3.1.22 to 3.1.24 but this is not reflected in sg.h (supeficial).]
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.20] Support for highmem I/O added. Used by aic7xxx,
|
||
3w-xxxx, esp, megaraid, qlogicfc and sym53c8xx_2 LLDs.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.20] "blocking_open" boot time, module load time parameter added to st.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.21] Give new HBAs a new host number (higher than any previously used)
|
||
unless there is a "scsihosts" match. Host numbering sequence "holes" are
|
||
only re-used if there is a "scsihosts" match.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.21] stop the SCSI status RECOVERED ERROR being treated as an error
|
||
by the mid level (complements a change in 2.4.19).
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.21] use the TEST_UNIT_READY command (rather than START_STOP) to
|
||
determine if removable media has changed (in sd driver).
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.21] major work on ide-scsi driver.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.21] add aic79xx driver for Adaptec Ultra 320 controllers.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.22] Extend timeout of SEND DIAGNOSTIC command to 2 hours. This is
|
||
for foreground extended self tests.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.26] Add 'scsi_allow_ghost_devices' kernel boot time and scsi_mod
|
||
module option.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> [2.4.27] SATA support via "libata" library introduced. SATA disks appear
|
||
with SCSI subsystem names (e.g. "/dev/sdb) and respond to SCSI commands (via
|
||
a command translation facility).
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="appendix"
|
||
><HR><H1
|
||
><A
|
||
NAME="trouble"
|
||
></A
|
||
>Appendix C. Troubleshooting</H1
|
||
><P
|
||
> Many SCSI problems are caused by cabling and (lack of, or inappropriate)
|
||
termination. This often results in repeated SCSI bus resets, parity
|
||
or CRC errors and sometimes reduced transfer speeds. There is a good
|
||
SCSI termination tutorial at this site:
|
||
<A
|
||
HREF="http://www.scsita.org/aboutscsi/SCSI_Termination_Tutorial.html"
|
||
TARGET="_top"
|
||
> www.scsita.org/aboutscsi/SCSI_Termination_Tutorial.html</A
|
||
>. There is
|
||
other useful SCSI information at that site (see <A
|
||
HREF="#W9"
|
||
>W9</A
|
||
>).
|
||
</P
|
||
><P
|
||
> There is also a SCSI "faq" site (see <A
|
||
HREF="#W10"
|
||
>W10</A
|
||
>)
|
||
that addresses many configuration and troubleshooting issues. Although
|
||
the main focus of this site is Windows (and its ASPI interface), much
|
||
is relevant to SCSI in Linux and other Unix implementations.
|
||
</P
|
||
><P
|
||
> When it looks like something has partially locked up the system, the
|
||
<B
|
||
CLASS="command"
|
||
>ps</B
|
||
> command can be useful for finding out what may be
|
||
causing the problem. The following options may be useful for identifying what
|
||
part of the kernel may be causing the problem. This information could be
|
||
forwarded to the maintainers.
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> ps -eo cmd,wchan
|
||
ps -eo fname,tty,pid,stat,pcpu,wchan
|
||
ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
The most interesting option for finding the location of the "hang" is
|
||
"wchan". If this is a kernel address then <B
|
||
CLASS="command"
|
||
>ps</B
|
||
> will
|
||
use <TT
|
||
CLASS="filename"
|
||
>/proc/ksyms</TT
|
||
> to find the nearest symbolic
|
||
location. The "nwchan" option outputs the numerical address of the "hang".
|
||
</P
|
||
><P
|
||
> If the system is not responding to keystrokes, then <Alt+ScrollLock>
|
||
in text mode should output a stack trace while <Ctrl+ScrollLock>
|
||
should output a list of all processes. If the log is still working, the
|
||
output will be sent there as well as appearing on the console.
|
||
</P
|
||
><P
|
||
> If the kernel has been built with the CONFIG_MAGIC_SYSRQ, then in text
|
||
mode <Alt+SysRq+H> will list available commands. Of these <Alt+SysRq+S>
|
||
is useful for doing an emergency sync while <Alt+SysRq+U> will remount
|
||
file systems in read only mode. After that <Alt+SysRq+B> to reboot the
|
||
machine might be your next move.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="appendix"
|
||
><HR><H1
|
||
><A
|
||
NAME="perform"
|
||
></A
|
||
>Appendix D. Performance, Test and Debugging tools</H1
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>scu. </B
|
||
>
|
||
The SCSI Command Utility (SCU) implements various SCSI commands necessary
|
||
for normal maintenance and diagnostics of SCSI peripherals. Some of its
|
||
features include: formatting, scanning for (and reassigning) bad blocks,
|
||
downloading new firmware, executing diagnostics and obtaining
|
||
performance information. It is available on several Unix platforms
|
||
(and NT), however it is only currently available in binary form. See
|
||
<A
|
||
HREF="http://www.bit-net.com/~rmiller/scu.html"
|
||
TARGET="_top"
|
||
> www.bit-net.com/~rmiller/scu.html</A
|
||
> for more details.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>dd. </B
|
||
>
|
||
Very useful for testing the streaming performance of disks and cdroms/dvds.
|
||
See <B
|
||
CLASS="command"
|
||
>man dd</B
|
||
> for more details. Here is an example for
|
||
timing how long a disk takes to read 1 GB (10**9 bytes) starting from block 0:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> $ time dd if=/dev/sda of=/dev/null bs=512 count=1953126
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
If the raw device <TT
|
||
CLASS="filename"
|
||
>/dev/raw/raw1</TT
|
||
> is bound to
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/sda</TT
|
||
> then the above line is equivalent to:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> $ time dd if=/dev/raw/raw1 of=/dev/null bs=512 count=1953126
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
This may be slower than expected since one 512 byte sector is being read
|
||
at a time. Changing the last 2 arguments to "bs=8k count=122071" should
|
||
give better timings for the "raw" dd.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>dt. </B
|
||
>
|
||
The Data Test (DT) program is modelled on dd's syntax but dt can do a
|
||
lot more than sequential copies. It is a comprehensive data test program
|
||
for SCSI devices such as disks, tapes and cdrom/dvds. It is available on
|
||
several Unix platforms (and NT), and its source is available (unlike its
|
||
stable mate "scu" discussed earlier). See
|
||
<A
|
||
HREF="http://www.bit-net.com/~rmiller/dt.html"
|
||
TARGET="_top"
|
||
> www.bit-net.com/~rmiller/dt.html</A
|
||
> for more details.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>lmdd. </B
|
||
>
|
||
This command is part of the lmbench suite of programs and is a variant of the
|
||
<B
|
||
CLASS="command"
|
||
>dd</B
|
||
> command. It has been tailored for IO measurements
|
||
and outputs timing and throughput numbers on completion. Hence the
|
||
<B
|
||
CLASS="command"
|
||
>time</B
|
||
> command and a calculator are not needed.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>blockdev. </B
|
||
>
|
||
Fetches the sector size, the number of sectors and read ahead status
|
||
of a block device (typically a disk). Can also be used to flush buffers
|
||
and reread the partition table. See <B
|
||
CLASS="command"
|
||
>man blockdev</B
|
||
>.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>sg_dd. </B
|
||
>
|
||
This command is part of the sg_utils package (see
|
||
<A
|
||
HREF="#W4"
|
||
>W4</A
|
||
>) and is another variant of the
|
||
<B
|
||
CLASS="command"
|
||
>dd</B
|
||
> command in which either the input and/or
|
||
output file is a sg or a raw device. The block size argument ("bs") must
|
||
match that of the physical device in question. The "skip" and "seek" arguments
|
||
can be up to 2**31 - 1 on a 32 bit architecture allowing 1TB disks to be
|
||
accessed (2G * 512). The Linux system command llseek() is used to seek with
|
||
a 64 bit file read/write offset. The <B
|
||
CLASS="command"
|
||
>lmdd</B
|
||
> does not
|
||
handle the > 2GB case and the <B
|
||
CLASS="command"
|
||
>dd</B
|
||
> command gets creative
|
||
with multiple relative seeks. <B
|
||
CLASS="command"
|
||
>sg_dd</B
|
||
> has
|
||
a "bpt" (blocks per transfer) argument that controls the number of blocks
|
||
read or written in each IO transaction.
|
||
</P
|
||
></DIV
|
||
><P
|
||
> There are other programs in the sg_utils package to scan the SCSI bus
|
||
(<B
|
||
CLASS="command"
|
||
>sg_scan</B
|
||
> and <B
|
||
CLASS="command"
|
||
>sg_map</B
|
||
>), to measure
|
||
SCSI bus throughput (<B
|
||
CLASS="command"
|
||
>sg_rbuf</B
|
||
> and <B
|
||
CLASS="command"
|
||
>sg_turs
|
||
</B
|
||
>), show data from the SCSI inquiry command
|
||
(<B
|
||
CLASS="command"
|
||
>sg_inq</B
|
||
>) and spin up (or down) media
|
||
(<B
|
||
CLASS="command"
|
||
>sg_start</B
|
||
>).
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>dd_rescue + scsiinfo. </B
|
||
>
|
||
This dd variant is designed to rescue damaged media such as SCSI (or IDE)
|
||
disks and CDROMs (see <A
|
||
HREF="#W6"
|
||
>W6</A
|
||
>). The <B
|
||
CLASS="command"
|
||
> scsiinfo</B
|
||
> utility for displaying and changing mode page
|
||
information is also at that site.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>sard. </B
|
||
>
|
||
This utility is modelled on System V Release 4's <B
|
||
CLASS="command"
|
||
>sar -d</B
|
||
> for
|
||
producing IO statistics for mounted devices and partitions. It has been
|
||
developed by Stephen Tweedie and includes the sard utility and a required
|
||
kernel patch which expands the output of <TT
|
||
CLASS="filename"
|
||
>/proc/partitions</TT
|
||
>
|
||
. It can be found at
|
||
<A
|
||
HREF="ftp://ftp.uk.linux.org/pub/linux/sct/fs/profiling"
|
||
TARGET="_top"
|
||
> ftp.uk.linux.org/pub/linux/sct/fs/profiling</A
|
||
>. It collects statistics
|
||
at a relatively low level (e.g. SCSI mid level) compared to programs
|
||
like <B
|
||
CLASS="command"
|
||
>vmstat</B
|
||
> (see "man vmstat").
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="appendix"
|
||
><HR><H1
|
||
><A
|
||
NAME="compileopt"
|
||
></A
|
||
>Appendix E. Compile options and System calls including ioctls</H1
|
||
><P
|
||
> The compile options in this appendix are those which a system administrator
|
||
might conceivably want to change. Naturally the defaults are chosen so the
|
||
vast majority of users will not need to modify anything. In some cases setting
|
||
kernel build time options, kernel boot time parameters or module load
|
||
parameters has the same effect as changing a driver compile time option.
|
||
</P
|
||
><P
|
||
> System calls act as the interface between application programs and the
|
||
kernel and its drivers. In the case of the layered driver architecture that
|
||
the SCSI subsystem uses, the upper layer drivers handle most of the
|
||
system calls.
|
||
</P
|
||
><P
|
||
> The SCSI subsystem has a "bubble down" ioctl structure. First the upper level
|
||
driver associated with the open file descriptor attempts to decode the ioctl.
|
||
If it doesn't recognize it then the ioctl is passed down to the mid level. If
|
||
the mid level doesn't recognize it then the ioctl is passed down to the lower
|
||
level driver associated with the file descriptor. If the lower level driver
|
||
doesn't recognize it then a EINVAL error is generated.
|
||
</P
|
||
><P
|
||
> Some ioctls are dispatched to related subsystems.
|
||
</P
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="coml"
|
||
></A
|
||
>E.1. Mid level</H1
|
||
><P
|
||
> The following header files in the kernel source are relevant to the mid
|
||
level:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> /usr/src/linux/include/scsi/scsi.h
|
||
/usr/src/linux/include/scsi/scsi_ioctl.h
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> These files are meant for applications to use (other than parts in
|
||
a __KERNEL__ conditional compilation block). They may also be found in
|
||
/usr/include/scsi directory but it is best not to trust these versions as
|
||
they are maintained with the glibc library and may lag the kernel version
|
||
being used. Usually in Linux systems <TT
|
||
CLASS="filename"
|
||
>/usr/include/linux</TT
|
||
>
|
||
can be relied upon to be a symbolic link to the kernel source's include
|
||
area (typically <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/include/linux</TT
|
||
>). This
|
||
symbolic link can be used to include the correct <TT
|
||
CLASS="filename"
|
||
>scsi_ioctl.h
|
||
</TT
|
||
> using the following trick: <TT
|
||
CLASS="filename"
|
||
> #include <linux/../scsi/scsi_ioctl.h></TT
|
||
>
|
||
</P
|
||
><P
|
||
> This include file: <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/drivers/scsi/scsi.h</TT
|
||
>
|
||
is the key internal header file for the SCSI subsystem. As such it will not
|
||
be discussed here other than to point out it has the same file name (but
|
||
it's in a different directory) as the include file mentioned at the beginning
|
||
of this section. This sometimes causes confusion.
|
||
</P
|
||
><P
|
||
> The mid level <TT
|
||
CLASS="filename"
|
||
>drivers/scsi/scsi_scan.c</TT
|
||
> file
|
||
maintains an array of known SCSI devices with <EM
|
||
>idiosyncrasies
|
||
</EM
|
||
>. [This was known as the "black list" but that was considered
|
||
to judgmental.] The array is called "device_list". The various value are:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>BLIST_NOLUN only probe lun 0</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_FORCELUN force all 8 luns to be probed
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_BORKEN passes through broken flag to lower
|
||
level driver</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_KEY sends magical MODE SENSE (pc=0x2e) to
|
||
unlock device</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_SINGLELUN only allow IO on one lun at a time
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_NOTQ disable tagged queuing
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_SPARSELUN keep going after lun not found
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_MAX5LUN only probe up to lun 5
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_ISDISK override INQUIRY's type with disk (direct
|
||
access) type</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>BLIST_ISROM override INQUIRY's type with ROM
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="comlco"
|
||
></A
|
||
>E.1.1. Mid level compile options</H2
|
||
><P
|
||
> None.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="comlio"
|
||
></A
|
||
>E.1.2. Mid level ioctls</H2
|
||
><P
|
||
> See the following files:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> /usr/src/linux/include/scsi/scsi.h
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Note that the SCSI status constants defined in include/scsi/scsi.h are
|
||
shifted 1 bit right from the values in the SCSI standards:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
scsi.h constant value SCSI 2 standard value
|
||
----------------------------------------------------
|
||
CHECK_CONDITION 0x1 0x2
|
||
CHECK_GOOD 0x2 0x4
|
||
BUSY 0x4 0x8
|
||
....
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Summary of ioctl()s follow:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> SCSI_IOCTL_SEND_COMMAND
|
||
This interface is deprecated - users should use
|
||
the scsi generic (sg) interface instead, as this
|
||
is a more flexible approach to performing
|
||
generic SCSI commands on a device.
|
||
|
||
The structure that we are passed should look like:
|
||
|
||
struct sdata {
|
||
unsigned int inlen; [i] Length of data written to device
|
||
unsigned int outlen; [i] Length of data read from device
|
||
unsigned char cmd[x]; [i] SCSI command (6 <= x <= 16)
|
||
[o] Data read from device starts here
|
||
[o] On error, sense buffer starts here
|
||
unsigned char wdata[y]; [i] Data written to device starts here
|
||
};
|
||
Notes:
|
||
- The SCSI command length is determined by examining
|
||
the 1st byte of the given command. There is no way
|
||
to override this.
|
||
- Data transfers are limited to PAGE_SIZE (4K on
|
||
i386, 8K on alpha).
|
||
- The length (x + y) must be at least OMAX_SB_LEN
|
||
bytes long to accommodate the sense buffer when
|
||
an error occurs. The sense buffer is truncated to
|
||
OMAX_SB_LEN (16) bytes so that old code will not
|
||
be surprised.
|
||
- If a Unix error occurs (e.g. ENOMEM) then the user
|
||
will receive a negative return and the Unix error
|
||
code in 'errno'. If the SCSI command succeeds then
|
||
0 is returned. Positive numbers returned are the
|
||
compacted SCSI error codes (4 bytes in one int)
|
||
where the lowest byte is the SCSI status. See the
|
||
drivers/scsi/scsi.h file for more information on this.
|
||
|
||
SCSI_IOCTL_GET_IDLUN
|
||
This ioctl takes a pointer to a "struct scsi_idlun" object
|
||
as its third argument. The "struct scsi_idlun" definition
|
||
is found in <scsi/scsi.h>. It gets populated with scsi
|
||
host, channel, device id and lun data for the given device.
|
||
Unfortunately that header file "hides" that structure
|
||
behind a "#ifdef __KERNEL__" block. To use this, that
|
||
structure needs to be replicated in the user's program.
|
||
Something like:
|
||
typedef struct my_scsi_idlun {
|
||
int four_in_one; /* 4 separate bytes of info
|
||
compacted into 1 int */
|
||
int host_unique_id; /* distinguishes adapter cards from
|
||
same supplier */
|
||
} My_scsi_idlun;
|
||
"four_in_one" is made up as follows:
|
||
(scsi_device_id | (lun << 8) | (channel << 16) |
|
||
(host << 24))
|
||
These 4 components are assumed (or masked) to be 1 byte each.
|
||
|
||
SCSI_IOCTL_GET_BUS_NUMBER
|
||
In lk 2.2 and earlier this ioctl was needed to get the
|
||
host number. During lk 2.3 development the
|
||
SCSI_IOCTL_GET_IDLUN ioctl was changed to include this
|
||
information. Hence this ioctl is only needed for
|
||
backward compatibility.
|
||
SCSI_IOCTL_TAGGED_ENABLE
|
||
Probably a remnant of the past when the mid level
|
||
addressed such issues. Now this functionality is
|
||
controlled by the lower level drivers. Best ignored.
|
||
SCSI_IOCTL_TAGGED_DISABLE
|
||
See comment for SCSI_IOCTL_TAGGED_ENABLE.
|
||
SCSI_IOCTL_PROBE_HOST
|
||
This ioctl expects its 3rd argument to be a pointer to
|
||
a union that looks like this:
|
||
union probe_host {
|
||
unsigned int length; /* [i] max length of
|
||
output ASCII string */
|
||
char str[length]; /* [o] N.B. may need '\0'
|
||
appended */
|
||
};
|
||
The host associated with the device's fd either has a
|
||
host dependent information string or failing that its
|
||
name, output into the given structure. Note that the
|
||
output starts at the beginning of given structure
|
||
(overwriting the input length). N.B. A trailing '\0'
|
||
may need to be put on the output string if it has been
|
||
truncated by the input length. A return value of 1
|
||
indicates the host is present, 0 indicates that the
|
||
host isn't present (how can that happen?) and a
|
||
negative value indicates an error.
|
||
|
||
SCSI_IOCTL_DOORLOCK
|
||
SCSI_IOCTL_DOORUNLOCK
|
||
SCSI_IOCTL_TEST_UNIT_READY
|
||
Returns 0 if the unit (device) is ready, a positive
|
||
number if it is not or a negative number when there
|
||
is an OS error.
|
||
|
||
SCSI_IOCTL_START_UNIT
|
||
SCSI_IOCTL_STOP_UNIT
|
||
SCSI_EMULATED_HOST {same as SG_EMULATED_HOST <new>}
|
||
|
||
SCSI_IOCTL_GET_PCI
|
||
Yields the PCI slot name (pci_dev::slot_name) associated with the lower
|
||
level (adapter) driver that controls the current device. Up to 8 characters
|
||
are output to the locations pointed to by 'arg'. If the current device
|
||
is not controlled by a PCI device then errno is set to ENXIO.
|
||
[This ioctl() was introduced in lk 2.4.4]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="cosd"
|
||
></A
|
||
>E.2. sd driver</H1
|
||
><P
|
||
> </P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="cosdco"
|
||
></A
|
||
>E.2.1. sd compile options</H2
|
||
><P
|
||
> <TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> MAX_RETRIES {5}
|
||
SD_TIMEOUT {30 seconds}
|
||
SD_MOD_TIMEOUT {75 seconds}
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="cosdio"
|
||
></A
|
||
>E.2.2. sd ioctls and user interface</H2
|
||
><P
|
||
> The relevant files to see:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> include/linux/hdreg.h
|
||
include/linux/genhd.h
|
||
include/linux/fs.h
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> A list of ioctl()s follow:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> HDIO_GETGEO_BIG
|
||
HDIO_GETGEO [retrieve disk geometry]
|
||
BLKGETSIZE [number of sectors in device]
|
||
BLKROSET [set read only flag]
|
||
BLKROGET [get read only flag]
|
||
BLKRASET [set read ahead value]
|
||
BLKRAGET [get read ahead value]
|
||
BLKFLSBUF [instructs SCSI subsystem to flush buffers]
|
||
BLKSSZGET [get device block size]
|
||
BLKPG [partition table manipulation]
|
||
BLKELVGET [get elevator parameters]
|
||
BLKELVSET [set elevator parameters]
|
||
BLKRRPART [reread the partition table]
|
||
|
||
open() (all flags ignored)
|
||
close()
|
||
ioctl() (see list above)
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="cosr"
|
||
></A
|
||
>E.3. sr driver</H1
|
||
><P
|
||
> </P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="cosrco"
|
||
></A
|
||
>E.3.1. sr compile options</H2
|
||
><P
|
||
> None.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="cosrio"
|
||
></A
|
||
>E.3.2. sr ioctls and user interface</H2
|
||
><P
|
||
> See the following files:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> /usr/src/linux/include/linux/cdrom.h
|
||
/usr/src/linux/drivers/cdrom/cdrom.c [revision history section]
|
||
/usr/src/linux/Documentation/cdrom/cdrom-standard.tex
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> Some of the following ioctls are described in cdrom-standard.tex :
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> CDROMCLOSETRAY
|
||
CDROM_SET_OPTIONS
|
||
CDROM_CLEAR_OPTIONS
|
||
CDROM_SELECT_SPEED
|
||
CDROM_SELECT_DISC
|
||
CDROM_MEDIA_CHANGED
|
||
CDROM_DRIVE_STATUS
|
||
CDROM_CHANGER_NSLOTS
|
||
CDROM_LOCKDOOR
|
||
CDROM_DEBUG
|
||
CDROM_GET_CAPABILITY
|
||
DVD_READ_STRUCT
|
||
DVD_WRITE_STRUCT
|
||
DVD_AUTH
|
||
CDROM_SEND_PACKET
|
||
CDROM_NEXT_WRITABLE
|
||
CDROM_LAST_WRITTEN
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The O_NONBLOCK flag on the open() of scd devices is important. Without it the
|
||
open() will wait until there is media in the device before returning.
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
open() O_NONBLOCK
|
||
close()
|
||
read()
|
||
write()
|
||
ioctl()
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="cost"
|
||
></A
|
||
>E.4. st driver</H1
|
||
><P
|
||
> </P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="costco"
|
||
></A
|
||
>E.4.1. st compile options</H2
|
||
><P
|
||
> Most of the following compile options can be overridden with
|
||
boot/module parameters and/or runtime configuration (i.e. ioctls).
|
||
</P
|
||
><P
|
||
> The following parameters are defined in linux/drivers/scsi/st_options.h
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> ST_NOWAIT {0}
|
||
ST_IN_FILE_POS {0}
|
||
ST_RECOVERED_WRITE_FATAL {0}
|
||
ST_DEFAULT_BLOCK {0}
|
||
ST_BUFFER_BLOCKS {32}
|
||
ST_WRITE_THRESHOLD_BLOCKS {30}
|
||
ST_MAX_BUFFERS {4}
|
||
ST_MAX_SG {16}
|
||
ST_FIRST_SG {8}
|
||
ST_FIRST_ORDER {5}
|
||
ST_TWO_FM {0}
|
||
ST_BUFFER_WRITES {1}
|
||
ST_ASYNC_WRITES {1}
|
||
ST_READ_AHEAD {1}
|
||
ST_AUTO_LOCK {0}
|
||
ST_FAST_MTEOM {0}
|
||
ST_SCSI2LOGICAL {0}
|
||
ST_SYSV {0}
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> The following parameters are defined in linux/drivers/scsi/st.c
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> ST_TIMEOUT {900*HZ}
|
||
ST_LONG_TIMEOUT {14000*HZ}
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="costio"
|
||
></A
|
||
>E.4.2. st ioctls and user interface</H2
|
||
><P
|
||
> The Linux tape interface is defined in
|
||
<TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/include/linux/mtio.h </TT
|
||
>.
|
||
</P
|
||
><P
|
||
> The following ioctl()s are listed in alphabetical order with a brief
|
||
explanation to the right. [See st documentation (especially
|
||
<B
|
||
CLASS="command"
|
||
>man 4 st</B
|
||
>) for more details.]
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> MTIOCTOP [execute tape commands and set drive/driver options]
|
||
MTIOCGET [get the status of the drive]
|
||
MTIOCPOS [get the current tape location]
|
||
|
||
open() O_RDONLY, O_RDWR
|
||
close()
|
||
read()
|
||
write()
|
||
ioctl()
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><HR><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="cosg"
|
||
></A
|
||
>E.5. sg driver</H1
|
||
><P
|
||
> The following header files in the kernel source are relevant to the sg driver:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> /usr/src/linux/include/scsi/sg.h
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><P
|
||
> As pointed out in <A
|
||
HREF="#coml"
|
||
>Section E.1</A
|
||
> this is best included in
|
||
applications by using:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> #include <linux/../scsi/sg.h>
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="cosgco"
|
||
></A
|
||
>E.5.1. sg compile options</H2
|
||
><P
|
||
> Here are some defines from the sg.h file that the user could conceivably want
|
||
to change. The current default values are shown in braces on the right:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
SG_SCATTER_SZ {32768}
|
||
SG_DEF_RESERVED_SIZE {SG_SCATTER_SZ}
|
||
SG_DEF_FORCE_LOW_DMA {0}
|
||
SG_DEF_FORCE_PACK_ID {0}
|
||
SG_DEF_KEP_ORPHAN {0}
|
||
SG_MAX_QUEUE {16}
|
||
SG_DEFAULT_RETRIES {1} # i.e. don't retry
|
||
SG_BIG_BUFF {SG_DEF_RESERVED_SIZE}
|
||
SG_DEFAULT_TIMEOUT {60 seconds}
|
||
SG_DEF_COMMAND_Q {0 *}
|
||
SG_DEF_UNDERRUN_FLAG {0}
|
||
|
||
* The per file descriptor copy of this flips to 1 (thus
|
||
allowing command queuing) as soon as a write() based
|
||
on the newer sg_io_hdr structure is detected.
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="sect2"
|
||
><HR><H2
|
||
CLASS="sect2"
|
||
><A
|
||
NAME="cosgio"
|
||
></A
|
||
>E.5.2. sg ioctls and user interface</H2
|
||
><P
|
||
> The following ioctl()s are listed in alphabetical order with a brief
|
||
explanation to the right. [See sg documentation for more details.]
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
>
|
||
SG_EMULATED_HOST [indicate if adapter is ide-scsi]
|
||
SG_GET_COMMAND_Q [command queuing flag state]
|
||
SG_GET_KEEP_ORPHAN [interrupted SG_IO keep orphan flag state]
|
||
SG_GET_LOW_DMA ["low dma flag" (<= 16 MB on i386) state]
|
||
SG_GET_NUM_WAITING [number of responses waiting to be read()]
|
||
SG_GET_PACK_ID [pack_id of next to read() response
|
||
(-1 if none)]
|
||
SG_GET_REQUEST_TABLE [yields array of requests being processed]
|
||
SG_GET_RESERVED_SIZE [current size of reserved buffer]
|
||
SG_GET_SCSI_ID [a little more info than the mid level's
|
||
SCSI_IOCTL_GET_IDLUN ioctl]
|
||
SG_GET_SG_TABLESIZE [max entries in host's scatter gather table]
|
||
SG_GET_TIMEOUT [yields timeout (unit: jiffies
|
||
(10ms on i386))]
|
||
SG_GET_TRANSFORM [state of ide-scsi's transform flag]
|
||
SG_IO [send given SCSI command and wait for
|
||
response]
|
||
SG_NEXT_CMD_LEN [change command length of next command]
|
||
SG_SCSI_RESET [send a SCSI bus, device or host reset]
|
||
SG_SET_COMMAND_Q [set command queuing state {old=0, new=1}]
|
||
SG_SET_DEBUG [set debug level {0}]
|
||
SG_SET_KEEP_ORPHAN [set SG_IO's keep orphan flag {0}]
|
||
SG_SET_FORCE_LOW_DMA [force DMA buffer low (<= 16 MB on i386)
|
||
{0}]
|
||
SG_SET_FORCE_PACK_ID [so read() can fetch by pack_id {0}]
|
||
SG_SET_RESERVED_SIZE [change default buffer size
|
||
{SG_DEF_RESERVED_SIZE}]
|
||
SG_SET_TIMEOUT [change current timeout {60 secs} ]
|
||
SG_SET_TRANSFORM [set ide-scsi's ATAPI transform flag {0}]
|
||
|
||
open() [recognized oflags: O_RDONLY, O_RDWR, O_EXCL,
|
||
O_NONBLOCK]
|
||
close()
|
||
read()
|
||
write()
|
||
ioctl()
|
||
poll() [used when in O_NONBLOCK mode]
|
||
fasync() [enables generation of SIGIO signal for read()]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="appendix"
|
||
><HR><H1
|
||
><A
|
||
NAME="refs"
|
||
></A
|
||
>Appendix F. References, Credits and Corrections</H1
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>WEB. </B
|
||
>
|
||
The following references are found on the web. Please alert the author
|
||
if any of these links become stale.
|
||
</P
|
||
></DIV
|
||
><P
|
||
> <A
|
||
NAME="W1"
|
||
></A
|
||
>
|
||
[W1] SCSI (draft) standards, resources:
|
||
<A
|
||
HREF="http://www.t10.org"
|
||
TARGET="_top"
|
||
><TT
|
||
CLASS="literal"
|
||
>www.t10.org</TT
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W2"
|
||
></A
|
||
>
|
||
[W2] Eric Youngdale is the chief architect of the Linux SCSI subsystem:
|
||
<A
|
||
HREF="http://www.andante.org/scsi.html"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.andante.org/scsi.html</TT
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W4"
|
||
></A
|
||
>
|
||
[W4] The author's scsi generic (sg) site is:
|
||
<A
|
||
HREF="http://www.torque.net/sg"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.torque.net/sg</TT
|
||
></A
|
||
>.
|
||
The Linux Documentation Project's site includes the
|
||
<A
|
||
HREF="http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.tldp.org/HOWTO/SCSI-Generic-HOWTO/</TT
|
||
></A
|
||
> .
|
||
A (possibly later) version of that document can be found at
|
||
<A
|
||
HREF="http://www.torque.net/sg/p/sg_v3_ho"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.torque.net/sg/p/sg_v3_ho</TT
|
||
></A
|
||
> .
|
||
The sg_utils and sg3_utils packages, as tarballs and as binary and source
|
||
rpms can also be found on this page. These packages and others available
|
||
for the sg driver are discussed at
|
||
<A
|
||
HREF="http://www.torque.net/sg/u_index.html"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.torque.net/sg/u_index.html</TT
|
||
></A
|
||
>.
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W5"
|
||
></A
|
||
>
|
||
[W5] Richard Gooch's devfs site:
|
||
<A
|
||
HREF="http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.atnf.csiro.au/~rgooch/linux/docs/devfs.html</TT
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W6"
|
||
></A
|
||
>
|
||
[W6] Kurt Garloff's site (including the <B
|
||
CLASS="command"
|
||
>scsidev</B
|
||
>
|
||
and the <B
|
||
CLASS="command"
|
||
>scsiinfo</B
|
||
> utilities):
|
||
<A
|
||
HREF="http://www.garloff.de/kurt/linux/"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.garloff.de/kurt/linux/</TT
|
||
></A
|
||
>. Kurt also has
|
||
the damaged media rescue program <B
|
||
CLASS="command"
|
||
>dd_rescue</B
|
||
> at this site:
|
||
<A
|
||
HREF="http://www.garloff.de/kurt/linux/ddrescue"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.garloff.de/kurt/linux/ddrescue</TT
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W7"
|
||
></A
|
||
>
|
||
[W7] Drew Eckhardt's SCSI-HOWTO from 1996 (in ASCII):
|
||
<A
|
||
HREF="http://metalab.unc.edu/pub/Linux/docs/HOWTO/unmaintained/SCSI-HOWTO"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>metalab.unc.edu/pub/Linux/docs/HOWTO/unmaintained/SCSI-HOWTO
|
||
</TT
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W8"
|
||
></A
|
||
>
|
||
[W8] Linux Documentation Project (LDP):
|
||
<A
|
||
HREF="http://tldp.org"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>tldp.org</TT
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W9"
|
||
></A
|
||
>
|
||
[W9] SCSI Trade Association site has a lot of useful information:
|
||
<A
|
||
HREF="http://www.scsita.org"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.scsita.org</TT
|
||
></A
|
||
>
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="W10"
|
||
></A
|
||
>
|
||
[W10] SCSI FAQ site - useful source of information and links:
|
||
<A
|
||
HREF="http://www.scsifaq.org"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.scsifaq.org</TT
|
||
></A
|
||
>
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>NEWSGROUPS. </B
|
||
>
|
||
The following entries are actually reflectors rather than newsgroups.
|
||
Various web locations archive their contents (e.g.
|
||
<A
|
||
HREF="http://marc.theaimsgroup.com"
|
||
TARGET="_top"
|
||
><TT
|
||
CLASS="literal"
|
||
>marc.theaimsgroup.com</TT
|
||
></A
|
||
>).
|
||
</P
|
||
></DIV
|
||
><P
|
||
> <A
|
||
NAME="N1"
|
||
></A
|
||
>
|
||
[N1] Linux SCSI reflector: <TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto: linux-scsi@vger.kernel.org "
|
||
> linux-scsi@vger.kernel.org </A
|
||
>></TT
|
||
>.
|
||
This is a relatively low volume (circa 200 postings per month) Linux
|
||
SCSI specific group that many of the SCSI subsystem maintainers
|
||
monitor.
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="N2"
|
||
></A
|
||
>
|
||
[N2] Linux kernel reflector: <TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto: linux-kernel@vger.kernel.org "
|
||
> linux-kernel@vger.kernel.org </A
|
||
>></TT
|
||
>.
|
||
This is a relatively high volume (circa 5000 postings per month) group
|
||
for all aspects of the Linux kernel. The Linux SCSI reflector should
|
||
be tried first.
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>BOOKS. </B
|
||
>
|
||
Here are some books that the author found useful.
|
||
</P
|
||
></DIV
|
||
><P
|
||
> <A
|
||
NAME="B1"
|
||
></A
|
||
>
|
||
[B1] "Linux Device Drivers" Second edition by Alessandro Rubini
|
||
and Jonathan Corbet [O'Reilly 2001 ISBN 0-596-00008-1]
|
||
This is a solid text on Linux device drivers including some information
|
||
on the SCSI subsystem. It covers the block subsystem well and has
|
||
many char device driver examples. It has been updated for the Linux
|
||
2.4 series kernels and also includes information on the Linux 2.2 and 2.0
|
||
series. This book is highly recommended.
|
||
The authors
|
||
and the publisher have unselfishly made this book available under the GNU
|
||
Free Documentation License (version 1.1). It can be found in html at
|
||
<A
|
||
HREF="http://www.xml.com/ldd/chapter/book"
|
||
TARGET="_top"
|
||
> <TT
|
||
CLASS="literal"
|
||
>www.xml.com/ldd/chapter/book</TT
|
||
></A
|
||
> .
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="B2"
|
||
></A
|
||
>
|
||
[B2] "Running Linux" 3rd edition by M. Welsh, M. K. Dalheimer & L. Kaufman
|
||
[O'Reilly 1999 ISBN 1-56592-469-X]
|
||
This is a classic Linux tome which includes some SCSI configuration info.
|
||
</P
|
||
><P
|
||
> <A
|
||
NAME="B3"
|
||
></A
|
||
>
|
||
[B3] "The Programmer's Guide to SCSI" by Brian Sawert [Addison Wesley 1998
|
||
ISBN 0-201-18538-5]
|
||
This book covers many SCSI topics, including the pass through mechanisms
|
||
of Linux (sg) and ASPI/ASPI32 as used by Windows.
|
||
</P
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>CREDITS. </B
|
||
>
|
||
The author is grateful for the following contributions:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>Kai M<>kisara (st) <TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:Kai.Makisara at metla
|
||
dot fi"
|
||
>Kai.Makisara at metla
|
||
dot fi</A
|
||
>></TT
|
||
>
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Jens Axboe (sr) <TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:axboe at suse dot de"
|
||
>axboe at suse dot de</A
|
||
>></TT
|
||
>
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Richard Gooch (devfs) <TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:rgooch at atnf dot csiro
|
||
dot au"
|
||
>rgooch at atnf dot csiro
|
||
dot au</A
|
||
>></TT
|
||
>
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Tim Waugh (ppa, imm, ppscsi + docbook)
|
||
<TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:twaugh at redhat dot com"
|
||
>twaugh at redhat dot com</A
|
||
>></TT
|
||
> </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Gadi Oxman (ide-scsi)
|
||
<TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:gadio at netvision dot net dot il"
|
||
>gadio at netvision dot net dot il</A
|
||
>></TT
|
||
> </P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="formalpara"
|
||
><P
|
||
><B
|
||
>CORRECTIONS and SUGGESTIONS. </B
|
||
>
|
||
Please send any corrections or suggestions to the author at
|
||
<TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:dgilbert at interlog dot com"
|
||
>dgilbert at interlog dot com</A
|
||
>></TT
|
||
> or <TT
|
||
CLASS="email"
|
||
><<A
|
||
HREF="mailto:dougg at torque
|
||
dot net"
|
||
>dougg at torque
|
||
dot net</A
|
||
>></TT
|
||
> .
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
></DIV
|
||
><H3
|
||
CLASS="FOOTNOTES"
|
||
>Notes</H3
|
||
><TABLE
|
||
BORDER="0"
|
||
CLASS="FOOTNOTES"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN152"
|
||
HREF="#AEN152"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[1]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> SCSI standards allow for multiple initiators to be present on a single bus.
|
||
This is not well supported in Linux although there are patches around
|
||
that improve this situation.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN172"
|
||
HREF="#AEN172"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[2]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> If 15 partitions is too limiting then the Logical Volume Manager (LVM)
|
||
might be considered. See <TT
|
||
CLASS="filename"
|
||
>/usr/src/linux/Documentation/LVM-HOWTO
|
||
</TT
|
||
>. LVM will also allow a logical partition to span multiple
|
||
block devices.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN264"
|
||
HREF="#AEN264"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[3]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> One slight wrinkle with grub is that <TT
|
||
CLASS="filename"
|
||
>/etc/grub.conf</TT
|
||
> is
|
||
a symbolic link to <TT
|
||
CLASS="filename"
|
||
>/boot/grub/grub.conf</TT
|
||
>. This can be
|
||
useful to know when <TT
|
||
CLASS="filename"
|
||
>/boot</TT
|
||
> is a separate partition.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN322"
|
||
HREF="#AEN322"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[4]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> There is a sequencing issue here if the root file system is on the SCSI
|
||
device controlled by the lower level (adapter) driver to be loaded since
|
||
it contains the <TT
|
||
CLASS="filename"
|
||
>/etc/modules.conf</TT
|
||
> file. Also there
|
||
is the issue of how the boot loader obtains the initial kernel image from
|
||
a SCSI device (often from the (master) boot record). The latter is usually
|
||
taken care of by the system's or adapter card's BIOS.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN328"
|
||
HREF="#AEN328"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[5]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> An example of using <B
|
||
CLASS="command"
|
||
>mkinitrd</B
|
||
>: assume the root
|
||
partition is on a SCSI disk connected to a controller from
|
||
Adaptec that requires the aic7xxx driver. After
|
||
building a kernel with the aic7xxx driver specified as a module then
|
||
load the image into the normal place (probably in the
|
||
<TT
|
||
CLASS="filename"
|
||
>/boot</TT
|
||
> directory). Next make sure a line like
|
||
"alias scsi_hostadapter aic7xxx" is in the <TT
|
||
CLASS="filename"
|
||
>/etc/modules.conf
|
||
</TT
|
||
> file. Then from the <TT
|
||
CLASS="filename"
|
||
>/boot</TT
|
||
> directory
|
||
execute a line like <B
|
||
CLASS="command"
|
||
>mkinitrd /boot/initrd-2.4.5.img 2.4.5</B
|
||
>
|
||
(this assumes lk 2.4.5 is being build). This should result in the
|
||
file <TT
|
||
CLASS="filename"
|
||
>initrd-2.4.5.img</TT
|
||
> being created. The
|
||
<TT
|
||
CLASS="filename"
|
||
>/etc/lilo.conf</TT
|
||
> should then have a section added
|
||
looking something like this:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> image=/boot/vmlinuz-2.4.5
|
||
label=linux
|
||
initrd=/boot/initrd-2.4.5.img
|
||
read-only
|
||
root=/dev/sda7
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
The following should also be selected in the kernel configuration:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> CONFIG_BLK_DEV_RAM=y
|
||
CONFIG_BLK_DEV_RAM_SIZE=4096
|
||
CONFIG_BLK_DEV_INITRD=y
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
See also <TT
|
||
CLASS="filename"
|
||
>Documentation/initrd.txt</TT
|
||
>.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN371"
|
||
HREF="#AEN371"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[6]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> PCI adapters are much "safer" for initialization code than the older ISA
|
||
adapters. Hence the order of initialization of PCI adapters is unlikely
|
||
to lead to lockups. In this case the order of initialization (and thus
|
||
SCSI adapter numbers) of built in drivers may be modified by changing the
|
||
order of entries in the SCSI subsystem Makefile (<TT
|
||
CLASS="filename"
|
||
> /usr/src/linux/drivers/scsi/Makefile</TT
|
||
>). Beware: some adapters
|
||
may be recognized by more than one lower level driver (e.g. those
|
||
based on NCR chipsets).
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN377"
|
||
HREF="#AEN377"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[7]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> Either comma or colon can be delimiters for "scsihosts". This means that
|
||
"scsihosts=advansys,imm,,ide-scsi" is also valid. Also if a machine's
|
||
boot sequence involves an "initrd" stage (look in
|
||
<TT
|
||
CLASS="filename"
|
||
>/etc/grub.conf</TT
|
||
> or <TT
|
||
CLASS="filename"
|
||
>/etc/lilo.conf</TT
|
||
>
|
||
to find out if this is the case), then the <B
|
||
CLASS="command"
|
||
>mkinitrd</B
|
||
>
|
||
command should be run after a change to the "scsihosts" boot time parameter.
|
||
This will generate a new initrd image that needs to be put in the
|
||
correct place (most probably in the <TT
|
||
CLASS="filename"
|
||
>/boot</TT
|
||
>
|
||
directory).
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN383"
|
||
HREF="#AEN383"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[8]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> Using "scsihosts" can lead to a situation in which the computer's BIOS finds
|
||
the boot track (and hence boot time parameters set in lilo or grub) on one
|
||
disk while the kernel finds the root partition on another disk. This can
|
||
be quite confusing when it is unplanned. Hence after changing (or adding)
|
||
"scsihosts" in lilo or grub's configuration, it may be wise to boot the
|
||
machine to see which disks are accessed.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN407"
|
||
HREF="#AEN407"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[9]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> The parsing of "add-single-device" and "remove-single-device" is rather
|
||
inflexible. Hence it is best to stay close to the demonstrated syntax
|
||
with no extra spaces (and no tabs).
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN489"
|
||
HREF="#AEN489"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[10]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> ATA is the modern name for what was previously known as IDE and/or EIDE.
|
||
Note that the subsystem that controls ATA devices in Linux is called
|
||
the "IDE" subsystem for historical reasons.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN495"
|
||
HREF="#AEN495"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[11]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> Other ATA devices such as tapes and floppies often use the ATAPI interface.
|
||
However, the vast majority of ATA disks do <EM
|
||
>not</EM
|
||
> use
|
||
the ATAPI interface.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN523"
|
||
HREF="#AEN523"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[12]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> In the linux 2.4 kernel series there has been an increase in problems when
|
||
the ide-scsi driver is used so that <B
|
||
CLASS="command"
|
||
>cdrecord</B
|
||
> can control
|
||
ATAPI (IDE) cd writers. The problem may be related to the aggressive manner
|
||
in which the IDE subsystem attempts to optimize the speed of data transfers
|
||
on devices it controls. Some people experiencing timeouts and machine lockups
|
||
have found that reducing the DMA setting via the <B
|
||
CLASS="command"
|
||
>hdparm</B
|
||
>
|
||
command has fixed the problem. If the cd writer is connected to
|
||
<TT
|
||
CLASS="filename"
|
||
>/dev/hdd</TT
|
||
> then users have reported success with one of
|
||
these two commands:
|
||
<TABLE
|
||
BORDER="0"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="programlisting"
|
||
> hdparm -d0 -c1 /dev/hdd
|
||
hdparm -d 1 -X 34 /dev/hdd
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
The first one turns off DMA completely while the second one sets it in
|
||
"multiword DMA mode 2". Cd writers do not need the types of speeds that
|
||
modern disks utilize. Even burning at "x16" implies a sustained transfer
|
||
rate of 16 times 150 KB/sec which is approximately 2.4 MB/sec, not
|
||
really that fast. There has also been a report that moving a cd writer off
|
||
a high speed IDE controller (Promise) and back to the motherboard's lower
|
||
speed IDE controllers has fixed a random IDE bus reset problem. Another
|
||
report suggests reducing (or turning off) the DMA on the IDE hard disk can
|
||
also stop lockups.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN659"
|
||
HREF="#AEN659"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[13]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> It has been reported that in some distributions the attempt
|
||
to use the hdparm command fails. In this case use the "echo ... >
|
||
/proc/ide/hdx/settings" form.
|
||
</P
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="5%"
|
||
><A
|
||
NAME="FTN.AEN898"
|
||
HREF="#AEN898"
|
||
><SPAN
|
||
CLASS="footnote"
|
||
>[14]</SPAN
|
||
></A
|
||
></TD
|
||
><TD
|
||
ALIGN="LEFT"
|
||
VALIGN="TOP"
|
||
WIDTH="95%"
|
||
><P
|
||
> This list has been compiled from the official 2.4 series kernels released
|
||
at <A
|
||
HREF="http://www.kernel.org"
|
||
TARGET="_top"
|
||
> www.kernel.org</A
|
||
>. Distributions
|
||
are free to tailor the official kernels and this may impact what is
|
||
supported (or changed) in the SCSI subsystem. For example this machine
|
||
reports this kernel: "2.4.18-27.8.0". So that is roughly based on the
|
||
official 2.4.18 kernel which the vendor has "modded" 27 times for the
|
||
"8.0" level of their distribution. As an example of the type of changes,
|
||
the aic7xxx driver in the official 2.4.18 does not support Adaptec's
|
||
Ultra 320 series of PCI adapters; however that vendor's version does.
|
||
</P
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
></BODY
|
||
></HTML
|
||
> |