CAM(4) 맨 페이지 - 윈디하나의 솔라나라

개요

섹션
맨 페이지 이름
검색(S)

CAM(4)

The  subsystem  provides a uniform and modular system for the im‐
plementation of drivers to control various and  devices,  and  to
utilize different and host adapters through host adapter drivers.
When the system probes buses, it attaches any devices it finds to
the  appropriate drivers.  The driver, if it is configured in the
kernel, will attach to  all  devices.   There  are  a  number  of
generic  kernel configuration options for the subsystem: This op‐
tion compiles in all the debugging printf code.   This  will  not
actually  cause  any debugging information to be printed out when
included by itself.  See below for details.  This sets the  maxi‐
mum  allowable  number  of  concurrent  "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 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.
This  eliminates  text descriptions of each Additional Sense Code
and Additional Sense Code Qualifier pair.  Since this is a fairly
large text database, eliminating it reduces the size of the  ker‐
nel  somewhat.  This is primarily necessary 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 inter‐
pretation  of  error  messages.   Do  not  let the "kernel bloat"
zealots get to you -- leave the sense descriptions in  your  ker‐
nel!   This  disables text descriptions of each opcode.  This op‐
tion, 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 recommended, since it
slows debugging of problems.  This is the "bus settle delay."  In
it is specified in not seconds like the old  layer  used  to  do.
When  the  kernel boots, it sends a bus reset to each bus to tell
each device to reset itself to a default set of transfer negotia‐
tions and other settings.  Most 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  is
not  specified,  it defaults to 2 seconds.  The minimum allowable
value for is "100", or 100ms.  One special case is that if the is
set to 0, that will be taken to mean the "lowest possible value."
In that case, the 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; will suffice for any
number of disk drivers.  The devices are either so they appear as
a particular device unit or 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  or  automatically  via the file.  The basic syntax is:
hint.device.unit.property="value" Individual bus numbers  can  be
wired  down to specific controllers with a config line similar to
the following: hint.scbus.0.at="ahd1" This assigns bus  number  0
to the 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 bus 0 to
the bus 1 instance on Peripheral drivers can be wired to  a  spe‐
cific   bus,   target,   and  lun  as  so:  hint.da.0.at="scbus0"
hint.da.0.target="0" hint.da.0.unit="0" This assigns to target 0,
unit (lun) 0 of scbus 0.  Omitting the target or unit hints  will
instruct  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 con‐
troller, bus, target, and/or unit instance.  This also works with
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 devices is always 1.  The unit is the
namespace  identifier  from the drive.  The namespace id 1 is ex‐
ported as and namespace id 2 is exported as When you have a  mix‐
ture  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 then the first non-wired
disk shall come on line as The system allows common  device  dri‐
vers  to  work  through  many  different  types of adapters.  The
adapters take requests from the upper layers and do  all  IO  be‐
tween  the or 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 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 com‐
plete for this version of the subsystem.  see  other  device  en‐
tries.  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  de‐
bugging flags that may be compiled in and used: This flag enables
general  informational printfs for the device or devices in ques‐
tion.  This flag  enables  function-level  command  flow  tracing
i.e., kernel printfs will happen at the entrance and exit of var‐
ious  functions.   This flag enables debugging output internal to
various functions.  This flag will cause the kernel to print  out
all  and  commands  sent to a particular device or devices.  This
flag will enable command scheduler tracing.  This flag  will  en‐
able  peripheral drivers messages.  This flag will enable devices
probe process tracing.  Some of these  flags,  most  notably  and
will produce kernel printfs in EXTREME numbers.  Users can enable
debugging  from  their kernel config file, by using the following
kernel config options: This builds into the kernel  all  possible
debugging.   This  allows  to specify support for which debugging
flags described above should be built into the kernel.  Flags may
be ORed together if the user wishes to see printfs  for  multiple
debugging levels.  This allows to set the various debugging flags
from a kernel config file.  Specify a bus to debug.  To debug all
buses,  set this to -1.  Specify a target to debug.  To debug all
targets, set this to -1.  Specify a lun to debug.  To  debug  all
luns, set this to -1.  Users may also enable debugging on the fly
by  using  the  utility, if wanted options built into the kernel.
See for details.  The subsystem first appeared in The ATA support
was added in The subsystem was written by  and  The  support  was
added by The support was added by





















맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 5 CSS3