1SMP_UTILS(8)                       SMP_UTILS                      SMP_UTILS(8)
2
3
4

NAME

6       smp_* - invoke a SAS Serial Management Protocol (SMP) function
7

SYNOPSIS

9       smp_*  [--expected=EX]  [--help]  [--hex]  [--interface=PARAMS] [--raw]
10       [--sa=SAS_ADDR] [--verbose] [--version] SMP_DEVICE[,N]
11

DESCRIPTION

13       Serial Attached SCSI (SAS) is a transport (also known  as  a  intercon‐
14       nect)  used  by  storage  systems.  A SAS system is made up of Host Bus
15       Adapters (HBAs typically containing SCSI initiators),  disks  (referred
16       to  in  SCSI  as  both  targets  and logical units) and optionally some
17       switching hardware called "expanders". Expanders are not  SCSI  devices
18       so  a  new  protocol was required to control and monitor them. Its full
19       name is the SAS Serial Management Protocol which is abbreviated to SMP.
20
21       smp_utils is a package of utilities. Each utility sends an SMP function
22       request  to a SMP_DEVICE (an SMP target). Some utilities may invoke the
23       same function more than once. If an error occurs then an error  message
24       is  sent  to  stderr.  If no error occurs, the response is decoded (the
25       default), output in ASCII hex (when --hex is given) or output in binary
26       to stdout (when the --raw option is given).
27
28       If  SMP_DEVICE[,N] is not given then the value in the environment vari‐
29       able SMP_UTILS_DEVICE is used.
30
31       This package was originally written for Linux and has  been  ported  to
32       FreeBSD and Solaris.
33

LINUX INTERFACE

