path: root/static/freebsd/man4/scsi.4 3.html

<table class="head">
  <tr>
    <td class="head-ltitle">CAM(4)</td>
    <td class="head-vol">Device Drivers Manual</td>
    <td class="head-rtitle">CAM(4)</td>
  </tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp"><code class="Nm">CAM</code> &#x2014; <span class="Nd">Common
    Access Method Storage subsystem</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp"><code class="Cd">device scbus</code>
  <br/>
  <code class="Cd">device ada</code>
  <br/>
  <code class="Cd">device cd</code>
  <br/>
  <code class="Cd">device ch</code>
  <br/>
  <code class="Cd">device da</code>
  <br/>
  <code class="Cd">device pass</code>
  <br/>
  <code class="Cd">device pt</code>
  <br/>
  <code class="Cd">device sa</code>
  <br/>
  <code class="Cd">options CAMDEBUG</code>
  <br/>
  <code class="Cd">options CAM_DEBUG_BUS=-1</code>
  <br/>
  <code class="Cd">options CAM_DEBUG_TARGET=-1</code>
  <br/>
  <code class="Cd">options CAM_DEBUG_LUN=-1</code>
  <br/>
  <code class="Cd">options
    CAM_DEBUG_COMPILE=CAM_DEBUG_INFO|CAM_DEBUG_CDB|CAM_DEBUG_PROBE</code>
  <br/>
  <code class="Cd">options CAM_DEBUG_FLAGS=CAM_DEBUG_INFO|CAM_DEBUG_CDB</code>
  <br/>
  <code class="Cd">options CAM_MAX_HIGHPOWER=4</code>
  <br/>
  <code class="Cd">options SCSI_NO_SENSE_STRINGS</code>
  <br/>
  <code class="Cd">options SCSI_NO_OP_STRINGS</code>
  <br/>
  <code class="Cd">options SCSI_DELAY=8000</code></p>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">The <code class="Nm">CAM</code> subsystem provides a uniform and
    modular system for the implementation of drivers to control various SCSI,
    ATA, NVMe, and MMC / SD devices, and to utilize different SCSI, ATA, NVMe,
    and MMC / SD host adapters through host adapter drivers. When the system
    probes buses, it attaches any devices it finds to the appropriate drivers.
    The <a class="Xr">pass(4)</a> driver, if it is configured in the kernel,
    will attach to all devices.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYSCTL_VARIABLES"><a class="permalink" href="#SYSCTL_VARIABLES">SYSCTL
  VARIABLES</a></h1>
<p class="Pp">The following variables are available as both
    <a class="Xr">sysctl(8)</a> variables and <a class="Xr">loader(8)</a>
    tunables:</p>
<dl class="Bl-tag">
  <dt id="kern.cam.cam_srch_hi"><var class="Va">kern.cam.cam_srch_hi</var></dt>
  <dd>Search above LUN 7 for SCSI3 and greater devices.</dd>
  <dt id="kern.cam.tur_timeout"><var class="Va">kern.cam.tur_timeout</var></dt>
  <dd>Timeout, in ms, for the initial TESTUNITREADY command we send to the
      devices during their initial probing. Defaults to 1s.
      <span class="Ux">FreeBSD 15</span> and earlier set this to 60s.</dd>
  <dt id="kern.cam.inquiry_timeout"><var class="Va">kern.cam.inquiry_timeout</var></dt>
  <dd>Timeout, in ms, for the initial INQUIRY command we send to the devices
      during their initial probing. Defaults to 1s. <span class="Ux">FreeBSD
      15</span> and earlier set this to 60s.</dd>
  <dt id="kern.cam.reportluns_timeout"><var class="Va">kern.cam.reportluns_timeout</var></dt>
  <dd>Timeout, in ms, for the initial REPORTLUNS command we send to the devices
      during their initial probing. Defaults to 50s.</dd>
  <dt id="kern.cam.max_high_power"><var class="Va">kern.cam.max_high_power</var></dt>
  <dd>The maximum number high power commands, like START UNIT, to issue at the
      same time. Defaults to 4.</dd>
  <dt id="kern.cam.modesense_timeout"><var class="Va">kern.cam.modesense_timeout</var></dt>
  <dd>Timeout, in ms, for the initial MODESENSE command we send to the devices
      during their initial probing. Defaults to 1s. <span class="Ux">FreeBSD
      15</span> and earlier set this to 60s.</dd>
