CAM(4) | Device Drivers Manual | CAM(4) |
CAM
— Common
Access Method Storage subsystem
device scbus
device ada
device cd
device ch
device da
device pass
device pt
device sa
options CAMDEBUG
options CAM_DEBUG_BUS=-1
options CAM_DEBUG_TARGET=-1
options CAM_DEBUG_LUN=-1
options
CAM_DEBUG_COMPILE=CAM_DEBUG_INFO|CAM_DEBUG_CDB|CAM_DEBUG_PROBE
options CAM_DEBUG_FLAGS=CAM_DEBUG_INFO|CAM_DEBUG_CDB
options CAM_MAX_HIGHPOWER=4
options SCSI_NO_SENSE_STRINGS
options SCSI_NO_OP_STRINGS
options SCSI_DELAY=8000
The CAM
subsystem provides a uniform and
modular system for the implementation of drivers to control various SCSI,
ATA, NMVe, 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 pass(4) driver, if it is configured in the kernel,
will attach to all devices.
There are a number of generic kernel configuration options for the
CAM
subsystem:
CAMDEBUG
CAM
debugging
printf code. This will not actually cause any debugging information to be
printed out when included by itself. See below for details.CAM_MAX_HIGHPOWER=4
SCSI_NO_SENSE_STRINGS
SCSI_NO_OP_STRINGS
SCSI_DELAY=8000
CAM
, it is specified in
milliseconds,
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 SCSI_DELAY
is not specified, it defaults to
2 seconds. The minimum allowable value for
SCSI_DELAY
is "100", or 100ms. One
special case is that if the SCSI_DELAY
is set to
0, that will be taken to mean the "lowest possible value." In
that case, the SCSI_DELAY
will be reset to
100ms.All devices and buses support dynamic allocation so that an upper
number of devices and controllers does not need to be configured;
device da
will suffice for any number of disk
drivers.
The devices are either wired so they appear as a particular device unit or counted so that they appear as the next available unused unit.
Units are wired down by setting kernel environment hints. This is usually done either interactively from the loader(8), or automatically via the /boot/device.hints file. The basic syntax is:
hint.device.unit.property="value"
Individual CAM
bus numbers can be wired
down to specific controllers with a config line similar to the
following:
hint.scbus.0.at="ahd1"
This assigns CAM
bus number 0 to
the ahd1 driver
instance. For controllers supporting more than one bus, a particular bus can
be assigned as follows:
hint.scbus.0.at="ahc1" hint.scbus.0.bus="1"
This assigns CAM
bus 0 to the
bus 1 instance on
ahc1. Peripheral
drivers can be wired to a specific bus, target, and lun as so:
hint.da.0.at="scbus0" hint.da.0.target="0" hint.da.0.unit="0"
This assigns
da0 to target 0, unit
(lun) 0 of scbus 0. Omitting the target or unit hints will instruct
CAM
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.
This also works with nvme(4) drives as well.
hint.nvme.4.at="pci7:0:0" hint.scbus.10.at="nvme4" hint.nda.10.at="scbus10" hint.nda.10.target="1" hint.nda.10.unit="12" hint.nda.11.at="scbus10" hint.nda.11.target="1" hint.nda.11.unit="2"
This assigns the NVMe card living at PCI bus 7 to scbus 10 (in PCIe, slot and function are rarely used and usually 0). The target for nda(4) devices is always 1. The unit is the namespace identifier from the drive. The namespace id 1 is exported as nda10 and namespace id 2 is exported as nda11.
When you have a mixture of wired down and counted devices then the counting begins with the first non-wired down unit for a particular type. That is, if you have a disk wired down as device da1, then the first non-wired disk shall come on line as da2.
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 64KB in a single operation, however many can transfer larger amounts.
Some adapters support
target
mode 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
CAM
SCSI subsystem.
see other CAM
device entries.
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:
CAM_DEBUG_INFO
CAM_DEBUG_TRACE
CAM_DEBUG_SUBTRACE
CAM_DEBUG_CDB
CAM_DEBUG_XPT
CAM_DEBUG_PERIPH
CAM_DEBUG_PROBE
Some of these flags, most notably
CAM_DEBUG_TRACE
and
CAM_DEBUG_SUBTRACE
, will produce kernel printfs in
EXTREME numbers.
Users can enable debugging from their kernel config file, by using the following kernel config options:
CAMDEBUG
CAM
debugging.CAM_DEBUG_COMPILE
CAM_DEBUG_FLAGS
CAM_DEBUG_BUS
CAM_DEBUG_TARGET
CAM_DEBUG_LUN
Users may also enable debugging on the fly by using the camcontrol(8) utility, if wanted options built into the kernel. See camcontrol(8) for details.
ada(4), aha(4), ahc(4), ahci(4), ahd(4), ata(4), bt(4), cd(4), ch(4), da(4), nda(4), nvme(4), pass(4), pt(4), sa(4), xpt(4), camcontrol(8)
The CAM
SCSI subsystem first appeared in
FreeBSD 3.0. The CAM
ATA
support was added in FreeBSD 8.0.
The CAM
SCSI subsystem was written by
Justin Gibbs and Kenneth
Merry. The CAM
ATA support was added by
Alexander Motin
<mav@FreeBSD.org>. The
CAM
NVMe support was added by
Warner Losh
<imp@FreeBSD.org>.
December 20, 2017 | Debian |