35       Currently  there are multiple interfaces that allow SMP functions to be
36       passed through to an SMP target.
37
38       One method is to have a SMP_DEVICE which is actually the SMP  initiator
39       (e.g.  '/dev/mptctl,0'). In this case the SMP target's SAS address must
40       be supplied with the --sa=SAS_ADDR option.
41
42       Another method is to have a SMP_DEVICE which represents the SMP target.
43       In this case no SAS_ADDRESS needs to be given (since it is implicit).
44
45       Each  utility  in smp_utils attempts to work out which interface it has
46       been given by examining the SMP_DEVICE file. There are three interfaces
47       supported currently:
48
49       aac    This  specifies  the  aacraid  SAS  pass-through associated with
50              Adaptec/PMC RAID products. The SMP_DEVICE[,N] argument takes the
51              form  /dev/aac[N[,E_ID]] where "N" is the raid controller number
52              (typically 0) and "E_ID" is the expander  identifier  (typically
53              0); both default to 0 so /dev/aac is equivalent to /dev/aac0 and
54              /dev/aac0,0   .    The   "N"   is   the   unique_id   found   in
55              /sys/class/scsi_host<HN>/unique_id  .  The "HN" is the host num‐
56              ber which is the first number to appear on each line in the lss‐
57              csi utility which by default uses one line to list each accessi‐
58              ble SCSI device (typically SCSI or ATA disks). The "E_ID" is the
59              expander identifier which can be found with the Adaptec/PMC arc‐
60              conf utility using the form "arcconf  expanderlist  <Controller‐
61              Num>".  The  <ControllerNum>s  start  at 1 . If an aac RAID con‐
62              troller is present then the /dev/acc device node will be created
63              by the first smp utility to use this interface.
64
65       mpt    This  specifies  the  MPT  fusion  SAS  pass-through. The mptsas
66              driver uses the  '/dev/mptctl'  device  node  (character  device
67              major   10,   minor   220)   while   the   mpt2sas  driver  uses
68              '/dev/mpt2ctl' device node  (major  10,  minor  221).   For  the
69              mpt3sas  driver the corresponding device node is '/dev/mpt3ctl'.
70              The 'modprobe mptctl'  or  'modprobe  mpt2ctl'  command  may  be
71              needed.  If  there are multiple mpt fusion controllers (HBAs) in
72              the computer, then the user will need to specify  which  one  to
73              use   with  the  syntax:  '/dev/mptctl,<n>'  where  <n>  is  the
74              "ioc_num". This number can be found with dmesg after the  mptsas
75              driver  is registered and appears as a suffix to the driver name
76              (e.g.     mpt2sas0).    It    can    also    be     found     in
77              '/sys/class/scsi_host/host<n>/unique_id'.   When  this interface
78              is used the --sa=SAS_ADDR option must be given  to  specify  the
79              SAS address of the SMP target.
80
81       sgv4 (sg)
82              This  interface is more generic and supported by several SAS HBA
83              drivers including mptsas (and mpt2sas). It was introduced in the
84              Linux  2.6.24 kernel. The SMP functions are passed to the kernel
85              via the bsg driver using a format known as "SCSI Generic Version
86              4" which gives this interface its name: "sgv4" or just "sg". The
87              SAS transport layer within the SCSI sub-system unpacks  the  SMP
88              requests and forwards them to SAS low level drivers that support
89              this interface.  The  SMP_DEVICE  is  either  a  member  of  the
90              '/sys/class/bsg'  directory  (e.g. /sys/class/bsg/expander-6:0 )
91              or   a   device   node   made   for   the   bsg   driver   (e.g.
92              /dev/bsg/expander-6:0  ).  Such  device  nodes are dynamic (i.e.
93              they don't have fixed major and minor numbers) and should corre‐
94              spond   to   the   major   and   minor   numbers  found  in  the
95              'sys/class/bsg/<smp_target_device>/dev' file.
96

FREEBSD INTERFACE

98       The CAM subsystem has been enhanced in FreeBSD 9  to  pass-through  SMP
99       requests  and  return the corresponding responses. However CAM does not
100       directly access expander devices because they are not SCSI devices.  It
101       makes  the  assumption  that  each  SAS  expander has an integrated SES
102       (enclosure) device and that is addressed. This assumption seems  to  be
103       true for SAS-2 expanders but not some SAS-1 expanders. Thus invocations
104       look like this:
105
106         # smp_discover /dev/ses0
107
108       where /dev/ses0 is a SES device associated with a SAS expander.
109

SOLARIS INTERFACE

111       The USMP pass-through mechanism is used. Invocations look like this:
112
113         # smp_rep_manufacturer /dev/smp/expd0
114

ENVIRONMENT VARIABLES

116       If the device name is not given then the  SMP_UTILS_DEVICE  environment
117       variable  is checked and if present its contents are used as the device
118       name.
119
120       If the SAS address (of the SMP target) is not given and it is  required
121       (i.e.    it   is   not   implicit   in   the   device  name)  then  the
122       SMP_UTILS_SAS_ADDR environment variable is checked and if  present  its
123       contents  are  used as the SAS address. SAS addresses are usually given
124       in hex indicated by a leading '0x' or trailing 'h'.
125
126       If either or both environment variables and the  corresponding  command
127       line options are given, then the command line options take precedence.
128

COMMON OPTIONS

130       Mandatory  arguments to long options are mandatory for short options as
131       well.  If an option takes a numeric  argument  then  that  argument  is
132       assumed  to  be decimal unless otherwise indicated (e.g. with a leading
133       "0x" or a trailing "h").
134
135       -E, --expected=EX
136              revision 4a of the SAS-2 draft introduced an 'expected  expander
137              change  count' field in some SMP requests. The idea is to detect
138              other SMP initiators trying to change the state of an  expander.
139              The  value  EX  is  from  0  to 65535 inclusive with 0 being the
140              default value. When EX is greater than zero then  if  the  value
141              doesn't  match the expander change count of the SMP target (i.e.
142              the expander) when the request arrives then the  target  ignores
143              the  request  and  sets  a  function result of "invalid expander
144              change count" in the response.
145
146       -h, --help
147              output the usage message for the utility then exit.
148
149       -H, --hex
150              output the response in hexadecimal. This does  not  include  the
151              trailing CRC field.
152
153       -I, --interface=PARAMS
154              interface specific parameters. This option is usually not needed
155              since the interface type is guessed by a utility  based  on  the
156              characteristics  of  the given SMP_DEVICE argument or what is in
157              the corresponding environment variables. PARAMS is of the  form:
158              INTF[,force].   If the guess doesn't work then the interface can
159              be specified by giving a INTF of either 'mpt' or 'sgv4'.  Sanity
160              checks  are  still  performed  and  a  utility  may refuse if it
161              doesn't agree with the given INTF. If the user  is  really  sure
162              then  adding  a ',force' will force the utility to use the given
163              interface.
164
165       -r, --raw
166              send the response to stdout in binary. This does not include the
167              trailing CRC field. All error messages are sent to stderr.
168
169       -s, --sa=SAS_ADDR
170              specifies  the  SAS  address of the SMP target device. Typically
171              this is an expander. This  option  may  not  be  needed  if  the
172              SMP_DEVICE  has the target's SAS address associated with it. The
173              SAS_ADDR is in decimal but most SAS addresses are shown in hexa‐
174              decimal.  To  give a number in hexadecimal either prefix it with
175              '0x' or put a trailing 'h' on it. If this option  is  not  given
176              then the value in the environment variable SMP_UTILS_SAS_ADDR is
177              used.
178
179       -v, --verbose
180              increase the verbosity of  the  output.  Can  be  used  multiple
181              times.
182
183       -V, --version
184              print the version string and then exit.
185