</dl>
</section>
<section class="Sh">
<h1 class="Sh" id="KERNEL_CONFIGURATION"><a class="permalink" href="#KERNEL_CONFIGURATION">KERNEL
  CONFIGURATION</a></h1>
<p class="Pp">There are a number of generic kernel configuration options for the
    <code class="Nm">CAM</code> subsystem:</p>
<dl class="Bl-tag">
  <dt id="CAM_BOOT_DELAY"><a class="permalink" href="#CAM_BOOT_DELAY"><code class="Dv">CAM_BOOT_DELAY</code></a></dt>
  <dd>Additional time to wait after the static parts of the kernel have run to
      allow for discovery of additional devices which may take time to connect,
      such as USB attached storage.</dd>
  <dt id="CAM_IOSCHED_DYNAMIC"><a class="permalink" href="#CAM_IOSCHED_DYNAMIC"><code class="Dv">CAM_IOSCHED_DYNAMIC</code></a></dt>
  <dd>Enable dynamic decisions in the I/O scheduler based on hints and the
      current performance of the storage devices.</dd>
  <dt id="CAM_IO_STATS"><a class="permalink" href="#CAM_IO_STATS"><code class="Dv">CAM_IO_STATS</code></a></dt>
  <dd>Enable collection of statistics for periph devices.</dd>
  <dt id="CAM_TEST_FAILURE"><a class="permalink" href="#CAM_TEST_FAILURE"><code class="Dv">CAM_TEST_FAILURE</code></a></dt>
  <dd>Enable ability to simulate I/O failures.</dd>
  <dt id="CAMDEBUG"><a class="permalink" href="#CAMDEBUG"><code class="Dv">CAMDEBUG</code></a></dt>
  <dd>This option compiles in all the <code class="Nm">CAM</code> debugging
      printf code. This will not actually cause any debugging information to be
      printed out when included by itself. See below for details.</dd>
  <dt id="CAM_MAX_HIGHPOWER=4"><a class="permalink" href="#CAM_MAX_HIGHPOWER=4"><code class="Dv">CAM_MAX_HIGHPOWER=4</code></a></dt>
  <dd>This sets the maximum allowable number of concurrent &quot;high
      power&quot; commands. A &quot;high power&quot; command is a command that
      takes more electrical power than most to complete. An example of this is
      the SCSI START UNIT command. Starting a disk often takes significantly
      more electrical power than normal operation. This option allows the user
      to specify how many concurrent high power commands may be outstanding
      without overloading the power supply on his computer.</dd>
  <dt id="SCSI_NO_SENSE_STRINGS"><a class="permalink" href="#SCSI_NO_SENSE_STRINGS"><code class="Dv">SCSI_NO_SENSE_STRINGS</code></a></dt>
  <dd>This eliminates text descriptions of each SCSI Additional Sense Code and
      Additional Sense Code Qualifier pair. Since this is a fairly large text
      database, eliminating it reduces the size of the kernel somewhat. This is
      primarily necessary for boot floppies and other low disk space or low
      memory space environments. In most cases, though, this should be enabled,
      since it speeds the interpretation of SCSI error messages. Do not let the
      &quot;kernel bloat&quot; zealots get to you -- leave the sense
      descriptions in your kernel!</dd>
  <dt id="SCSI_NO_OP_STRINGS"><a class="permalink" href="#SCSI_NO_OP_STRINGS"><code class="Dv">SCSI_NO_OP_STRINGS</code></a></dt>
  <dd>This disables text descriptions of each SCSI opcode. This option, like the
      sense string option above, is primarily useful for environments like a
      boot floppy where kernel size is critical. Enabling this option for normal
      use is not recommended, since it slows debugging of SCSI problems.</dd>
  <dt id="SCSI_DELAY=8000"><a class="permalink" href="#SCSI_DELAY=8000"><code class="Dv">SCSI_DELAY=8000</code></a></dt>
  <dd>This is the SCSI &quot;bus settle delay.&quot; In
      <code class="Nm">CAM</code>, it is specified in
      <a class="permalink" href="#milliseconds"><i class="Em" id="milliseconds">milliseconds</i></a>,
      not seconds like the old SCSI layer used to do. When the kernel boots, it
      sends a bus reset to each SCSI bus to tell each device to reset itself to
      a default set of transfer negotiations and other settings. Most SCSI
      devices need some amount of time to recover from a bus reset. Newer disks
      may need as little as 100ms, while old, slow devices may need much longer.
      If the <code class="Dv">SCSI_DELAY</code> is not specified, it defaults to
      2 seconds. The minimum allowable value for
      <code class="Dv">SCSI_DELAY</code> is &quot;100&quot;, or 100ms. One
      special case is that if the <code class="Dv">SCSI_DELAY</code> is set to
      0, that will be taken to mean the &quot;lowest possible value.&quot; In
      that case, the <code class="Dv">SCSI_DELAY</code> will be reset to
    100ms.</dd>
