xref: /src/share/man/man4/scsi.4 (revision b1bebaaba9b9c0ddfe503c43ca8e9e3917ee2c57)
1.\" Copyright (c) 1996
2.\"	Julian Elischer <julian@FreeBSD.org>.  All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\"    notice, this list of conditions and the following disclaimer.
9.\"
10.\" 2. Redistributions in binary form must reproduce the above copyright
11.\"    notice, this list of conditions and the following disclaimer in the
12.\"    documentation and/or other materials provided with the distribution.
13.\"
14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
17.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
24.\" SUCH DAMAGE.
25.Dd December 11, 2025
26.Dt CAM 4
27.Os
28.Sh NAME
29.Nm CAM
30.Nd Common Access Method Storage subsystem
31.Sh SYNOPSIS
32.Cd "device scbus"
33.Cd "device ada"
34.Cd "device cd"
35.Cd "device ch"
36.Cd "device da"
37.Cd "device pass"
38.Cd "device pt"
39.Cd "device sa"
40.Cd "options CAMDEBUG"
41.Cd "options CAM_DEBUG_BUS=-1"
42.Cd "options CAM_DEBUG_TARGET=-1"
43.Cd "options CAM_DEBUG_LUN=-1"
44.Cd "options CAM_DEBUG_COMPILE=CAM_DEBUG_INFO|CAM_DEBUG_CDB|CAM_DEBUG_PROBE"
45.Cd "options CAM_DEBUG_FLAGS=CAM_DEBUG_INFO|CAM_DEBUG_CDB"
46.Cd "options CAM_MAX_HIGHPOWER=4"
47.Cd "options SCSI_NO_SENSE_STRINGS"
48.Cd "options SCSI_NO_OP_STRINGS"
49.Cd "options SCSI_DELAY=8000"
50.Sh DESCRIPTION
51The
52.Nm
53subsystem provides a uniform and modular system for the implementation
54of drivers to control various
55.Tn SCSI ,
56.Tn ATA ,
57.Tn NVMe ,
58and
59.Tn MMC / SD
60devices, and to utilize different
61.Tn SCSI ,
62.Tn ATA ,
63.Tn NVMe ,
64and
65.Tn MMC / SD
66host adapters through host adapter drivers.
67When the system probes buses, it attaches any devices it finds to the
68appropriate drivers.
69The
70.Xr pass 4
71driver, if it is configured in the kernel, will attach to all devices.
72.Sh SYSCTL VARIABLES
73The following variables are available as both
74.Xr sysctl 8
75variables and
76.Xr loader 8
77tunables:
78.Bl -tag -width 12
79.It Va kern.cam.cam_srch_hi
80Search above LUN 7 for SCSI3 and greater devices.
81.It Va kern.cam.tur_timeout
82Timeout, in ms, for the initial TESTUNITREADY command we send to the devices
83during their initial probing.
84Defaults to 1s.
85.Fx 15
86and earlier set this to 60s.
87.It Va kern.cam.inquiry_timeout
88Timeout, in ms, for the initial INQUIRY command we send to the devices
89during their initial probing.
90Defaults to 1s.
91.Fx 15
92and earlier set this to 60s.
93.It Va kern.cam.reportluns_timeout
94Timeout, in ms, for the initial REPORTLUNS command we send to the devices
95during their initial probing.
96Defaults to 50s.
97.It Va kern.cam.modesense_timeout
98Timeout, in ms, for the initial MODESENSE command we send to the devices
99during their initial probing.
100Defaults to 1s.
101.Fx 15
102and earlier set this to 60s.
103.El
104.Sh KERNEL CONFIGURATION
105There are a number of generic kernel configuration options for the
106.Nm
107subsystem:
108.Bl -tag -width SCSI_NO_SENSE_STRINGS
109.It Dv CAM_BOOT_DELAY
110Additional time to wait after the static parts of the kernel have run to allow
111for discovery of additional devices which may take time to connect,
112such as USB attached storage.
113.It Dv CAM_IOSCHED_DYNAMIC
114Enable dynamic decisions in the I/O scheduler based on hints and the current
115performance of the storage devices.
116.It Dv CAM_IO_STATS
117Enable collection of statistics for periph devices.
118.It Dv CAM_TEST_FAILURE
119Enable ability to simulate I/O failures.
120.It Dv CAMDEBUG
121This option compiles in all the
122.Nm
123debugging printf code.
124This will not actually
125cause any debugging information to be printed out when included by itself.
126See below for details.
127.It Dv "CAM_MAX_HIGHPOWER=4"
128This sets the maximum allowable number of concurrent "high power" commands.
129A "high power" command is a command that takes more electrical power than
130most to complete.
131An example of this is the
132.Tn SCSI
133START UNIT command.
134Starting a disk often takes significantly more electrical power than normal
135operation.
136This option allows the
137user to specify how many concurrent high power commands may be outstanding
138without overloading the power supply on his computer.
139.It Dv SCSI_NO_SENSE_STRINGS
140This eliminates text descriptions of each
141.Tn SCSI
142Additional Sense Code and Additional Sense Code Qualifier pair.
143Since this
144is a fairly large text database, eliminating it reduces the size of the
145kernel somewhat.
146This is primarily necessary for boot floppies and other
147low disk space or low memory space environments.
148In most cases, though,
149this should be enabled, since it speeds the interpretation of
150.Tn SCSI
151error messages.
152Do not let the "kernel bloat" zealots get to you -- leave
153the sense descriptions in your kernel!
154.It Dv SCSI_NO_OP_STRINGS
155This disables text descriptions of each
156.Tn SCSI
157opcode.
158This option, like the sense string option above, is primarily
159useful for environments like a boot floppy where kernel size is critical.
160Enabling this option for normal use is not recommended, since it slows
161debugging of
162.Tn SCSI
163problems.
164.It Dv SCSI_DELAY=8000
165This is the
166.Tn SCSI
167"bus settle delay."
168In
169.Nm ,
170it is specified in
171.Em milliseconds ,
172not seconds like the old
173.Tn SCSI
174layer used to do.
175When the kernel boots, it sends a bus reset to each
176.Tn SCSI
177bus to tell each device to reset itself to a default set of transfer
178negotiations and other settings.
179Most
180.Tn SCSI
181devices need some amount of time to recover from a bus reset.
182Newer disks
183may need as little as 100ms, while old, slow devices may need much longer.
184If the
185.Dv SCSI_DELAY
186is not specified, it defaults to 2 seconds.
187The minimum allowable value for
188.Dv SCSI_DELAY
189is "100", or 100ms.
190One special case is that if the
191.Dv SCSI_DELAY
192is set to 0, that will be taken to mean the "lowest possible value."
193In that case, the
194.Dv SCSI_DELAY
195will be reset to 100ms.
196.El
197.Pp
198All devices and buses support dynamic allocation so that
199an upper number of devices and controllers does not need to be configured;
200.Cd "device da"
201will suffice for any number of disk drivers.
202.Pp
203The devices are either
204.Em wired
205so they appear as a particular device unit or
206.Em counted
207so that they appear as the next available unused unit.
208.Pp
209Units are wired down by setting kernel environment hints.
210This is usually done either interactively from the
211.Xr loader 8 ,
212or automatically via the
213.Pa /boot/device.hints
214file.
215The basic syntax is:
216.Bd -literal -offset indent
217hint.device.unit.property="value"
218.Ed
219.Pp
220Individual
221.Nm
222bus numbers can be wired down to specific controllers with
223a config line similar to the following:
224.Bd -literal -offset indent
225hint.scbus.0.at="mpr1"
226.Ed
227.Pp
228This assigns
229.Nm
230bus number 0 to the
231.Em mpr1
232driver instance.
233For controllers supporting more than one bus, a particular bus can be assigned
234as follows:
235.Bd -literal -offset indent
236hint.scbus.0.at="ahci1"
237hint.scbus.0.bus="1"
238.Ed
239.Pp
240This assigns
241.Nm
242bus 0 to the bus 1 instance on
243.Em ahci1 .
244Peripheral drivers can be wired to a specific bus, target, and lun as so:
245.Bd -literal -offset indent
246hint.da.0.at="scbus0"
247hint.da.0.target="0"
248hint.da.0.lun="0"
249.Ed
250.Pp
251This assigns
252.Em da0
253to target 0, unit (lun) 0 of scbus 0.
254Omitting the target or unit hints will instruct
255.Nm
256to treat them as wildcards
257and use the first respective counted instances.
258These examples can be combined together to allow a peripheral device to be
259wired to any particular controller, bus, target, and/or unit instance.
260.Pp
261This also works with
262.Xr nvme 4
263drives.
264.Bd -literal -offset indent
265hint.nvme.4.at="pci7:0:0"
266hint.scbus.10.at="nvme4"
267hint.nda.10.at="scbus10"
268hint.nda.10.target="1"
269hint.nda.10.lun="12"
270hint.nda.11.at="scbus10"
271hint.nda.11.target="1"
272hint.nda.11.lun="2"
273.Ed
274.Pp
275This assigns the NVMe card at PCI bus 7 slot 0 function 1 to scbus 10.
276The target for
277.Xr nda 4
278devices is always 1.
279The unit is the namespace identifier from the drive.
280The namespace id 1 is exported as
281.Em nda10
282and namespace id 2 is exported as
283.Em nda11 .
284.Pp
285For devices that provide a serial number, units may be wired to that serial
286number without regard where the drive is attached:
287.Bd -literal -offset indent
288hint.nda.3.sn="CY0AN07101120B12P"
289hint.da.44.sn="143282400011"
290hint.ada.2.sn="A065D591"
291.Ed
292wires
293.Em nda3 ,
294.Em da44 ,
295and
296.Em ada2
297to drives with the specified serial numbers.
298One need not specify an
299.Em at
300line when serial numbers are used.
301.Sh ADAPTERS
302The system allows common device drivers to work through many different
303types of adapters.
304The adapters take requests from the upper layers and do
305all IO between the
306.Tn SCSI ,
307.Tn ATA ,
308.Tn NVMe ,
309or
310.Tn MMC / SD
311bus and the system.
312The maximum size of a transfer is governed by the
313adapter.
314Most adapters can transfer 1MB in a single operation, however
315many can transfer larger amounts.
316.Sh TARGET MODE
317Some adapters support
318.Em target mode
319in which the system is capable of operating as a device, responding to
320operations initiated by another system.
321Target mode is supported for
322some adapters, but is not yet complete for this version of the
323.Nm
324.Tn SCSI
325subsystem.
326.Sh ARCHITECTURE
327The
328.Nm
329subsystem glues together the upper layers of the system to the storage devices.
330PERIPH devices accept storage requests from GEOM and other upper layers of the
331system and translates them into protocol requests.
332XPT (transport) dispatches these protocol requests to a SIM driver.
333A SIM driver takes protocol requests and translates them into hardware commands
334the host adapter understands to transfer the protocol requests, and data (if
335any) to the storage device.
336The CCB transports these requests around as messages.
337.Ss CAM
338The Common Access Method was a standard defined in the 1990s to talk to disk
339drives.
340.Fx
341is one of the few operating systems to fully implement this model.
342The interface between different parts of CAM is the CCB (or CAM Control Block).
343Each CCB has a standard header, which contains the type of request and dispatch
344information, and a command specific portion.
345A CAM Periph generates requests.
346The XPT layer dispatches these requests to the appropriate SIM.
347Some CCBs are sent directly to the SIM for immediate processing, while others
348are queued and complete when the I/O has finished.
349A SIM takes CCBs and translates them into hardware specific commands to push the
350SCSI CDB or other protocol control block to the peripheral, along with setting
351up the DMA for the associated data.
352.Ss Periph Devices
353A periph driver knows how to translate standard requests into protocol messages
354that a SIM can deliver to hardware.
355These requests can come from any upper layer source, but primarily come in via
356GEOM as a bio request.
357They can also come in directly from character device requests for tapes and pass
358through commands.
359.Pp
360Disk devices, or direct access (da) in CAM, are one type of peripheral.
361These devices present themselves to the kernel a device ending in
362.Dq da .
363Each protocol has a unique device name:
364.Bl -tag -width 4
365.It Xr da 4
366SCSI or SAS device, or devices that accept SCSI CDBs for I/O.
367.It Xr ada 4
368ATA or SATA device
369.It Xr nda 4
370NVME device
371.It Xr sdda 4
372An SD or MMC block storage device.
373.El
374.Pp
375Tape devices are called serial access
376.Po
377.Xr sa 4
378.Pc
379in CAM.
380They interface to the system via a character device and provide
381.Xr ioctl 2
382control for tape drives.
383.Pp
384The
385.Xr pass 4
386device will pass through CCB requests from userland to the SIM directly.
387The device is used to send commands other than read, write, trim or flush to a
388device.
389The
390.Xr camcontrol 8
391command uses this device.
392.Ss XPT drivers
393The transport driver connects the periph to the SIM.
394It is not configured separately.
395It is also responsible for device discovery for those SIM drivers that do not
396enumerate themselves.
397.Ss SIM driver
398SIM used to stand for SCSI Interface Module.
399Now it is just SIM because it understands protocols other than SCSI.
400There are two types of SIM drivers: virtual and physical.
401Physical SIMs are typically called host bus adapters (HBA), but not universally.
402Virtual SIM drivers are for communicating with network or virtual machine hosts.
403.Sh FILES
404see other
405.Nm
406device entries.
407.Sh DIAGNOSTICS
408An XPT_DEBUG CCB can be used to enable various amounts of tracing information
409on any specific bus/device from the list of options compiled into the kernel.
410There are currently seven debugging flags that may be compiled in and used:
411.Bl -tag -width CAM_DEBUG_SUBTRACE
412.It Dv CAM_DEBUG_INFO
413This flag enables general informational printfs for the device
414or devices in question.
415.It Dv CAM_DEBUG_TRACE
416This flag enables function-level command flow tracing i.e.,
417kernel printfs will happen at the entrance and exit of various functions.
418.It Dv CAM_DEBUG_SUBTRACE
419This flag enables debugging output internal to various functions.
420.It Dv CAM_DEBUG_CDB
421This flag will cause the kernel to print out all
422.Tn ATA
423and
424.Tn SCSI
425commands sent to a particular device or devices.
426.It Dv CAM_DEBUG_XPT
427This flag will enable command scheduler tracing.
428.It Dv CAM_DEBUG_PERIPH
429This flag will enable peripheral drivers messages.
430.It Dv CAM_DEBUG_PROBE
431This flag will enable devices probe process tracing.
432.El
433.Pp
434Some of these flags, most notably
435.Dv CAM_DEBUG_TRACE
436and
437.Dv CAM_DEBUG_SUBTRACE ,
438will produce kernel printfs in EXTREME numbers.
439.Pp
440Users can enable debugging from their kernel config file, by using
441the following kernel config options:
442.Bl -tag -width CAM_DEBUG_COMPILE
443.It Dv CAMDEBUG
444This builds into the kernel all possible
445.Nm
446debugging.
447.It Dv CAM_DEBUG_COMPILE
448This specifies support for which debugging flags described above
449should be built into the kernel.
450Flags may be ORed together if the user wishes to
451see printfs for multiple debugging levels.
452.It Dv CAM_DEBUG_FLAGS
453This sets the various debugging flags from a kernel config file.
454.It Dv CAM_DEBUG_BUS
455Specify a bus to debug.
456To debug all buses, set this to -1.
457.It Dv CAM_DEBUG_TARGET
458Specify a target to debug.
459To debug all targets, set this to -1.
460.It Dv CAM_DEBUG_LUN
461Specify a lun to debug.
462To debug all luns, set this to -1.
463.El
464.Pp
465Users may also enable debugging on the fly by using the
466.Xr camcontrol 8
467utility, if wanted options built into the kernel.
468See
469.Xr camcontrol 8
470for details.
471.Sh SEE ALSO
472.Bl -tag -width 20
473.It Sy Commands:
474.Xr camcontrol 8 ,
475.Xr camdd 8
476.It Sy Libraries:
477.Xr cam 3
478.It Sy Periph Drivers:
479.Xr ada 4 ,
480.Xr da 4 ,
481.Xr nda 4 ,
482.\" .Xr sdda 4 ,
483.Xr pass 4 ,
484.Xr sa 4
485.It Sy SIM Devices:
486.Xr aac 4 ,
487.Xr aacraid 4 ,
488.Xr ahc 4 ,
489.Xr ahci 4 ,
490.Xr ata 4 ,
491.Xr aw_mmc 4 ,
492.Xr ciss 4 ,
493.Xr hv_storvsc 4 ,
494.Xr isci 4 ,
495.Xr iscsi 4 ,
496.Xr isp 4 ,
497.\" .Xr mmcnull 4 ,
498.Xr mpr 4 ,
499.Xr mps 4 ,
500.Xr mpt 4 ,
501.Xr mrsas 4 ,
502.Xr mvs 4 ,
503.Xr nvme 4 ,
504.Xr pms 4 ,
505.Xr pvscsi 4 ,
506.Xr sdhci 4 ,
507.Xr smartpqi 4 ,
508.Xr sym 4 ,
509.Xr tws 4 ,
510.Xr umass 4 ,
511.Xr virtio_scsi 4
512.It Sy Deprecated or Poorly Supported SIM Devices:
513.Xr ahd 4 ,
514.Xr amr 4 ,
515.Xr arcmsr 4 ,
516.Xr esp 4 ,
517.\" .Xr fslsata 4 ,
518.Xr hpt27xx 4 ,
519.Xr hptiop 4 ,
520.Xr hptmv 4 ,
521.Xr hptnr 4 ,
522.\" .Xr htprr 4 ,
523.Xr iir 4
524.Xr mfi 4 ,
525.\" .Xr osc 4 ,
526.\" .Xr ps3cdrom 4 ,
527.Xr sbp 4 ,
528.Xr twa 4
529.El
530.Sh HISTORY
531The
532.Nm
533.Tn SCSI
534subsystem first appeared in
535.Fx 3.0 .
536The
537.Nm
538ATA support was added in
539.Fx 8.0 .
540.Sh AUTHORS
541.An -nosplit
542The
543.Nm
544.Tn SCSI
545subsystem was written by
546.An Justin Gibbs
547and
548.An Kenneth Merry .
549The
550.Nm
551.Tn ATA
552support was added by
553.An Alexander Motin Aq Mt mav@FreeBSD.org .
554The
555.Nm
556.Tn NVMe
557support was added by
558.An Warner Losh Aq Mt imp@FreeBSD.org .
559