linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

             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).