</dl>
<p class="Pp">All devices and buses support dynamic allocation so that an upper
    number of devices and controllers does not need to be configured;
    <code class="Cd">device da</code> will suffice for any number of disk
    drivers.</p>
<p class="Pp" id="wired">The devices are either
    <a class="permalink" href="#wired"><i class="Em">wired</i></a> so they
    appear as a particular device unit or
    <a class="permalink" href="#counted"><i class="Em" id="counted">counted</i></a>
    so that they appear as the next available unused unit.</p>
<p class="Pp">Units are wired down by setting kernel environment hints. This is
    usually done either interactively from the <a class="Xr">loader(8)</a>, or
    automatically via the <span class="Pa">/boot/device.hints</span> file. The
    basic syntax is:</p>
<div class="Bd Pp Bd-indent Li">
<pre>hint.device.unit.property=&quot;value&quot;</pre>
</div>
<p class="Pp">Individual <code class="Nm">CAM</code> bus numbers can be wired
    down to specific controllers with a config line similar to the
  following:</p>
<div class="Bd Pp Bd-indent Li">
<pre>hint.scbus.0.at=&quot;mpr1&quot;</pre>
</div>
<p class="Pp" id="mpr1">This assigns <code class="Nm">CAM</code> bus number 0 to
    the <a class="permalink" href="#mpr1"><i class="Em">mpr1</i></a> driver
    instance. For controllers supporting more than one bus, a particular bus can
    be assigned as follows:</p>
<div class="Bd Pp Bd-indent Li">
<pre>hint.scbus.0.at=&quot;ahci1&quot;
hint.scbus.0.bus=&quot;1&quot;</pre>
</div>
<p class="Pp" id="ahci1">This assigns <code class="Nm">CAM</code> bus 0 to the
    bus 1 instance on
    <a class="permalink" href="#ahci1"><i class="Em">ahci1</i></a>. Peripheral
    drivers can be wired to a specific bus, target, and lun as so:</p>
<div class="Bd Pp Bd-indent Li">
<pre>hint.da.0.at=&quot;scbus0&quot;
hint.da.0.target=&quot;0&quot;
hint.da.0.lun=&quot;0&quot;</pre>
</div>
<p class="Pp" id="da0">This assigns
    <a class="permalink" href="#da0"><i class="Em">da0</i></a> to target 0, unit
    (lun) 0 of scbus 0. Omitting the target or unit hints will instruct
    <code class="Nm">CAM</code> to treat them as wildcards and use the first
    respective counted instances. These examples can be combined together to
    allow a peripheral device to be wired to any particular controller, bus,
    target, and/or unit instance.</p>
