Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
CAM(4)			    Kernel Interfaces Manual			CAM(4)

NAME
       CAM -- Common Access Method SCSI/ATA subsystem

SYNOPSIS
       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

DESCRIPTION
       The  CAM	subsystem provides a uniform and modular system	for the	imple-
       mentation of drivers to control various SCSI and	ATA  devices,  and  to
       utilize	different SCSI and ATA host adapters through host adapter dri-
       vers.  When the system probes busses, 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.

KERNEL CONFIGURATION
       There  are a number of generic kernel configuration options for the CAM
       subsystem:

       CAMDEBUG		      This option compiles in all  the	CAM  debugging
			      printf  code.   This will	not actually cause any
			      debugging	information to be printed out when in-
			      cluded by	itself.	 See below for details.

       CAM_MAX_HIGHPOWER=4    This sets	the maximum allowable number  of  con-
			      current  "high  power" commands.	A "high	power"
			      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.

       SCSI_NO_SENSE_STRINGS  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 nec-
			      essary 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  mes-
			      sages.   Do  not	let the	"kernel	bloat" zealots
			      get to you -- leave the  sense  descriptions  in
			      your kernel!

       SCSI_NO_OP_STRINGS     This disables text descriptions of each SCSI op-
			      code.  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  rec-
			      ommended,	since it slows debugging of SCSI prob-
			      lems.

       SCSI_DELAY=8000	      This is the SCSI "bus settle delay."  In 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 mini-
			      mum 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 busses support dynamic allocation so that an upper num-
       ber  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 usu-
       ally 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 con-
       trollers	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  dri-
       vers 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 com-
       bined together to allow a peripheral device to be wired to any particu-
       lar controller, bus, target, and/or unit	instance.

       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.

ADAPTERS
       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 or ATA 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.

TARGET MODE
       Some adapters support target mode in which the system is	capable	of op-
       erating as a device, responding to operations initiated by another sys-
       tem.   Target  mode is supported	for some adapters, but is not yet com-
       plete for this version of the CAM SCSI subsystem.

FILES
       see other CAM device entries.

DIAGNOSTICS
       An XPT_DEBUG CCB	can be used to enable various amounts of  tracing  in-
       formation  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	   This	flag enables general informational printfs for
			   the device or devices in question.

       CAM_DEBUG_TRACE	   This	flag enables function-level command flow trac-
			   ing.	 i.e. kernel printfs will happen  at  the  en-
			   trance and exit of various functions.

       CAM_DEBUG_SUBTRACE  This	flag enables debugging output internal to var-
			   ious	functions.

       CAM_DEBUG_CDB	   This	 flag  will  cause the kernel to print out all
			   ATA and SCSI	commands sent to a  particular	device
			   or devices.

       CAM_DEBUG_XPT	   This	flag will enable command scheduler tracing.

       CAM_DEBUG_PERIPH	   This	flag will enable peripheral drivers messages.

       CAM_DEBUG_PROBE	   This	 flag  will enable devices probe process trac-
			   ing.

       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		  This builds into the kernel all possible CAM	debug-
			  ging.

       CAM_DEBUG_COMPILE  This	allows	to specify support for which debugging
			  flags	described above	should be built	into the  ker-
			  nel.	 Flags may be ORed together if the user	wishes
			  to see printfs for multiple debugging	levels.

       CAM_DEBUG_FLAGS	  This allows to set the various debugging flags  from
			  a kernel config file.

       CAM_DEBUG_BUS	  Specify  a  bus  to debug.  To debug all busses, set
			  this to -1.

       CAM_DEBUG_TARGET	  Specify a target to debug.  To  debug	 all  targets,
			  set this to -1.

       CAM_DEBUG_LUN	  Specify a lun	to debug.  To debug all	luns, set this
			  to -1.

       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.

SEE ALSO
       ada(4),	aha(4),	 ahb(4), ahc(4), ahci(4), ata(4), bt(4), cd(4),	ch(4),
       da(4), pass(4), pt(4), sa(4), xpt(4), camcontrol(8)

HISTORY
       The CAM SCSI subsystem first appeared in	FreeBSD	3.0.  The CAM ATA sup-
       port was	added in FreeBSD 8.0.

AUTHORS
       The CAM SCSI subsystem was written by Justin Gibbs and  Kenneth	Merry.
       The CAM ATA support was added by	Alexander Motin	<mav@FreeBSD.org>.

FreeBSD	9.3			 June 7, 2012				CAM(4)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=cam&sektion=4&manpath=FreeBSD+9.3-RELEASE>

home | help