EXIT STATUS

187       To  aid  scripts  that  call these utilities, the exit status is set to
188       indicate success (0) or failure (1 or more):
189
190       0      success
191
192       1 - 63 reserved for SMP function result codes. See the SAS-2 (or later)
193              draft,  in  the  section on the application layer, drilling down
194              further: management application layer then SMP  functions.  Here
195              are some common function result codes: 1 [unknown SMP function],
196              2 [SMP function failed], 16 [phy does not exist], 17 [index does
197              not  exist],  18  [phy  does  not support SATA], 19 [unknown phy
198              operation], 22 [phy vacant] and 35 [zone lock violation].
199
200       91     syntax error. Either illegal options, options with bad arguments
201              or a combination of options that is not permitted.
202
203       92     the   utility  is  unable  to  open,  close  or  use  the  given
204              SMP_DEVICE.  The given file name could be incorrect or there may
205              be  file  permission  problems.  Adding the --verbose option may
206              give more information.
207
208       97     the response to an SMP function failed sanity checks.
209
210       99     any error that can't be categorized into  values  1  to  97  may
211              yield  this value.  This includes transport and operating system
212              errors.
213

NOTES

215       Finding the SAS address of an expander can be a challenge in some envi‐
216       ronments.  An  enclosure  containing one or more expanders may have the
217       expander SAS address(es) printed on the back of the device, a bit  like
218       Ethernet MAC addresses.
219
220       In  the Linux 2.6 kernel series the expander SAS address may well be in
221       the sysfs tree but it is not always easy to find. Doing this search may
222       help:
223
224         # find /sys -name "*expander*"
225
226       That  should  show the suffix on any expanders that have been detected.
227       Then            a             command             like             'cat
228       /sys/class/sas_device/expander-6:0/sas_address'  should  show  its  SAS
229       address.
230
231       Another approach is to work backwards from SCSI devices  (i.e.  logical
232       units).  The  protocol  specific  port log page (log page 18h) contains
233       fields for the "attached SAS address". The  sg_logs  utility  from  the
234       sg3_utils package could be used like this:
235
236         # sg_logs --page=18h /dev/sdb
237
238       Any  given  "attached  SAS  address"  is either a HBA, an expander or 0
239       indicating that port is not connected.  An  expander  is  indicated  by
240       "attached device type: expander device". A SAS disk's target port iden‐
241       tifiers (also known as SAS addresses), device  name  and  logical  unit
242       name  (all  NAA  5  format)  can be found with the sg_vpd utility (e.g.
243       'sg_vpd -i <disk_dev>'). The sdparm utility can provide the same infor‐
244       mation (e.g. 'sdparm -i <disk_dev>').
245
246       A SAS expander is often associated with a SCSI Enclosure Services (SES)
247       device sometimes on the same silicon attached via a virtual phy to  the
248       expander. That SES device may be able to access and control an attached
249       enclosure or backplane via SGPIO or I2C on sideband signals (e.g. in  a
250       SFF-8087 cable). To interact with a SES device, see the sg_ses utility.
251
252       Often  expander  phys  are grouped in fours on the same connector (e.g.
253       SFF-8088). Care needs to be taken when multiple expanders are intercon‐
254       nected.   An enclosure universal port is one in which the "table to ta‐
255       ble supported" attribute is set (in the REPORT  GENERAL  response)  and
256       the  associated  phys have the table routing attribute (in the DISCOVER
257       response). Enclosure universal ports were introduced in SAS-2 and  have
258       few  restrictions when used to interconnect expanders or connect SAS or
259       SATA devices. An enclosure out port is one in which the "table to table
260       supported"  attribute  is  clear and the associated phys have the table
261       routing attribute. An enclosure in port is one in which the  associated
262       phys  have  the subtractive routing attribute. When universal ports are
263       not available, an expander interconnect should be between  an  in  port
264       and an out port.
265