<p class="Pp">This also works with <a class="Xr">nvme(4)</a> drives.</p>
<div class="Bd Pp Bd-indent Li">
<pre>hint.nvme.4.at=&quot;pci7:0:0&quot;
hint.scbus.10.at=&quot;nvme4&quot;
hint.nda.10.at=&quot;scbus10&quot;
hint.nda.10.target=&quot;1&quot;
hint.nda.10.lun=&quot;12&quot;
hint.nda.11.at=&quot;scbus10&quot;
hint.nda.11.target=&quot;1&quot;
hint.nda.11.lun=&quot;2&quot;</pre>
</div>
<p class="Pp" id="nda10">This assigns the NVMe card at PCI bus 7 slot 0 function
    1 to scbus 10. The target for <a class="Xr">nda(4)</a> devices is always 1.
    The unit is the namespace identifier from the drive. The namespace id 1 is
    exported as <a class="permalink" href="#nda10"><i class="Em">nda10</i></a>
    and namespace id 2 is exported as
    <a class="permalink" href="#nda11"><i class="Em" id="nda11">nda11</i></a>.</p>
<p class="Pp">For devices that provide a serial number, units may be wired to
    that serial number without regard where the drive is attached:</p>
<div class="Bd Pp Bd-indent Li">
<pre>hint.nda.3.sn=&quot;CY0AN07101120B12P&quot;
hint.da.44.sn=&quot;143282400011&quot;
hint.ada.2.sn=&quot;A065D591&quot;</pre>
</div>
wires <a class="permalink" href="#nda3"><i class="Em" id="nda3">nda3</i></a>,
  <a class="permalink" href="#da44"><i class="Em" id="da44">da44</i></a>, and
  <a class="permalink" href="#ada2"><i class="Em" id="ada2">ada2</i></a> to
  drives with the specified serial numbers. One need not specify an
  <a class="permalink" href="#at"><i class="Em" id="at">at</i></a> line when
  serial numbers are used.
</section>
<section class="Sh">
<h1 class="Sh" id="ADAPTERS"><a class="permalink" href="#ADAPTERS">ADAPTERS</a></h1>
<p class="Pp">The system allows common device drivers to work through many
    different types of adapters. The adapters take requests from the upper
    layers and do all IO between the SCSI, ATA, NVMe, or MMC / SD bus and the
    system. The maximum size of a transfer is governed by the adapter. Most
    adapters can transfer 1MB in a single operation, however many can transfer
    larger amounts.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="TARGET_MODE"><a class="permalink" href="#TARGET_MODE">TARGET
  MODE</a></h1>
<p class="Pp">Some adapters support
    <a class="permalink" href="#target"><i class="Em" id="target">target
    mode</i></a> in which the system is capable of operating as a device,
    responding to operations initiated by another system. Target mode is
    supported for some adapters, but is not yet complete for this version of the
    <code class="Nm">CAM</code> SCSI subsystem.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="ARCHITECTURE"><a class="permalink" href="#ARCHITECTURE">ARCHITECTURE</a></h1>
<p class="Pp">The <code class="Nm">CAM</code> subsystem glues together the upper
    layers of the system to the storage devices. PERIPH devices accept storage
    requests from GEOM and other upper layers of the system and translates them
    into protocol requests. XPT (transport) dispatches these protocol requests
    to a SIM driver. A SIM driver takes protocol requests and translates them
    into hardware commands the host adapter understands to transfer the protocol
    requests, and data (if any) to the storage device. The CCB transports these
    requests around as messages.</p>
