[Bug 248630] sesutil does not report all drives in an MSA60, locate LED is off by +1

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248630

--- Comment #4 from Mike Biesele <mike at biesele.com> ---
Unfortunately, I have other MSA60s that are on the latest firmware (2.28,
according to
https://support.hpe.com/hpsc/swd/public/detail?swItemId=co_119008_1#tab-history
) that exhibit this same behavior.  I think they are past EOL/EOS so a firmware
update is not possible.  I assume this enclosure falls under the category
described at http://sg.danny.cz/sg/sg_ses.html : 

"Prior to the EIIOE bit's introduction in ses3r06 several arrays acted as if
this bit was present and set. If 'force' is given the Additional Element Status
page's element index field is treated as if EIIOE=1. If 'auto' is given a
heuristic is used to decide whether to set EIIOE or not."

It looks like ses3r06 was introduced in August 2013, and the 2.28 firmware for
this enclosure was released in May 2013.  

I think the heuristic described in the sg_ses documentation is documented in a
large comment in sg_ses.c in sg3_utils :

/* Join array has four "element index"ing stategies:
 *   [1] based on all descriptors in the Enclosure Status (ES) dpage
 *   [2] based on the non-overall descriptors in the ES dpage
 *   [3] based on the non-overall descriptors of these element types
 *       in the ES dpage: DEVICE_ETC, ARRAY_DEV_ETC, SAS_EXPANDER_ETC,
 *       SCSI_IPORT_ETC, SCSI_TPORT_ETC and ENC_SCELECTR_ETC.
 *   [4] based on the non-overall descriptors of the SAS_CONNECTOR_ETC
 *       element type
 *
 * The indexes are all origin 0 with the maximum index being one less then
 * the number of status descriptors in the ES dpage. Table of supported
 * permutations follows:
 *
 *  ==========|===============================================================
 *  Algorithm |              Indexes                  |    Notes
 *            |Element|Connector element|Other element|
 *  ==========|=======|=================|=============|=======================
 *   [A]      |  [2]  |       [4]       |    [3]      | SES-2, OR
 *   [A]      |  [2]  |       [4]       |    [3]      | SES-3,EIIOE=0
 *  ----------|-------|-----------------|-------------|-----------------------
 *   [B]      |  [1]  |       [1]       |    [1]      | SES-3, EIIOE=1
 *  ----------|-------|-----------------|-------------|-----------------------
 *   [C]      |  [2]  |       [2]       |    [2]      | SES-3, EIIOE=2
 *  ----------|-------|-----------------|-------------|-----------------------
 *   [D]      |  [2]  |       [1]       |    [1]      | SES-3, EIIOE=3
 *  ----------|-------|-----------------|-------------|-----------------------
 *   [E]      |  [1]  |       [4]       |    [3]      | EIIOE=0 and
 *            |       |                 |             | --eiioe=force, OR
 *   [E]      |  [1]  |       [4]       |    [3]      | {HP JBOD} EIIOE=0 and
 *            |       |                 |             | --eiioe=auto and
 *            |       |                 |             | AES[desc_0].ei==1 .
 *  ----------|-------|-----------------|-------------|-----------------------
 *   [F]      | [2->3]|       [4]       |    [3]      | "broken_ei" when any
 *            |       |                 |             | of AES[*].ei invalid
 *            |       |                 |             | using strategy [2]
 *  ----------|-------|-----------------|-------------|-----------------------
 *   [Z]      |  -    |       [4]       |    [3]      | EIP=0, implicit
 *            |       |                 |             | element index of [3]
 *  ==========================================================================
 *
 *
 */

Which does look pretty cumbersome, and appears to call out some HP gear for
specific treatment as well.  Ugh.

Would a sysctl tunable be plausible to implement?  Something like
dev.mps.ses.X.eiioe=1 to mimic the --eiioe=force behavior from ses_util and
allow working around the broken behavior?  I realize it may not be worth it at
this point, of course.

-- 
You are receiving this mail because:
You are the assignee for the bug.