EXAMPLES

267       See "Examples" section in http://sg.danny.cz/sg/smp_utils.html .
268

CONFORMING TO

270       SAS has multiple generations. The early standards are: the original SAS
271       (ANSI INCITS 376-2003), SAS  1.1  (INCITS  417-2006)  and  SAS-2  (ANSI
272       INCITS 457-2010) . SAS-2.1 work was split into an electrical and physi‐
273       cal layers document (standardized as SAS-2.1 ANSI INCITS 478-2011) with
274       the  upper  level  layers  placed in a document called the SAS Protocol
275       Layer and it was standardized as SPL ANSI INCITS  476-2011.  Next  came
276       SPL-2  which  was  standardized as SPL-2 ANSI INCITS 505-2013. SPL-3 is
277       near standardization and its most recent draft is spl3r07.pdf. To avoid
278       confusion, the multiple generations of SAS will be referred to in these
279       man pages as SAS 1, 1.1, 2, 2.1 (SPL) and 3 (SPL-2 and SPL-3).  Roughly
280       speaking  SAS-1  runs  at 3 Gbps, SAS-2 at 6 Gbps and SAS-3 at 12 Gbps.
281       Drafts, including those just prior to standardization can be  found  at
282       the http://www.t10.org site (e.g. spl-r07.pdf and spl2r04c.pdf). INCITS
283       policy now requires a registration to view these drafts, a  break  from
284       t10.org tradition.
285
286       The   two   utilities  for  reading  and  writing  to  GPIO  registers,
287       smp_read_gpio and smp_write_gpio, are defined in the Small Form  Factor
288       document  SFF-8485  found  at  http://www.sffcommittee.com . "Enhanced"
289       versions of the corresponding SMP functions have been mentioned in some
290       drafts  but  no definitions have been published and the references have
291       been removed in more recent drafts.
292
293       In this section of each utility's man page is  the  first  standard  in
294       which  the associated SMP function appeared and whether there have been
295       significant additions in later standards.
296
297       The COVERAGE file in the smp_utils source tarball shows a table of  all
298       SMP  function  names defined in the drafts, the versions of those stan‐
299       dards in which those SMP functions first appeared and the corresponding
300       smp_utils  utility  names. A lot of extra SMP functions have been added
301       in SAS-2 associated with zoning.
302

AUTHORS

304       Written by Douglas Gilbert.
305

REPORTING BUGS

307       Report bugs to <dgilbert at interlog dot com>.
308
310       Copyright © 2006-2014 Douglas Gilbert
311       This software is distributed under a FreeBSD license. There is NO  war‐
312       ranty;  not  even  for MERCHANTABILITY or FITNESS FOR A PARTICULAR PUR‐
313       POSE.
314

SEE ALSO

316       sg_logs, sg_vpd, sg_ses(sg3_utils); sdparm(sdparm); lsscsi(lsscsi)
317
318
319
320smp_utils-0.98                     May 2014                       SMP_UTILS(8)
Impressum