<section class="Ss">
<h2 class="Ss" id="CAM"><a class="permalink" href="#CAM">CAM</a></h2>
<p class="Pp">The Common Access Method was a standard defined in the 1990s to
    talk to disk drives. <span class="Ux">FreeBSD</span> is one of the few
    operating systems to fully implement this model. The interface between
    different parts of CAM is the CCB (or CAM Control Block). Each CCB has a
    standard header, which contains the type of request and dispatch
    information, and a command specific portion. A CAM Periph generates
    requests. The XPT layer dispatches these requests to the appropriate SIM.
    Some CCBs are sent directly to the SIM for immediate processing, while
    others are queued and complete when the I/O has finished. A SIM takes CCBs
    and translates them into hardware specific commands to push the SCSI CDB or
    other protocol control block to the peripheral, along with setting up the
    DMA for the associated data.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Periph_Devices"><a class="permalink" href="#Periph_Devices">Periph
  Devices</a></h2>
<p class="Pp">A periph driver knows how to translate standard requests into
    protocol messages that a SIM can deliver to hardware. These requests can
    come from any upper layer source, but primarily come in via GEOM as a bio
    request. They can also come in directly from character device requests for
    tapes and pass through commands.</p>
<p class="Pp">Disk devices, or direct access (da) in CAM, are one type of
    peripheral. These devices present themselves to the kernel a device ending
    in &#x201C;da&#x201D;. Each protocol has a unique device name:</p>
<dl class="Bl-tag">
  <dt><a class="Xr">da(4)</a></dt>
  <dd>SCSI or SAS device, or devices that accept SCSI CDBs for I/O.</dd>
  <dt><a class="Xr">ada(4)</a></dt>
  <dd>ATA or SATA device</dd>
  <dt><a class="Xr">nda(4)</a></dt>
  <dd>NVME device</dd>
  <dt><a class="Xr">sdda(4)</a></dt>
  <dd>An SD or MMC block storage device.</dd>
</dl>
<p class="Pp">Tape devices are called serial access (<a class="Xr">sa(4)</a>) in
    CAM. They interface to the system via a character device and provide
    <a class="Xr">ioctl(2)</a> control for tape drives.</p>
<p class="Pp">The <a class="Xr">pass(4)</a> device will pass through CCB
    requests from userland to the SIM directly. The device is used to send
    commands other than read, write, trim or flush to a device. The
    <a class="Xr">camcontrol(8)</a> command uses this device.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="XPT_drivers"><a class="permalink" href="#XPT_drivers">XPT
  drivers</a></h2>
<p class="Pp">The transport driver connects the periph to the SIM. It is not
    configured separately. It is also responsible for device discovery for those
    SIM drivers that do not enumerate themselves.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="SIM_driver"><a class="permalink" href="#SIM_driver">SIM
  driver</a></h2>
<p class="Pp">SIM used to stand for SCSI Interface Module. Now it is just SIM
    because it understands protocols other than SCSI. There are two types of SIM
    drivers: virtual and physical. Physical SIMs are typically called host bus
    adapters (HBA), but not universally. Virtual SIM drivers are for
    communicating with network or virtual machine hosts.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="FILES"><a class="permalink" href="#FILES">FILES</a></h1>
<p class="Pp">see other <code class="Nm">CAM</code> device entries.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="DIAGNOSTICS"><a class="permalink" href="#DIAGNOSTICS">DIAGNOSTICS</a></h1>
<p class="Pp">An XPT_DEBUG CCB can be used to enable various amounts of tracing
    information on any specific bus/device from the list of options compiled
    into the kernel. There are currently seven debugging flags that may be
    compiled in and used:</p>
