From: Rich <rercola@pha.jhu.edu>
To: linux-scsi@vger.kernel.org
Subject: Odd behavior of a "SAS-2" backplane with SGPIO commands
Date: Tue, 3 Jul 2012 21:54:58 -0400 [thread overview]
Message-ID: <CAOeNLuruup-22wAFgR0b+cPc0nCf_jUm0teDHB7DLnRmcHtTog@mail.gmail.com> (raw)
[My apologies if this is the wrong mailing list for this, but it
seemed to be the most relevant. Please direct me elsewhere and discard
if this is OT.]
Hi all,
I've been beating my head against SGPIO for a bit now, and I can't
tell if I'm just misreading SFF-8485, or this backplane is just not
doing something sane.
I have here a Supermicro X8DAH-F+ with a backplane of model
BPN-SAS-836A - which means it has 3 MG9072 controller chips on it.
Supports speaking in-band or out-of-band to read data, control lights,
&c.
With two LSI 9201-16i HBA attached, manipulating it via
/dev/bsg/sas_hostN and smp_utils 0.97, SFF-8485 section 8.4.4 seems to
think that changing this:
00 41 02 00 00 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0
10 a0 a0 a0 a0 00 00 00 00 00 00 00 00 00 00 00 00
20 00 00 00 00
By doing this:
# smp_write_gpio -d a1,a0,a0,a0 -t 3 -i 0 -c /dev/bsg/sas_hostN
Resulting in:
00 41 02 00 00 a1 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0
10 a0 a0 a0 a0 00 00 00 00 00 00 00 00 00 00 00 00
20 00 00 00 00
Should enable a single drive's fault LED (drive m+3, by spec above).
In practice, I am in possession of ~90 identical machines, and on
every single one, this controls the fault LED on 3 drives - I have 3
SAS ports wired to the backplane (via iPASS cable) per HBA, so I would
suspect the HBA of setting bit m+3 on each SAS port [and having each
of its three ports running to an input controlled by a different SGPIO
controller on the backplane]. No permutation of the register bits
beyond the 4 bytes at index 0 changes the behavior of the LEDs that I
can see, and the output in the beginning [a0 a0 ... 00 00 00 00] is
what is returned on clean cold boot of the machine.
In contrast, when I have an LSI 9240-8i attached, I can control
per-drive LEDs, though the mechanism it uses for this is opaque to me
(the megaraid_sas driver doesn't expose a virtual SAS host port like
mpt2sas, so I am manipulating this using LSI's closed-source MegaCli
blob); so I know it is possible, through some method, to control
per-drive LEDs.
I cannot tell, however, whether I am using smp_write_gpio incorrectly
(either by misreading the spec or somehow abusing the virtual SAS
port), or it's a bug somewhere (be it in smp_write_gpio, the kernel,
the HBA firmware, or the upstream MG9072's firmware, that is somehow
magically avoided by the 9240-8i), and there is almost no public
documentation of people using smp_write_gpio.
I've tried this with kernel 2.6.32-220.7.1.el6, 3.4.4, and 3.5.0-rc5
(the last because it includes mpt2sas 13.XX.XX.XX, while 3.4.4 has
12.XX.XX.XX, and I was curious if anything had changed), and smp_utils
0.97.
I wanted to see what the register state was when the 9240-8i was in
use, but I couldn't coax the megaraid_sas driver into disgorging this
information, and upon unplugging the iPASS cable from the backplane to
connect it to the HBA, the backplane appears to reset its internal
state; the LEDs cease blinking in any pattern, and consequent querying
with the HBA returns expected default initial state.
Am I insane, or is this backplane crazy? Does anyone have any
experience with cajoling such things into submission?
Thanks,
- Rich Ercolani
next reply other threads:[~2012-07-04 1:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 1:54 Rich [this message]
2012-08-18 23:52 ` Odd behavior of a "SAS-2" backplane with SGPIO commands Pasi Kärkkäinen
2012-08-19 0:10 ` Rich
2012-08-19 10:25 ` Pasi Kärkkäinen
2012-08-19 12:50 ` Harri Olin
2012-08-19 13:13 ` Pasi Kärkkäinen
2012-08-19 13:47 ` Rich
2012-08-19 13:56 ` Pasi Kärkkäinen
2012-08-19 14:01 ` Rich
2012-08-19 14:06 ` Pasi Kärkkäinen
2012-09-10 13:47 ` Pasi Kärkkäinen
2012-09-10 16:01 ` Emmanuel Florac
2012-09-10 16:04 ` Pasi Kärkkäinen
2012-09-10 16:07 ` Rich
2012-09-10 16:13 ` Pasi Kärkkäinen
2012-09-10 16:14 ` Rich
2012-09-10 16:25 ` Pasi Kärkkäinen
2012-10-21 12:46 ` Pasi Kärkkäinen
2012-11-01 15:55 ` Rich
2012-11-01 16:04 ` Pasi Kärkkäinen
2012-12-07 13:46 ` Pasi Kärkkäinen
[not found] ` <CAOeNLuroRgZUvFWYTx7yr5ERtEpjiOwQgcy4COCLsm7Z9wWaKw@mail.gmail.com>
2012-12-19 19:40 ` Pasi Kärkkäinen
[not found] ` <CAOeNLuqVPQTsBs1eoizHBcEVbGgLrQOQBxqkV38cGwyKS4UTNA@mail.gmail.com>
2012-12-19 19:41 ` Pasi Kärkkäinen
2013-04-23 0:19 ` Pasi Kärkkäinen
[not found] ` <CAOeNLuo+Pti7LfshpOuzDSwWzdtXw0Ouph7ZAoJ9i7CyaUXiAA@mail.gmail.com>
2013-04-23 0:39 ` Pasi Kärkkäinen
[not found] ` <CAOeNLuqnX9r-jrmq0kV1=kU3XOzFEttDQktcD5338BzaBX3KHg@mail.gmail.com>
2013-08-30 21:42 ` Rich
2013-09-01 17:13 ` Pasi Kärkkäinen
2013-09-02 14:44 ` Pasi Kärkkäinen
2013-10-03 19:11 ` Pasi Kärkkäinen
2013-10-03 20:07 ` Rich
2013-10-03 20:16 ` Pasi Kärkkäinen
2013-10-04 0:07 ` Douglas Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOeNLuruup-22wAFgR0b+cPc0nCf_jUm0teDHB7DLnRmcHtTog@mail.gmail.com \
--to=rercola@pha.jhu.edu \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).