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