<dl class="Bl-tag">
  <dt id="CAM_DEBUG_INFO"><a class="permalink" href="#CAM_DEBUG_INFO"><code class="Dv">CAM_DEBUG_INFO</code></a></dt>
  <dd>This flag enables general informational printfs for the device or devices
      in question.</dd>
  <dt id="CAM_DEBUG_TRACE"><a class="permalink" href="#CAM_DEBUG_TRACE"><code class="Dv">CAM_DEBUG_TRACE</code></a></dt>
  <dd>This flag enables function-level command flow tracing i.e., kernel printfs
      will happen at the entrance and exit of various functions.</dd>
  <dt id="CAM_DEBUG_SUBTRACE"><a class="permalink" href="#CAM_DEBUG_SUBTRACE"><code class="Dv">CAM_DEBUG_SUBTRACE</code></a></dt>
  <dd>This flag enables debugging output internal to various functions.</dd>
  <dt id="CAM_DEBUG_CDB"><a class="permalink" href="#CAM_DEBUG_CDB"><code class="Dv">CAM_DEBUG_CDB</code></a></dt>
  <dd>This flag will cause the kernel to print out all ATA and SCSI commands
      sent to a particular device or devices.</dd>
  <dt id="CAM_DEBUG_XPT"><a class="permalink" href="#CAM_DEBUG_XPT"><code class="Dv">CAM_DEBUG_XPT</code></a></dt>
  <dd>This flag will enable command scheduler tracing.</dd>
  <dt id="CAM_DEBUG_PERIPH"><a class="permalink" href="#CAM_DEBUG_PERIPH"><code class="Dv">CAM_DEBUG_PERIPH</code></a></dt>
  <dd>This flag will enable peripheral drivers messages.</dd>
  <dt id="CAM_DEBUG_PROBE"><a class="permalink" href="#CAM_DEBUG_PROBE"><code class="Dv">CAM_DEBUG_PROBE</code></a></dt>
  <dd>This flag will enable devices probe process tracing.</dd>
</dl>
<p class="Pp">Some of these flags, most notably
    <code class="Dv">CAM_DEBUG_TRACE</code> and
    <code class="Dv">CAM_DEBUG_SUBTRACE</code>, will produce kernel printfs in
    EXTREME numbers.</p>
<p class="Pp">Users can enable debugging from their kernel config file, by using
    the following kernel config options:</p>
<dl class="Bl-tag">
  <dt id="CAMDEBUG~2"><a class="permalink" href="#CAMDEBUG~2"><code class="Dv">CAMDEBUG</code></a></dt>
  <dd>This builds into the kernel all possible <code class="Nm">CAM</code>
      debugging.</dd>
  <dt id="CAM_DEBUG_COMPILE"><a class="permalink" href="#CAM_DEBUG_COMPILE"><code class="Dv">CAM_DEBUG_COMPILE</code></a></dt>
  <dd>This specifies support for which debugging flags described above should be
      built into the kernel. Flags may be ORed together if the user wishes to
      see printfs for multiple debugging levels.</dd>
  <dt id="CAM_DEBUG_FLAGS"><a class="permalink" href="#CAM_DEBUG_FLAGS"><code class="Dv">CAM_DEBUG_FLAGS</code></a></dt>
  <dd>This sets the various debugging flags from a kernel config file.</dd>
  <dt id="CAM_DEBUG_BUS"><a class="permalink" href="#CAM_DEBUG_BUS"><code class="Dv">CAM_DEBUG_BUS</code></a></dt>
  <dd>Specify a bus to debug. To debug all buses, set this to -1.</dd>
  <dt id="CAM_DEBUG_TARGET"><a class="permalink" href="#CAM_DEBUG_TARGET"><code class="Dv">CAM_DEBUG_TARGET</code></a></dt>
  <dd>Specify a target to debug. To debug all targets, set this to -1.</dd>
  <dt id="CAM_DEBUG_LUN"><a class="permalink" href="#CAM_DEBUG_LUN"><code class="Dv">CAM_DEBUG_LUN</code></a></dt>
  <dd>Specify a lun to debug. To debug all luns, set this to -1.</dd>
</dl>
<p class="Pp">Users may also enable debugging on the fly by using the
    <a class="Xr">camcontrol(8)</a> utility, if wanted options built into the
    kernel. See <a class="Xr">camcontrol(8)</a> for details.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
  ALSO</a></h1>
