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