Date: Mon, 17 Aug 2020 20:33:42 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 248630] sesutil does not report all drives in an MSA60, locate LED is off by +1 Message-ID: <bug-248630-227-5aUv4uvdeY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-248630-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248630 --- Comment #4 from Mike Biesele <mike@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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248630-227-5aUv4uvdeY>