<dl class="Bl-tag">
  <dt id="Commands:"><a class="permalink" href="#Commands:"><b class="Sy">Commands:</b></a></dt>
  <dd><a class="Xr">camcontrol(8)</a>, <a class="Xr">camdd(8)</a></dd>
  <dt id="Libraries:"><a class="permalink" href="#Libraries:"><b class="Sy">Libraries:</b></a></dt>
  <dd><a class="Xr">cam(3)</a></dd>
  <dt id="Periph"><a class="permalink" href="#Periph"><b class="Sy">Periph
    Drivers:</b></a></dt>
  <dd><a class="Xr">ada(4)</a>, <a class="Xr">da(4)</a>,
      <a class="Xr">nda(4)</a>, <a class="Xr">pass(4)</a>,
      <a class="Xr">sa(4)</a></dd>
  <dt id="SIM"><a class="permalink" href="#SIM"><b class="Sy">SIM
    Devices:</b></a></dt>
  <dd><a class="Xr">aac(4)</a>, <a class="Xr">aacraid(4)</a>,
      <a class="Xr">ahc(4)</a>, <a class="Xr">ahci(4)</a>,
      <a class="Xr">ata(4)</a>, <a class="Xr">aw_mmc(4)</a>,
      <a class="Xr">ciss(4)</a>, <a class="Xr">hv_storvsc(4)</a>,
      <a class="Xr">isci(4)</a>, <a class="Xr">iscsi(4)</a>,
      <a class="Xr">isp(4)</a>, <a class="Xr">mpr(4)</a>,
      <a class="Xr">mps(4)</a>, <a class="Xr">mpt(4)</a>,
      <a class="Xr">mrsas(4)</a>, <a class="Xr">mvs(4)</a>,
      <a class="Xr">nvme(4)</a>, <a class="Xr">pms(4)</a>,
      <a class="Xr">pvscsi(4)</a>, <a class="Xr">sdhci(4)</a>,
      <a class="Xr">smartpqi(4)</a>, <a class="Xr">sym(4)</a>,
      <a class="Xr">tws(4)</a>, <a class="Xr">umass(4)</a>,
      <a class="Xr">virtio_scsi(4)</a></dd>
  <dt id="Deprecated"><a class="permalink" href="#Deprecated"><b class="Sy">Deprecated
    or Poorly Supported SIM Devices:</b></a></dt>
  <dd><a class="Xr">ahd(4)</a>, <a class="Xr">amr(4)</a>,
      <a class="Xr">arcmsr(4)</a>, <a class="Xr">esp(4)</a>,
      <a class="Xr">hpt27xx(4)</a>, <a class="Xr">hptiop(4)</a>,
      <a class="Xr">hptmv(4)</a>, <a class="Xr">hptnr(4)</a>,
      <a class="Xr">iir(4)</a> <a class="Xr">mfi(4)</a>,
      <a class="Xr">sbp(4)</a>, <a class="Xr">twa(4)</a></dd>
</dl>
</section>
<section class="Sh">
<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1>
<p class="Pp">The <code class="Nm">CAM</code> SCSI subsystem first appeared in
    <span class="Ux">FreeBSD 3.0</span>. The <code class="Nm">CAM</code> ATA
    support was added in <span class="Ux">FreeBSD 8.0</span>.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1>
<p class="Pp">The <code class="Nm">CAM</code> SCSI subsystem was written by
    <span class="An">Justin Gibbs</span> and <span class="An">Kenneth
    Merry</span>. The <code class="Nm">CAM</code> ATA support was added by
    <span class="An">Alexander Motin</span>
    &lt;<a class="Mt" href="mailto:mav@FreeBSD.org">mav@FreeBSD.org</a>&gt;. The
    <code class="Nm">CAM</code> NVMe support was added by
    <span class="An">Warner Losh</span>
    &lt;<a class="Mt" href="mailto:imp@FreeBSD.org">imp@FreeBSD.org</a>&gt;.</p>
</section>
</div>
<table class="foot">
  <tr>
    <td class="foot-date">December 11, 2025</td>
    <td class="foot-os">FreeBSD 15.0</td>
  </tr>
</table>