Re: Odd behavior of a "SAS-2" backplane with SGPIO commands

["Pasi Kärkkäinen" <pasik@iki.fi>]

On Sun, Aug 19, 2012 at 10:01:08AM -0400, Rich wrote:
> My short example would be something like the original message, but In
> brief, pages 27-28 of SFF-8485 [tables 24-27, in section 8.4.4 "GPIO
> transmit registers"] have what you want - I could reproduce the table
> here, but that'd be convoluted to do in text. :)
> 

Yep :)

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

Great, thanks a lot! 

Also let us know when you hear back from Supermicro/LSI .. 


-- Pasi


> - Rich
> 
> On Sun, Aug 19, 2012 at 9:56 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Sun, Aug 19, 2012 at 09:47:17AM -0400, Rich wrote:
> >> I've got open discussions with both Supermicro and LSI at the moment,
> >> and have shipped one of them a backplane and HBA to demonstrate this
> >> since they couldn't replicate it easily in-house.
> >>
> >
> > Cool! Let's hope they'll be able to fix it..
> >
> >> I also wouldn't claim SGPIO is "disabled" on any of these cards - any
> >> of the RAID cards don't expose the virtual SMP port, but said blinking
> >> works fine through LSI's magic binary blob MegaCLI. And with the
> >> 9211-8i and other SAS2008 HBAs (9201-16i being the one I have a lot
> >> of), it works great on any expander I've tried, but on the passive
> >> backplanes in these, the behavior is as I described - blinking one LED
> >> per SAS port plugged from a given HBA into the backplane. [...which is
> >> even more fascinating the more you think about it, since that means
> >> that the behavior easily straddles multiple passive management chips,
> >> which looks more like an HBA-end problem...]
> >>
> >
> > Yep..
> >
> > btw do you have example commands/scripts/tools for SGPIO LED control?
> > I should be able to try this stuff in a couple of days..
> >
> > Otherwise I'll try reading the SFF-8485/SGPIO spec and play with smp_write_gpio/smp_read_gpio :)
> >
> > Thanks,
> >
> > -- Pasi
> >
> >
> >> - Rich
> >>
> >> On Sun, Aug 19, 2012 at 9:13 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >> > On Sun, Aug 19, 2012 at 03:50:00PM +0300, Harri Olin wrote:
> >> >> On 19.8.2012 13:25, Pasi Kärkkäinen wrote:
> >> >> >>To be brief, the sas2ircu toolset works perfectly fine with IT mode
> >> >> >>HBAs - just not with passive backplanes AFAICS [e.g. the 846A, versus
> >> >> >>the 846EL2].
> >> >> >Ok. So with an expander backplane (846EL*) with SES, sas2ircu is able to control leds?
> >> >> >"LOCATE" command works? I haven't been able to try those commands with SES backplanes
> >> >> >because in these systems I've been trying to avoid expanders :)
> >> >>
> >> >> I think SGPIO control is disabled intentionally on LSI 9211-8i
> >> >> firmware, maybe others. When using expander, the expander controls
> >> >> LED's and SGPIO control lines from HBA are unused.
> >> >>
> >> >
> >> > Yep. The good news is that Rich has been able to control the SM passive backplane
> >> > (with AMI MG9072 SGPIO chip) LEDs using SPGIO thru LSI SAS2008 HBAs from Linux,
> >> > using smp_utils tools. Those tools directly send SGPIO commands using mptctl/mpt2ctl interface.
> >> >
> >> > The only problem Rich had is with 9211-8i HBAs.. 3 LEDs light up simultanously,
> >> > which sounds like a firmware/driver bug somewhere..
> >> >
> >> > With SAS2308 based HBAs it works properly with the same Supermicro passive backplane,
> >> > and he has been able to control invidual LEDS thru SGPIO using smp_utils,
> >> > If I understood the earlier discussion correctly.
> >> >
> >> >
> >> >> The thing is, on 9211-8i and 9240 and probably others, multilane
> >> >> connectors are wired backwards so that if you connect a normal
> >> >> ipass-ipass cable, backplane slots will appear in backwards order to
> >> >> the system. Firmware knows this and slot numbers will appear to be
> >> >> correct when checking serial numbers etc from bios or with sas2ircu,
> >> >> but I suspect this is related to SGPIO not working.
> >> >>
> >> >
> >> > Yeah, that's really annoying..
> >> >
> >> > I wonder if option "phyPolarity" (mentioned here: http://www.xtremesystems.org/forums/archive/index.php/t-271922.html)
> >> > affects that ?
> >> >
> >> > .. or the "Lane and polarity reversal" feature advertised for LSI SAS2308 based HBAs ?
> >> > http://www.servethehome.com/lsi-sas-2308-raid-controller-hba-information-listing/
> >> >
> >> >
> >> >> You can get the SGPIO working (using sas2ircu) with
> >> >> Supermicro-supplied SAS2008 firmware from
> >> >> ftp://ftp.supermicro.com/driver/SAS/LSI/2008/IT/Firmware/ but as
> >> >> Supermicro SAS2008 HBA's (AOC-USAS2-L8i) use correct lane order on
> >> >> multilane connector, SGPIO-controlled LOCATE LED will point to wrong
> >> >> slot if not used with Supermicro card. Note that Supermicro
> >> >> backplanes will not light the LED if no HDD is in slot.
> >> >>
> >> >
> >> > Yep..
> >> >
> >> >> Tested mainly with Supermicro 846A backplane I think.
> >> >>
> >> >> I think I still have a support request open with LSI but haven't
> >> >> heart back for a long time about this issue..
> >> >>
> >> >
> >> > Me too, they replied once asking what kind of SAS x4 cable I was using,
> >> > but no replies after that.. I've been pinging them quite a few times,
> >> > but it seems they've redirected me to /dev/null.
> >> >
> >> >> Also I haven't yet tested the new SAS2308 based cards, great if
> >> >> finally fixed but I kind of doubt it before I see it :)
> >> >>
> >> >
> >> > Hehe :)
> >> >
> >> > Thanks,
> >> >
> >> > -- Pasi
> >> >
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html