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

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

[Rich]

[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

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

[Pasi Kärkkäinen]

On Tue, Jul 03, 2012 at 09:54:58PM -0400, Rich wrote:
> [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.]
> 

This is a perfectly fine list, hopefully :)

> Hi all,
>

Hello,

> 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've been struggling with SGPIO LED control aswell! 

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

Wow, I've been trying to figure out how to control SGPIO from Linux,
and for some reason I didn't find anything about smp_write_gpio earlier.

I need to try that. Thanks a lot for this information! :)

(earlier I tried getting LSI sas2ircu to do something clever 
with the LEDS but that didn't work at all - I guess LSI only supports 
SGPIO LED control in IR mode - not IT mode).


> 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?
> 

Hmm, I have some servers with LSI 9211-8i SAS2 HBAs (mpt2sas driver) 
and Supermicro BPN-SAS-846A backplanes, which have 3x MG9072 chips in them.

I'll let you know how that stuff works for me!

Thanks,

-- Pasi

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

[Rich]

I actually have a lot of information I can share about this since I
wrote this email.

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

Also, the bug I'm experiencing is not present with the SAS2308
generation of the HBAs (the 9217 and friends) at the same F/W version
as the 9211, so this may be a bug - on the controller chip, driver, or
HBA firmware.

- Rich

On Sat, Aug 18, 2012 at 7:52 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Tue, Jul 03, 2012 at 09:54:58PM -0400, Rich wrote:
>> [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.]
>>
>
> This is a perfectly fine list, hopefully :)
>
>> Hi all,
>>
>
> Hello,
>
>> 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've been struggling with SGPIO LED control aswell!
>
>> 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).
>>
>
> Wow, I've been trying to figure out how to control SGPIO from Linux,
> and for some reason I didn't find anything about smp_write_gpio earlier.
>
> I need to try that. Thanks a lot for this information! :)
>
> (earlier I tried getting LSI sas2ircu to do something clever
> with the LEDS but that didn't work at all - I guess LSI only supports
> SGPIO LED control in IR mode - not IT mode).
>
>
>> 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?
>>
>
> Hmm, I have some servers with LSI 9211-8i SAS2 HBAs (mpt2sas driver)
> and Supermicro BPN-SAS-846A backplanes, which have 3x MG9072 chips in them.
>
> I'll let you know how that stuff works for me!
>
> 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

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

[Pasi Kärkkäinen]

On Sat, Aug 18, 2012 at 08:10:27PM -0400, Rich wrote:
> I actually have a lot of information I can share about this since I
> wrote this email.
>

Great!
 
> 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 :)


> Also, the bug I'm experiencing is not present with the SAS2308
> generation of the HBAs (the 9217 and friends) at the same F/W version
> as the 9211, so this may be a bug - on the controller chip, driver, or
> HBA firmware.
> 

That's good to know. Did you open any bug reports about the SAS2008/9211 SGPIO glitch? 

Thanks,

-- Pasi

> - Rich
> 
> On Sat, Aug 18, 2012 at 7:52 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Tue, Jul 03, 2012 at 09:54:58PM -0400, Rich wrote:
> >> [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.]
> >>
> >
> > This is a perfectly fine list, hopefully :)
> >
> >> Hi all,
> >>
> >
> > Hello,
> >
> >> 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've been struggling with SGPIO LED control aswell!
> >
> >> 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).
> >>
> >
> > Wow, I've been trying to figure out how to control SGPIO from Linux,
> > and for some reason I didn't find anything about smp_write_gpio earlier.
> >
> > I need to try that. Thanks a lot for this information! :)
> >
> > (earlier I tried getting LSI sas2ircu to do something clever
> > with the LEDS but that didn't work at all - I guess LSI only supports
> > SGPIO LED control in IR mode - not IT mode).
> >
> >
> >> 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?
> >>
> >
> > Hmm, I have some servers with LSI 9211-8i SAS2 HBAs (mpt2sas driver)
> > and Supermicro BPN-SAS-846A backplanes, which have 3x MG9072 chips in them.
> >
> > I'll let you know how that stuff works for me!
> >
> > 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
--
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

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

[Harri Olin]

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.

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.

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.

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

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

Quick summary about Supermicro backplane models:
T  - separate SATA connectors, no SGPIO and no locate LED's
TQ - separate SATA connectors for each slot, separate SGPIO header for 
each 4 slot group
A  - multilane connector for each 4 slots, SGPIO on multilane connectors
E1 - single expander
E2 - dual expander
E16 - single 6GB expander
E26 - dual 6GB expander

-- 
Harri.

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

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

[Pasi Kärkkäinen]

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

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

[Rich]

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.

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

- 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

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

[Pasi Kärkkäinen]

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

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

[Rich]

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


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

- 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

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

[Pasi Kärkkäinen]

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

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

[Pasi Kärkkäinen]

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

Hello,

Any replies from Supermicro/LSI ? 

-- Pasi

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

[Emmanuel Florac]

Le Mon, 10 Sep 2012 16:47:11 +0300
Pasi Kärkkäinen <pasik@iki.fi> écrivait:

> Any replies from Supermicro/LSI ? 
> 

Only loosely related, but Supermicro replaced recently my 846E26 (dual
expander backplane) with 846E16 (single expander). Apparently they
gave up getting the E26 to work properly or something: LSI expander
firmware problem.

In another (very large scale, high end) setup, many different 60 slots
5 LSI expanders chassis had a general failure of the 5th drawer.
Another LSI SAS-2 expander firmware problem.

I could start a rant about the evil of proprietary firmware, etc. You
get my meaning :)

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------
--
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

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

[Pasi Kärkkäinen]

On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
> Le Mon, 10 Sep 2012 16:47:11 +0300
> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
> 
> > Any replies from Supermicro/LSI ? 
> > 
> 
> Only loosely related, but Supermicro replaced recently my 846E26 (dual
> expander backplane) with 846E16 (single expander). Apparently they
> gave up getting the E26 to work properly or something: LSI expander
> firmware problem.
> 
> In another (very large scale, high end) setup, many different 60 slots
> 5 LSI expanders chassis had a general failure of the 5th drawer.
> Another LSI SAS-2 expander firmware problem.
> 
> I could start a rant about the evil of proprietary firmware, etc. You
> get my meaning :)
> 

Yeah, this is a good example why we're trying to get the LEDs working with 
direct attach (non-expander) backplanes :)

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

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

[Rich]

On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
>> Le Mon, 10 Sep 2012 16:47:11 +0300
>> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
>>
>> > Any replies from Supermicro/LSI ?
>> >
>>
>> Only loosely related, but Supermicro replaced recently my 846E26 (dual
>> expander backplane) with 846E16 (single expander). Apparently they
>> gave up getting the E26 to work properly or something: LSI expander
>> firmware problem.
>>
>> In another (very large scale, high end) setup, many different 60 slots
>> 5 LSI expanders chassis had a general failure of the 5th drawer.
>> Another LSI SAS-2 expander firmware problem.
>>
>> I could start a rant about the evil of proprietary firmware, etc. You
>> get my meaning :)
>>
>
> Yeah, this is a good example why we're trying to get the LEDs working with
> direct attach (non-expander) backplanes :)
>
> -- Pasi
>

I don't have anything useful for people, other than that they have
shown me an HBA firmware that fixes the LED problem but has other
problems they're still debugging.

So there does exist code for this firmware which will fix this problem.

[I don't disagree on the evils of proprietary firmware, but this is
the hand I've been dealt, so.]

- Rich
--
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

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

[Pasi Kärkkäinen]

On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
> On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
> >> Le Mon, 10 Sep 2012 16:47:11 +0300
> >> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
> >>
> >> > Any replies from Supermicro/LSI ?
> >> >
> >>
> >> Only loosely related, but Supermicro replaced recently my 846E26 (dual
> >> expander backplane) with 846E16 (single expander). Apparently they
> >> gave up getting the E26 to work properly or something: LSI expander
> >> firmware problem.
> >>
> >> In another (very large scale, high end) setup, many different 60 slots
> >> 5 LSI expanders chassis had a general failure of the 5th drawer.
> >> Another LSI SAS-2 expander firmware problem.
> >>
> >> I could start a rant about the evil of proprietary firmware, etc. You
> >> get my meaning :)
> >>
> >
> > Yeah, this is a good example why we're trying to get the LEDs working with
> > direct attach (non-expander) backplanes :)
> >
> > -- Pasi
> >
> 
> I don't have anything useful for people, other than that they have
> shown me an HBA firmware that fixes the LED problem but has other
> problems they're still debugging.
> 
> So there does exist code for this firmware which will fix this problem.
> 

That's good to know! Let's hope the fix ends up in an official 
LSI HBA firmware update in not-so-distant future.

> [I don't disagree on the evils of proprietary firmware, but this is
> the hand I've been dealt, so.]
> 

Yeah, there's still the proprietary LSI HBA firmware, but at least using
direct-attach backplanes has one less :) 

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

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

[Rich]

On Mon, Sep 10, 2012 at 12:13 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
>> On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>> > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
>> >> Le Mon, 10 Sep 2012 16:47:11 +0300
>> >> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
>> >>
>> >> > Any replies from Supermicro/LSI ?
>> >> >
>> >>
>> >> Only loosely related, but Supermicro replaced recently my 846E26 (dual
>> >> expander backplane) with 846E16 (single expander). Apparently they
>> >> gave up getting the E26 to work properly or something: LSI expander
>> >> firmware problem.
>> >>
>> >> In another (very large scale, high end) setup, many different 60 slots
>> >> 5 LSI expanders chassis had a general failure of the 5th drawer.
>> >> Another LSI SAS-2 expander firmware problem.
>> >>
>> >> I could start a rant about the evil of proprietary firmware, etc. You
>> >> get my meaning :)
>> >>
>> >
>> > Yeah, this is a good example why we're trying to get the LEDs working with
>> > direct attach (non-expander) backplanes :)
>> >
>> > -- Pasi
>> >
>>
>> I don't have anything useful for people, other than that they have
>> shown me an HBA firmware that fixes the LED problem but has other
>> problems they're still debugging.
>>
>> So there does exist code for this firmware which will fix this problem.
>>
>
> That's good to know! Let's hope the fix ends up in an official
> LSI HBA firmware update in not-so-distant future.
>
>> [I don't disagree on the evils of proprietary firmware, but this is
>> the hand I've been dealt, so.]
>>
>
> Yeah, there's still the proprietary LSI HBA firmware, but at least using
> direct-attach backplanes has one less :)
>
> Thanks!
>
> -- Pasi

Actually, the direct-attach backplanes have 3 "passive" AMI management
controller chips...which also, presumably, have embedded mutable
firmware.

- Rich
--
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

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

[Pasi Kärkkäinen]

On Mon, Sep 10, 2012 at 12:14:35PM -0400, Rich wrote:
> On Mon, Sep 10, 2012 at 12:13 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
> >> On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >> > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
> >> >> Le Mon, 10 Sep 2012 16:47:11 +0300
> >> >> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
> >> >>
> >> >> > Any replies from Supermicro/LSI ?
> >> >> >
> >> >>
> >> >> Only loosely related, but Supermicro replaced recently my 846E26 (dual
> >> >> expander backplane) with 846E16 (single expander). Apparently they
> >> >> gave up getting the E26 to work properly or something: LSI expander
> >> >> firmware problem.
> >> >>
> >> >> In another (very large scale, high end) setup, many different 60 slots
> >> >> 5 LSI expanders chassis had a general failure of the 5th drawer.
> >> >> Another LSI SAS-2 expander firmware problem.
> >> >>
> >> >> I could start a rant about the evil of proprietary firmware, etc. You
> >> >> get my meaning :)
> >> >>
> >> >
> >> > Yeah, this is a good example why we're trying to get the LEDs working with
> >> > direct attach (non-expander) backplanes :)
> >> >
> >> > -- Pasi
> >> >
> >>
> >> I don't have anything useful for people, other than that they have
> >> shown me an HBA firmware that fixes the LED problem but has other
> >> problems they're still debugging.
> >>
> >> So there does exist code for this firmware which will fix this problem.
> >>
> >
> > That's good to know! Let's hope the fix ends up in an official
> > LSI HBA firmware update in not-so-distant future.
> >
> >> [I don't disagree on the evils of proprietary firmware, but this is
> >> the hand I've been dealt, so.]
> >>
> >
> > Yeah, there's still the proprietary LSI HBA firmware, but at least using
> > direct-attach backplanes has one less :)
> >
> > Thanks!
> >
> > -- Pasi
> 
> Actually, the direct-attach backplanes have 3 "passive" AMI management
> controller chips...which also, presumably, have embedded mutable
> firmware.
> 

Yeah, true, but the "passive" management chips are not part of the SAS datapath? 
They're only communicating to the SAS HBA using the sideband signals/pins,
and controlling the LEDs on the backplane? 

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

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

[Pasi Kärkkäinen]

On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi Kärkkäinen wrote:
> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
> > >> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
> > >>
> > >> > Any replies from Supermicro/LSI ?
> > >> >
> > >>
> > >> Only loosely related, but Supermicro replaced recently my 846E26 (dual
> > >> expander backplane) with 846E16 (single expander). Apparently they
> > >> gave up getting the E26 to work properly or something: LSI expander
> > >> firmware problem.
> > >>
> > >> In another (very large scale, high end) setup, many different 60 slots
> > >> 5 LSI expanders chassis had a general failure of the 5th drawer.
> > >> Another LSI SAS-2 expander firmware problem.
> > >>
> > >> I could start a rant about the evil of proprietary firmware, etc. You
> > >> get my meaning :)
> > >>
> > >
> > > Yeah, this is a good example why we're trying to get the LEDs working with
> > > direct attach (non-expander) backplanes :)
> > >
> > > -- Pasi
> > >
> > 
> > I don't have anything useful for people, other than that they have
> > shown me an HBA firmware that fixes the LED problem but has other
> > problems they're still debugging.
> > 
> > So there does exist code for this firmware which will fix this problem.
> > 
> 
> That's good to know! Let's hope the fix ends up in an official 
> LSI HBA firmware update in not-so-distant future.
> 

Btw what was the version number of the LED-fixed LSI firmware?
I'm just wondering in which firmware series the fix might end up being included..

Also: Any updates on this?

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

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

[Rich]

On Sun, Oct 21, 2012 at 8:46 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi Kärkkäinen wrote:
>> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
>> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
>> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
>> > >> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
>> > >>
>> > >> > Any replies from Supermicro/LSI ?
>> > >> >
>> > >>
>> > >> Only loosely related, but Supermicro replaced recently my 846E26 (dual
>> > >> expander backplane) with 846E16 (single expander). Apparently they
>> > >> gave up getting the E26 to work properly or something: LSI expander
>> > >> firmware problem.
>> > >>
>> > >> In another (very large scale, high end) setup, many different 60 slots
>> > >> 5 LSI expanders chassis had a general failure of the 5th drawer.
>> > >> Another LSI SAS-2 expander firmware problem.
>> > >>
>> > >> I could start a rant about the evil of proprietary firmware, etc. You
>> > >> get my meaning :)
>> > >>
>> > >
>> > > Yeah, this is a good example why we're trying to get the LEDs working with
>> > > direct attach (non-expander) backplanes :)
>> > >
>> > > -- Pasi
>> > >
>> >
>> > I don't have anything useful for people, other than that they have
>> > shown me an HBA firmware that fixes the LED problem but has other
>> > problems they're still debugging.
>> >
>> > So there does exist code for this firmware which will fix this problem.
>> >
>>
>> That's good to know! Let's hope the fix ends up in an official
>> LSI HBA firmware update in not-so-distant future.
>>
>
> Btw what was the version number of the LED-fixed LSI firmware?
> I'm just wondering in which firmware series the fix might end up being included..
>
> Also: Any updates on this?
>
> Thanks,
>
> -- Pasi
>

The fixed FW I had demonstrated for me was still 14.0.0.0 - I've been
told it'll be rolled into the FW release currently on the site and
posted at some point, but that they have no ETA for that.

- Rich
--
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

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

[Pasi Kärkkäinen]

On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich wrote:
> On Sun, Oct 21, 2012 at 8:46 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi Kärkkäinen wrote:
> >> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
> >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
> >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
> >> > >> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
> >> > >>
> >> > >> > Any replies from Supermicro/LSI ?
> >> > >> >
> >> > >>
> >> > >> Only loosely related, but Supermicro replaced recently my 846E26 (dual
> >> > >> expander backplane) with 846E16 (single expander). Apparently they
> >> > >> gave up getting the E26 to work properly or something: LSI expander
> >> > >> firmware problem.
> >> > >>
> >> > >> In another (very large scale, high end) setup, many different 60 slots
> >> > >> 5 LSI expanders chassis had a general failure of the 5th drawer.
> >> > >> Another LSI SAS-2 expander firmware problem.
> >> > >>
> >> > >> I could start a rant about the evil of proprietary firmware, etc. You
> >> > >> get my meaning :)
> >> > >>
> >> > >
> >> > > Yeah, this is a good example why we're trying to get the LEDs working with
> >> > > direct attach (non-expander) backplanes :)
> >> > >
> >> > > -- Pasi
> >> > >
> >> >
> >> > I don't have anything useful for people, other than that they have
> >> > shown me an HBA firmware that fixes the LED problem but has other
> >> > problems they're still debugging.
> >> >
> >> > So there does exist code for this firmware which will fix this problem.
> >> >
> >>
> >> That's good to know! Let's hope the fix ends up in an official
> >> LSI HBA firmware update in not-so-distant future.
> >>
> >
> > Btw what was the version number of the LED-fixed LSI firmware?
> > I'm just wondering in which firmware series the fix might end up being included..
> >
> > Also: Any updates on this?
> >
> > Thanks,
> >
> > -- Pasi
> >
> 
> The fixed FW I had demonstrated for me was still 14.0.0.0 - I've been
> told it'll be rolled into the FW release currently on the site and
> posted at some point, but that they have no ETA for that.
> 

Ok, good to know. Thanks for the update!

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

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

[Pasi Kärkkäinen]

On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich wrote:
> On Sun, Oct 21, 2012 at 8:46 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi Kärkkäinen wrote:
> >> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
> >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote:
> >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
> >> > >> Pasi Kärkkäinen <pasik@iki.fi> écrivait:
> >> > >>
> >> > >> > Any replies from Supermicro/LSI ?
> >> > >> >
> >> > >>
> >> > >> Only loosely related, but Supermicro replaced recently my 846E26 (dual
> >> > >> expander backplane) with 846E16 (single expander). Apparently they
> >> > >> gave up getting the E26 to work properly or something: LSI expander
> >> > >> firmware problem.
> >> > >>
> >> > >> In another (very large scale, high end) setup, many different 60 slots
> >> > >> 5 LSI expanders chassis had a general failure of the 5th drawer.
> >> > >> Another LSI SAS-2 expander firmware problem.
> >> > >>
> >> > >> I could start a rant about the evil of proprietary firmware, etc. You
> >> > >> get my meaning :)
> >> > >>
> >> > >
> >> > > Yeah, this is a good example why we're trying to get the LEDs working with
> >> > > direct attach (non-expander) backplanes :)
> >> > >
> >> > > -- Pasi
> >> > >
> >> >
> >> > I don't have anything useful for people, other than that they have
> >> > shown me an HBA firmware that fixes the LED problem but has other
> >> > problems they're still debugging.
> >> >
> >> > So there does exist code for this firmware which will fix this problem.
> >> >
> >>
> >> That's good to know! Let's hope the fix ends up in an official
> >> LSI HBA firmware update in not-so-distant future.
> >>
> >
> > Btw what was the version number of the LED-fixed LSI firmware?
> > I'm just wondering in which firmware series the fix might end up being included..
> >
> > Also: Any updates on this?
> >
> > Thanks,
> >
> > -- Pasi
> >
> 
> The fixed FW I had demonstrated for me was still 14.0.0.0 - I've been
> told it'll be rolled into the FW release currently on the site and
> posted at some point, but that they have no ETA for that.
> 

I can now see P15 firmware available on LSI's website for 9211-8i (SAS2008 based HBA).
Sadly it's missing the releasenotes/changelogs for both the LSI bios and firmware..

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

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

[Pasi Kärkkäinen]

On Wed, Dec 19, 2012 at 02:00:43PM -0500, Rich wrote:
>    From the LSI P15 F/W release notes:
>    SCGCQ00342805 (DFCT) Â - SlotStatus updates to SES managed Enclosure may
>    update incorrect slots
>    "Modified FW to use SES diag page 0Ah mapping only if SMP Discover
>    DeviceSlotNum is used for Encl Phy Slot enumeration."

.. hmm it's talking about SES, but probably still worth a try with the SGPIO backplane..

>    SCGCQ00345867 (DFCT) Â - Channel NVDATA internal Phy reverse setting for
>    9207-4i4e 9207-8i 9217-4i4e 9217-8i and 9201-16i
>    "ISSUE DESC:Â Internal PHY orders are reversed for the channel boards
>    above."
>    So I would submit this is likely fixed by this FW rev.

And nice that they updated the P15 package to include the changelog now :) 

Thanks!

-- Pasi

>    - Rich
> 
>    On Fri, Dec 7, 2012 at 8:46 AM, Pasi KÀrkkÀinen <[1]pasik@iki.fi> wrote:
> 
>      On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich wrote:
>      > On Sun, Oct 21, 2012 at 8:46 AM, Pasi KÀrkkÀinen <[2]pasik@iki.fi>
>      wrote:
>      > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi KÀrkkÀinen wrote:
>      > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
>      > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi KÀrkkÀinen
>      <[3]pasik@iki.fi> wrote:
>      > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac
>      wrote:
>      > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
>      > >> > >> Pasi KÀrkkÀinen <[4]pasik@iki.fi> écrivait:
>      > >> > >>
>      > >> > >> > Any replies from Supermicro/LSI ?
>      > >> > >> >
>      > >> > >>
>      > >> > >> Only loosely related, but Supermicro replaced recently my
>      846E26 (dual
>      > >> > >> expander backplane) with 846E16 (single expander). Apparently
>      they
>      > >> > >> gave up getting the E26 to work properly or something: LSI
>      expander
>      > >> > >> firmware problem.
>      > >> > >>
>      > >> > >> In another (very large scale, high end) setup, many different
>      60 slots
>      > >> > >> 5 LSI expanders chassis had a general failure of the 5th
>      drawer.
>      > >> > >> Another LSI SAS-2 expander firmware problem.
>      > >> > >>
>      > >> > >> I could start a rant about the evil of proprietary firmware,
>      etc. You
>      > >> > >> get my meaning :)
>      > >> > >>
>      > >> > >
>      > >> > > Yeah, this is a good example why we're trying to get the LEDs
>      working with
>      > >> > > direct attach (non-expander) backplanes :)
>      > >> > >
>      > >> > > -- Pasi
>      > >> > >
>      > >> >
>      > >> > I don't have anything useful for people, other than that they
>      have
>      > >> > shown me an HBA firmware that fixes the LED problem but has other
>      > >> > problems they're still debugging.
>      > >> >
>      > >> > So there does exist code for this firmware which will fix this
>      problem.
>      > >> >
>      > >>
>      > >> That's good to know! Let's hope the fix ends up in an official
>      > >> LSI HBA firmware update in not-so-distant future.
>      > >>
>      > >
>      > > Btw what was the version number of the LED-fixed LSI firmware?
>      > > I'm just wondering in which firmware series the fix might end up
>      being included..
>      > >
>      > > Also: Any updates on this?
>      > >
>      > > Thanks,
>      > >
>      > > -- Pasi
>      > >
>      >
>      > The fixed FW I had demonstrated for me was still 14.0.0.0 - I've been
>      > told it'll be rolled into the FW release currently on the site and
>      > posted at some point, but that they have no ETA for that.
>      >
> 
>      I can now see P15 firmware available on LSI's website for 9211-8i
>      (SAS2008 based HBA).
>      Sadly it's missing the releasenotes/changelogs for both the LSI bios and
>      firmware..
>      -- Pasi
> 
> References
> 
>    Visible links
>    1. mailto:pasik@iki.fi
>    2. mailto:pasik@iki.fi
>    3. mailto:pasik@iki.fi
>    4. mailto:pasik@iki.fi
--
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

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

[Pasi Kärkkäinen]

On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
>    Nope, I'm wrong.

:(

>    I flashed P15 on a machine, and the same behavior persisted, right up to
>    and including the "groups of 3 devices light up when I do my own
>    smp_write_gpio".
>    Whereas if I flash the experimental blob I was handed by support to try
>    and confirm they had resolved the issue, it does the correct thing.
>    I wonder why this change didn't make it into P15.

Hmm.. if you have open contact channel with LSI support please ask them.. 
it'd be nice to get the fix for wider audience..

Thanks!

-- Pasi

>    - Rich
> 
>    On Wed, Dec 19, 2012 at 2:00 PM, Rich <[1]rercola@pha.jhu.edu> wrote:
> 
>      From the LSI P15 F/W release notes:
>      SCGCQ00342805 (DFCT) Â - SlotStatus updates to SES managed Enclosure may
>      update incorrect slots
>      "Modified FW to use SES diag page 0Ah mapping only if SMP Discover
>      DeviceSlotNum is used for Encl Phy Slot enumeration."
>      SCGCQ00345867 (DFCT) Â - Channel NVDATA internal Phy reverse setting for
>      9207-4i4e 9207-8i 9217-4i4e 9217-8i and 9201-16i
>      "ISSUE DESC:Â Internal PHY orders are reversed for the channel boards
>      above."
>      So I would submit this is likely fixed by this FW rev.
>      - Rich
> 
>      On Fri, Dec 7, 2012 at 8:46 AM, Pasi KÀrkkÀinen <[2]pasik@iki.fi>
>      wrote:
> 
>        On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich wrote:
>        > On Sun, Oct 21, 2012 at 8:46 AM, Pasi KÀrkkÀinen <[3]pasik@iki.fi>
>        wrote:
>        > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi KÀrkkÀinen wrote:
>        > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
>        > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi KÀrkkÀinen
>        <[4]pasik@iki.fi> wrote:
>        > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac
>        wrote:
>        > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
>        > >> > >> Pasi KÀrkkÀinen <[5]pasik@iki.fi> écrivait:
>        > >> > >>
>        > >> > >> > Any replies from Supermicro/LSI ?
>        > >> > >> >
>        > >> > >>
>        > >> > >> Only loosely related, but Supermicro replaced recently my
>        846E26 (dual
>        > >> > >> expander backplane) with 846E16 (single expander).
>        Apparently they
>        > >> > >> gave up getting the E26 to work properly or something: LSI
>        expander
>        > >> > >> firmware problem.
>        > >> > >>
>        > >> > >> In another (very large scale, high end) setup, many
>        different 60 slots
>        > >> > >> 5 LSI expanders chassis had a general failure of the 5th
>        drawer.
>        > >> > >> Another LSI SAS-2 expander firmware problem.
>        > >> > >>
>        > >> > >> I could start a rant about the evil of proprietary firmware,
>        etc. You
>        > >> > >> get my meaning :)
>        > >> > >>
>        > >> > >
>        > >> > > Yeah, this is a good example why we're trying to get the LEDs
>        working with
>        > >> > > direct attach (non-expander) backplanes :)
>        > >> > >
>        > >> > > -- Pasi
>        > >> > >
>        > >> >
>        > >> > I don't have anything useful for people, other than that they
>        have
>        > >> > shown me an HBA firmware that fixes the LED problem but has
>        other
>        > >> > problems they're still debugging.
>        > >> >
>        > >> > So there does exist code for this firmware which will fix this
>        problem.
>        > >> >
>        > >>
>        > >> That's good to know! Let's hope the fix ends up in an official
>        > >> LSI HBA firmware update in not-so-distant future.
>        > >>
>        > >
>        > > Btw what was the version number of the LED-fixed LSI firmware?
>        > > I'm just wondering in which firmware series the fix might end up
>        being included..
>        > >
>        > > Also: Any updates on this?
>        > >
>        > > Thanks,
>        > >
>        > > -- Pasi
>        > >
>        >
>        > The fixed FW I had demonstrated for me was still 14.0.0.0 - I've
>        been
>        > told it'll be rolled into the FW release currently on the site and
>        > posted at some point, but that they have no ETA for that.
>        >
> 
>        I can now see P15 firmware available on LSI's website for 9211-8i
>        (SAS2008 based HBA).
>        Sadly it's missing the releasenotes/changelogs for both the LSI bios
>        and firmware..
>        -- Pasi
> 
> References
> 
>    Visible links
>    1. mailto:rercola@pha.jhu.edu
>    2. mailto:pasik@iki.fi
>    3. mailto:pasik@iki.fi
>    4. mailto:pasik@iki.fi
>    5. mailto:pasik@iki.fi
--
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

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

[Pasi Kärkkäinen]

On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi Kärkkäinen wrote:
> On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
> >    Nope, I'm wrong.
> 
> :(
> 
> >    I flashed P15 on a machine, and the same behavior persisted, right up to
> >    and including the "groups of 3 devices light up when I do my own
> >    smp_write_gpio".
> >    Whereas if I flash the experimental blob I was handed by support to try
> >    and confirm they had resolved the issue, it does the correct thing.
> >    I wonder why this change didn't make it into P15.
> 
> Hmm.. if you have open contact channel with LSI support please ask them.. 
> it'd be nice to get the fix for wider audience..
>

It seems LSI P16 firmware has been released.. in the FW changelog I can see at least this:

"Disable SGPIO Group ID support in Channel NVDATA XML's. This allows the use of manufacturing page 7 or default slot mapping setting for direct connected drive slots."


-- Pasi

 
> 
> >    - Rich
> > 
> >    On Wed, Dec 19, 2012 at 2:00 PM, Rich <[1]rercola@pha.jhu.edu> wrote:
> > 
> >      From the LSI P15 F/W release notes:
> >      SCGCQ00342805 (DFCT) Â - SlotStatus updates to SES managed Enclosure may
> >      update incorrect slots
> >      "Modified FW to use SES diag page 0Ah mapping only if SMP Discover
> >      DeviceSlotNum is used for Encl Phy Slot enumeration."
> >      SCGCQ00345867 (DFCT) Â - Channel NVDATA internal Phy reverse setting for
> >      9207-4i4e 9207-8i 9217-4i4e 9217-8i and 9201-16i
> >      "ISSUE DESC:Â Internal PHY orders are reversed for the channel boards
> >      above."
> >      So I would submit this is likely fixed by this FW rev.
> >      - Rich
> > 
> >      On Fri, Dec 7, 2012 at 8:46 AM, Pasi KÀrkkÀinen <[2]pasik@iki.fi>
> >      wrote:
> > 
> >        On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich wrote:
> >        > On Sun, Oct 21, 2012 at 8:46 AM, Pasi KÀrkkÀinen <[3]pasik@iki.fi>
> >        wrote:
> >        > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi KÀrkkÀinen wrote:
> >        > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote:
> >        > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi KÀrkkÀinen
> >        <[4]pasik@iki.fi> wrote:
> >        > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac
> >        wrote:
> >        > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
> >        > >> > >> Pasi KÀrkkÀinen <[5]pasik@iki.fi> écrivait:
> >        > >> > >>
> >        > >> > >> > Any replies from Supermicro/LSI ?
> >        > >> > >> >
> >        > >> > >>
> >        > >> > >> Only loosely related, but Supermicro replaced recently my
> >        846E26 (dual
> >        > >> > >> expander backplane) with 846E16 (single expander).
> >        Apparently they
> >        > >> > >> gave up getting the E26 to work properly or something: LSI
> >        expander
> >        > >> > >> firmware problem.
> >        > >> > >>
> >        > >> > >> In another (very large scale, high end) setup, many
> >        different 60 slots
> >        > >> > >> 5 LSI expanders chassis had a general failure of the 5th
> >        drawer.
> >        > >> > >> Another LSI SAS-2 expander firmware problem.
> >        > >> > >>
> >        > >> > >> I could start a rant about the evil of proprietary firmware,
> >        etc. You
> >        > >> > >> get my meaning :)
> >        > >> > >>
> >        > >> > >
> >        > >> > > Yeah, this is a good example why we're trying to get the LEDs
> >        working with
> >        > >> > > direct attach (non-expander) backplanes :)
> >        > >> > >
> >        > >> > > -- Pasi
> >        > >> > >
> >        > >> >
> >        > >> > I don't have anything useful for people, other than that they
> >        have
> >        > >> > shown me an HBA firmware that fixes the LED problem but has
> >        other
> >        > >> > problems they're still debugging.
> >        > >> >
> >        > >> > So there does exist code for this firmware which will fix this
> >        problem.
> >        > >> >
> >        > >>
> >        > >> That's good to know! Let's hope the fix ends up in an official
> >        > >> LSI HBA firmware update in not-so-distant future.
> >        > >>
> >        > >
> >        > > Btw what was the version number of the LED-fixed LSI firmware?
> >        > > I'm just wondering in which firmware series the fix might end up
> >        being included..
> >        > >
> >        > > Also: Any updates on this?
> >        > >
> >        > > Thanks,
> >        > >
> >        > > -- Pasi
> >        > >
> >        >
> >        > The fixed FW I had demonstrated for me was still 14.0.0.0 - I've
> >        been
> >        > told it'll be rolled into the FW release currently on the site and
> >        > posted at some point, but that they have no ETA for that.
> >        >
> > 
> >        I can now see P15 firmware available on LSI's website for 9211-8i
> >        (SAS2008 based HBA).
> >        Sadly it's missing the releasenotes/changelogs for both the LSI bios
> >        and firmware..
> >        -- Pasi
> > 
> > References
> > 
> >    Visible links
> >    1. mailto:rercola@pha.jhu.edu
> >    2. mailto:pasik@iki.fi
> >    3. mailto:pasik@iki.fi
> >    4. mailto:pasik@iki.fi
> >    5. mailto:pasik@iki.fi
> --
> 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
--
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

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

[Pasi Kärkkäinen]

On Mon, Apr 22, 2013 at 08:28:58PM -0400, Rich wrote:
>    I'm told that the fix won't actually be in until P17, because it involved
>    touching a large number of codepaths, but that it will be in P17.
>

That's unfortunate.. so another 5-6 months.

Thanks for the info!

-- Pasi

>    - Rich
> 
>    On Mon, Apr 22, 2013 at 8:19 PM, Pasi KÀrkkÀinen <[1]pasik@iki.fi>
>    wrote:
> 
>      On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi KÀrkkÀinen wrote:
>      > On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
>      > > Â  Â Nope, I'm wrong.
>      >
>      > :(
>      >
>      > > Â  Â I flashed P15 on a machine, and the same behavior persisted,
>      right up to
>      > > Â  Â and including the "groups of 3 devices light up when I do my
>      own
>      > > Â  Â smp_write_gpio".
>      > > Â  Â Whereas if I flash the experimental blob I was handed by
>      support to try
>      > > Â  Â and confirm they had resolved the issue, it does the correct
>      thing.
>      > > Â  Â I wonder why this change didn't make it into P15.
>      >
>      > Hmm.. if you have open contact channel with LSI support please ask
>      them..
>      > it'd be nice to get the fix for wider audience..
>      >
> 
>      It seems LSI P16 firmware has been released.. in the FW changelog I can
>      see at least this:
> 
>      "Disable SGPIO Group ID support in Channel NVDATA XML's. This allows the
>      use of manufacturing page 7 or default slot mapping setting for direct
>      connected drive slots."
> 
>      -- Pasi
> 
>      >
>      > > Â  Â - Rich
>      > >
>      > > Â  Â On Wed, Dec 19, 2012 at 2:00 PM, Rich
>      <[1][2]rercola@pha.jhu.edu> wrote:
>      > >
>      > > Â  Â  Â From the LSI P15 F/W release notes:
>      > > Â  Â  Â SCGCQ00342805 (DFCT) Ã* - SlotStatus updates to SES managed
>      Enclosure may
>      > > Â  Â  Â update incorrect slots
>      > > Â  Â  Â "Modified FW to use SES diag page 0Ah mapping only if SMP
>      Discover
>      > > Â  Â  Â DeviceSlotNum is used for Encl PhyÃ* Slot enumeration."
>      > > Â  Â  Â SCGCQ00345867 (DFCT) Ã* - Channel NVDATA internal Phy
>      reverse setting for
>      > > Â  Â  Â 9207-4i4e 9207-8i 9217-4i4eÃ* 9217-8i and 9201-16i
>      > > Â  Â  Â "ISSUE DESC:Ã* Internal PHY orders are reversed for the
>      channel boards
>      > > Â  Â  Â above."
>      > > Â  Â  Â So I would submit this is likely fixed by this FW rev.
>      > > Â  Â  Â - Rich
>      > >
>      > > Â  Â  Â On Fri, Dec 7, 2012 at 8:46 AM, Pasi KÃ*â*¬rkkÃ*â*¬inen
>      <[2][3]pasik@iki.fi>
>      > > Â  Â  Â wrote:
>      > >
>      > > Â  Â  Â  Â On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich wrote:
>      > > Â  Â  Â  Â > On Sun, Oct 21, 2012 at 8:46 AM, Pasi
>      KÃ*â*¬rkkÃ*â*¬inen <[3][4]pasik@iki.fi>
>      > > Â  Â  Â  Â wrote:
>      > > Â  Â  Â  Â > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi
>      KÃ*â*¬rkkÃ*â*¬inen wrote:
>      > > Â  Â  Â  Â > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich
>      wrote:
>      > > Â  Â  Â  Â > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi
>      KÃ*â*¬rkkÃ*â*¬inen
>      > > Â  Â  Â  Â <[4][5]pasik@iki.fi> wrote:
>      > > Â  Â  Â  Â > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200,
>      Emmanuel Florac
>      > > Â  Â  Â  Â wrote:
>      > > Â  Â  Â  Â > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
>      > > Â  Â  Â  Â > >> > >> Pasi KÃ*â*¬rkkÃ*â*¬inen <[5][6]pasik@iki.fi>
>      Ã*©crivait:
>      > > Â  Â  Â  Â > >> > >>
>      > > Â  Â  Â  Â > >> > >> > Any replies from Supermicro/LSI ?
>      > > Â  Â  Â  Â > >> > >> >
>      > > Â  Â  Â  Â > >> > >>
>      > > Â  Â  Â  Â > >> > >> Only loosely related, but Supermicro replaced
>      recently my
>      > > Â  Â  Â  Â 846E26 (dual
>      > > Â  Â  Â  Â > >> > >> expander backplane) with 846E16 (single
>      expander).
>      > > Â  Â  Â  Â Apparently they
>      > > Â  Â  Â  Â > >> > >> gave up getting the E26 to work properly or
>      something: LSI
>      > > Â  Â  Â  Â expander
>      > > Â  Â  Â  Â > >> > >> firmware problem.
>      > > Â  Â  Â  Â > >> > >>
>      > > Â  Â  Â  Â > >> > >> In another (very large scale, high end) setup,
>      many
>      > > Â  Â  Â  Â different 60 slots
>      > > Â  Â  Â  Â > >> > >> 5 LSI expanders chassis had a general failure
>      of the 5th
>      > > Â  Â  Â  Â drawer.
>      > > Â  Â  Â  Â > >> > >> Another LSI SAS-2 expander firmware problem.
>      > > Â  Â  Â  Â > >> > >>
>      > > Â  Â  Â  Â > >> > >> I could start a rant about the evil of
>      proprietary firmware,
>      > > Â  Â  Â  Â etc. You
>      > > Â  Â  Â  Â > >> > >> get my meaning :)
>      > > Â  Â  Â  Â > >> > >>
>      > > Â  Â  Â  Â > >> > >
>      > > Â  Â  Â  Â > >> > > Yeah, this is a good example why we're trying to
>      get the LEDs
>      > > Â  Â  Â  Â working with
>      > > Â  Â  Â  Â > >> > > direct attach (non-expander) backplanes :)
>      > > Â  Â  Â  Â > >> > >
>      > > Â  Â  Â  Â > >> > > -- Pasi
>      > > Â  Â  Â  Â > >> > >
>      > > Â  Â  Â  Â > >> >
>      > > Â  Â  Â  Â > >> > I don't have anything useful for people, other
>      than that they
>      > > Â  Â  Â  Â have
>      > > Â  Â  Â  Â > >> > shown me an HBA firmware that fixes the LED
>      problem but has
>      > > Â  Â  Â  Â other
>      > > Â  Â  Â  Â > >> > problems they're still debugging.
>      > > Â  Â  Â  Â > >> >
>      > > Â  Â  Â  Â > >> > So there does exist code for this firmware which
>      will fix this
>      > > Â  Â  Â  Â problem.
>      > > Â  Â  Â  Â > >> >
>      > > Â  Â  Â  Â > >>
>      > > Â  Â  Â  Â > >> That's good to know! Let's hope the fix ends up in
>      an official
>      > > Â  Â  Â  Â > >> LSI HBA firmware update in not-so-distant future.
>      > > Â  Â  Â  Â > >>
>      > > Â  Â  Â  Â > >
>      > > Â  Â  Â  Â > > Btw what was the version number of the LED-fixed LSI
>      firmware?
>      > > Â  Â  Â  Â > > I'm just wondering in which firmware series the fix
>      might end up
>      > > Â  Â  Â  Â being included..
>      > > Â  Â  Â  Â > >
>      > > Â  Â  Â  Â > > Also: Any updates on this?
>      > > Â  Â  Â  Â > >
>      > > Â  Â  Â  Â > > Thanks,
>      > > Â  Â  Â  Â > >
>      > > Â  Â  Â  Â > > -- Pasi
>      > > Â  Â  Â  Â > >
>      > > Â  Â  Â  Â >
>      > > Â  Â  Â  Â > The fixed FW I had demonstrated for me was still
>      14.0.0.0 - I've
>      > > Â  Â  Â  Â been
>      > > Â  Â  Â  Â > told it'll be rolled into the FW release currently on
>      the site and
>      > > Â  Â  Â  Â > posted at some point, but that they have no ETA for
>      that.
>      > > Â  Â  Â  Â >
>      > >
>      > > Â  Â  Â  Â I can now see P15 firmware available on LSI's website for
>      9211-8i
>      > > Â  Â  Â  Â (SAS2008 based HBA).
>      > > Â  Â  Â  Â Sadly it's missing the releasenotes/changelogs for both
>      the LSI bios
>      > > Â  Â  Â  Â and firmware..
>      > > Â  Â  Â  Â -- Pasi
>      > >
>      > > References
>      > >
>      > > Â  Â Visible links
>      > > Â  Â 1. mailto:[7]rercola@pha.jhu.edu
>      > > Â  Â 2. mailto:[8]pasik@iki.fi
>      > > Â  Â 3. mailto:[9]pasik@iki.fi
>      > > Â  Â 4. mailto:[10]pasik@iki.fi
>      > > Â  Â 5. mailto:[11]pasik@iki.fi
>      > --
>      > To unsubscribe from this list: send the line "unsubscribe linux-scsi"
>      in
>      > the body of a message to [12]majordomo@vger.kernel.org
>      > More majordomo info at
>      Â [13]http://vger.kernel.org/majordomo-info.html
> 
> References
> 
>    Visible links
>    1. mailto:pasik@iki.fi
>    2. mailto:rercola@pha.jhu.edu
>    3. mailto:pasik@iki.fi
>    4. mailto:pasik@iki.fi
>    5. mailto:pasik@iki.fi
>    6. mailto:pasik@iki.fi
>    7. mailto:rercola@pha.jhu.edu
>    8. mailto:pasik@iki.fi
>    9. mailto:pasik@iki.fi
>   10. mailto:pasik@iki.fi
>   11. mailto:pasik@iki.fi
>   12. mailto:majordomo@vger.kernel.org
>   13. http://vger.kernel.org/majordomo-info.html
--
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

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

[Rich]

Resending as plain-text (hopefully) so linux-scsi doesn't bounce it...

Apparently, only about 4 months.

P17 firmware is out.

Tested on a card which was demonstrating the incorrect behavior
before, of model 9201-16i.

It does appear to contain the fixes for this problem.

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

[Pasi Kärkkäinen]

On Fri, Aug 30, 2013 at 05:38:04PM -0400, Rich wrote:
>    Apparently, only about 4 months.
>    P17 firmware is out.
>    Tested on a card which was demonstrating the incorrect behavior before, of
>    model 9201-16i.
>    It does appear to contain the fixes for this problem.

This is great news, finally! 
Thanks for testing and reporting!

-- Pasi

>    - Rich
> 
>    On Mon, Apr 22, 2013 at 8:39 PM, Pasi Kärkkäinen <[1]pasik@iki.fi> wrote:
> 
>      On Mon, Apr 22, 2013 at 08:28:58PM -0400, Rich wrote:
>      >    I'm told that the fix won't actually be in until P17, because it
>      involved
>      >    touching a large number of codepaths, but that it will be in P17.
>      >
> 
>      That's unfortunate.. so another 5-6 months.
> 
>      Thanks for the info!
> 
>      -- Pasi
> 
>      >    - Rich
>      >
>      >    On Mon, Apr 22, 2013 at 8:19 PM, Pasi KÃ*rkkÃ*inen
>      <[1][2]pasik@iki.fi>
>      >    wrote:
>      >
>      >      On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi KÃ*rkkÃ*inen
>      wrote:
>      >      > On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
>      >      > > Â  Â Nope, I'm wrong.
>      >      >
>      >      > :(
>      >      >
>      >      > > Â  Â I flashed P15 on a machine, and the same behavior
>      persisted,
>      >      right up to
>      >      > > Â  Â and including the "groups of 3 devices light up when I
>      do my
>      >      own
>      >      > > Â  Â smp_write_gpio".
>      >      > > Â  Â Whereas if I flash the experimental blob I was handed by
>      >      support to try
>      >      > > Â  Â and confirm they had resolved the issue, it does the
>      correct
>      >      thing.
>      >      > > Â  Â I wonder why this change didn't make it into P15.
>      >      >
>      >      > Hmm.. if you have open contact channel with LSI support please
>      ask
>      >      them..
>      >      > it'd be nice to get the fix for wider audience..
>      >      >
>      >
>      >      It seems LSI P16 firmware has been released.. in the FW changelog
>      I can
>      >      see at least this:
>      >
>      >      "Disable SGPIO Group ID support in Channel NVDATA XML's. This
>      allows the
>      >      use of manufacturing page 7 or default slot mapping setting for
>      direct
>      >      connected drive slots."
>      >
>      >      -- Pasi
>      >
>      >      >
>      >      > > Â  Â - Rich
>      >      > >
>      >      > > Â  Â On Wed, Dec 19, 2012 at 2:00 PM, Rich
>      >      <[1][2][3]rercola@pha.jhu.edu> wrote:
>      >      > >
>      >      > > Â  Â  Â From the LSI P15 F/W release notes:
>      >      > > Â  Â  Â SCGCQ00342805 (DFCT) Ã* - SlotStatus updates to SES
>      managed
>      >      Enclosure may
>      >      > > Â  Â  Â update incorrect slots
>      >      > > Â  Â  Â "Modified FW to use SES diag page 0Ah mapping only if
>      SMP
>      >      Discover
>      >      > > Â  Â  Â DeviceSlotNum is used for Encl PhyÃ* Slot
>      enumeration."
>      >      > > Â  Â  Â SCGCQ00345867 (DFCT) Ã* - Channel NVDATA internal Phy
>      >      reverse setting for
>      >      > > Â  Â  Â 9207-4i4e 9207-8i 9217-4i4eÃ* 9217-8i and 9201-16i
>      >      > > Â  Â  Â "ISSUE DESC:Ã* Internal PHY orders are reversed for
>      the
>      >      channel boards
>      >      > > Â  Â  Â above."
>      >      > > Â  Â  Â So I would submit this is likely fixed by this FW
>      rev.
>      >      > > Â  Â  Â - Rich
>      >      > >
>      >      > > Â  Â  Â On Fri, Dec 7, 2012 at 8:46 AM, Pasi
>      KÃ*â*¬rkkÃ*â*¬inen
>      >      <[2][3][4]pasik@iki.fi>
>      >      > > Â  Â  Â wrote:
>      >      > >
>      >      > > Â  Â  Â  Â On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich
>      wrote:
>      >      > > Â  Â  Â  Â > On Sun, Oct 21, 2012 at 8:46 AM, Pasi
>      >      KÃ*â*¬rkkÃ*â*¬inen <[3][4][5]pasik@iki.fi>
>      >      > > Â  Â  Â  Â wrote:
>      >      > > Â  Â  Â  Â > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi
>      >      KÃ*â*¬rkkÃ*â*¬inen wrote:
>      >      > > Â  Â  Â  Â > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400,
>      Rich
>      >      wrote:
>      >      > > Â  Â  Â  Â > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi
>      >      KÃ*â*¬rkkÃ*â*¬inen
>      >      > > Â  Â  Â  Â <[4][5][6]pasik@iki.fi> wrote:
>      >      > > Â  Â  Â  Â > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200,
>      >      Emmanuel Florac
>      >      > > Â  Â  Â  Â wrote:
>      >      > > Â  Â  Â  Â > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
>      >      > > Â  Â  Â  Â > >> > >> Pasi KÃ*â*¬rkkÃ*â*¬inen
>      <[5][6][7]pasik@iki.fi>
>      >      Ã*©crivait:
>      >      > > Â  Â  Â  Â > >> > >>
>      >      > > Â  Â  Â  Â > >> > >> > Any replies from Supermicro/LSI ?
>      >      > > Â  Â  Â  Â > >> > >> >
>      >      > > Â  Â  Â  Â > >> > >>
>      >      > > Â  Â  Â  Â > >> > >> Only loosely related, but Supermicro
>      replaced
>      >      recently my
>      >      > > Â  Â  Â  Â 846E26 (dual
>      >      > > Â  Â  Â  Â > >> > >> expander backplane) with 846E16 (single
>      >      expander).
>      >      > > Â  Â  Â  Â Apparently they
>      >      > > Â  Â  Â  Â > >> > >> gave up getting the E26 to work properly
>      or
>      >      something: LSI
>      >      > > Â  Â  Â  Â expander
>      >      > > Â  Â  Â  Â > >> > >> firmware problem.
>      >      > > Â  Â  Â  Â > >> > >>
>      >      > > Â  Â  Â  Â > >> > >> In another (very large scale, high end)
>      setup,
>      >      many
>      >      > > Â  Â  Â  Â different 60 slots
>      >      > > Â  Â  Â  Â > >> > >> 5 LSI expanders chassis had a general
>      failure
>      >      of the 5th
>      >      > > Â  Â  Â  Â drawer.
>      >      > > Â  Â  Â  Â > >> > >> Another LSI SAS-2 expander firmware
>      problem.
>      >      > > Â  Â  Â  Â > >> > >>
>      >      > > Â  Â  Â  Â > >> > >> I could start a rant about the evil of
>      >      proprietary firmware,
>      >      > > Â  Â  Â  Â etc. You
>      >      > > Â  Â  Â  Â > >> > >> get my meaning :)
>      >      > > Â  Â  Â  Â > >> > >>
>      >      > > Â  Â  Â  Â > >> > >
>      >      > > Â  Â  Â  Â > >> > > Yeah, this is a good example why we're
>      trying to
>      >      get the LEDs
>      >      > > Â  Â  Â  Â working with
>      >      > > Â  Â  Â  Â > >> > > direct attach (non-expander) backplanes
>      :)
>      >      > > Â  Â  Â  Â > >> > >
>      >      > > Â  Â  Â  Â > >> > > -- Pasi
>      >      > > Â  Â  Â  Â > >> > >
>      >      > > Â  Â  Â  Â > >> >
>      >      > > Â  Â  Â  Â > >> > I don't have anything useful for people,
>      other
>      >      than that they
>      >      > > Â  Â  Â  Â have
>      >      > > Â  Â  Â  Â > >> > shown me an HBA firmware that fixes the LED
>      >      problem but has
>      >      > > Â  Â  Â  Â other
>      >      > > Â  Â  Â  Â > >> > problems they're still debugging.
>      >      > > Â  Â  Â  Â > >> >
>      >      > > Â  Â  Â  Â > >> > So there does exist code for this firmware
>      which
>      >      will fix this
>      >      > > Â  Â  Â  Â problem.
>      >      > > Â  Â  Â  Â > >> >
>      >      > > Â  Â  Â  Â > >>
>      >      > > Â  Â  Â  Â > >> That's good to know! Let's hope the fix ends
>      up in
>      >      an official
>      >      > > Â  Â  Â  Â > >> LSI HBA firmware update in not-so-distant
>      future.
>      >      > > Â  Â  Â  Â > >>
>      >      > > Â  Â  Â  Â > >
>      >      > > Â  Â  Â  Â > > Btw what was the version number of the
>      LED-fixed LSI
>      >      firmware?
>      >      > > Â  Â  Â  Â > > I'm just wondering in which firmware series
>      the fix
>      >      might end up
>      >      > > Â  Â  Â  Â being included..
>      >      > > Â  Â  Â  Â > >
>      >      > > Â  Â  Â  Â > > Also: Any updates on this?
>      >      > > Â  Â  Â  Â > >
>      >      > > Â  Â  Â  Â > > Thanks,
>      >      > > Â  Â  Â  Â > >
>      >      > > Â  Â  Â  Â > > -- Pasi
>      >      > > Â  Â  Â  Â > >
>      >      > > Â  Â  Â  Â >
>      >      > > Â  Â  Â  Â > The fixed FW I had demonstrated for me was still
>      >      14.0.0.0 - I've
>      >      > > Â  Â  Â  Â been
>      >      > > Â  Â  Â  Â > told it'll be rolled into the FW release
>      currently on
>      >      the site and
>      >      > > Â  Â  Â  Â > posted at some point, but that they have no ETA
>      for
>      >      that.
>      >      > > Â  Â  Â  Â >
>      >      > >
>      >      > > Â  Â  Â  Â I can now see P15 firmware available on LSI's
>      website for
>      >      9211-8i
>      >      > > Â  Â  Â  Â (SAS2008 based HBA).
>      >      > > Â  Â  Â  Â Sadly it's missing the releasenotes/changelogs for
>      both
>      >      the LSI bios
>      >      > > Â  Â  Â  Â and firmware..
>      >      > > Â  Â  Â  Â -- Pasi
>      >      > >
>      >      > > References
>      >      > >
>      >      > > Â  Â Visible links
>      >      > > Â  Â 1. mailto:[7][8]rercola@pha.jhu.edu
>      >      > > Â  Â 2. mailto:[8][9]pasik@iki.fi
>      >      > > Â  Â 3. mailto:[9][10]pasik@iki.fi
>      >      > > Â  Â 4. mailto:[10][11]pasik@iki.fi
>      >      > > Â  Â 5. mailto:[11][12]pasik@iki.fi
>      >      > --
>      >      > To unsubscribe from this list: send the line "unsubscribe
>      linux-scsi"
>      >      in
>      >      > the body of a message to [12][13]majordomo@vger.kernel.org
>      >      > More majordomo info at
>      >      Â [13][14]http://vger.kernel.org/majordomo-info.html
>      >
>      > References
>      >
>      >    Visible links
>      >    1. mailto:[15]pasik@iki.fi
>      >    2. mailto:[16]rercola@pha.jhu.edu
>      >    3. mailto:[17]pasik@iki.fi
>      >    4. mailto:[18]pasik@iki.fi
>      >    5. mailto:[19]pasik@iki.fi
>      >    6. mailto:[20]pasik@iki.fi
>      >    7. mailto:[21]rercola@pha.jhu.edu
>      >    8. mailto:[22]pasik@iki.fi
>      >    9. mailto:[23]pasik@iki.fi
>      >   10. mailto:[24]pasik@iki.fi
>      >   11. mailto:[25]pasik@iki.fi
>      >   12. mailto:[26]majordomo@vger.kernel.org
>      >   13. [27]http://vger.kernel.org/majordomo-info.html
> 
> References
> 
>    Visible links
>    1. mailto:pasik@iki.fi
>    2. mailto:pasik@iki.fi
>    3. mailto:rercola@pha.jhu.edu
>    4. mailto:pasik@iki.fi
>    5. mailto:pasik@iki.fi
>    6. mailto:pasik@iki.fi
>    7. mailto:pasik@iki.fi
>    8. mailto:rercola@pha.jhu.edu
>    9. mailto:pasik@iki.fi
>   10. mailto:pasik@iki.fi
>   11. mailto:pasik@iki.fi
>   12. mailto:pasik@iki.fi
>   13. mailto:majordomo@vger.kernel.org
>   14. http://vger.kernel.org/majordomo-info.html
>   15. mailto:pasik@iki.fi
>   16. mailto:rercola@pha.jhu.edu
>   17. mailto:pasik@iki.fi
>   18. mailto:pasik@iki.fi
>   19. mailto:pasik@iki.fi
>   20. mailto:pasik@iki.fi
>   21. mailto:rercola@pha.jhu.edu
>   22. mailto:pasik@iki.fi
>   23. mailto:pasik@iki.fi
>   24. mailto:pasik@iki.fi
>   25. mailto:pasik@iki.fi
>   26. mailto:majordomo@vger.kernel.org
>   27. http://vger.kernel.org/majordomo-info.html
--
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

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

[Pasi Kärkkäinen]

On Sun, Sep 01, 2013 at 08:13:02PM +0300, Pasi Kärkkäinen wrote:
> On Fri, Aug 30, 2013 at 05:38:04PM -0400, Rich wrote:
> >    Apparently, only about 4 months.
> >    P17 firmware is out.
> >    Tested on a card which was demonstrating the incorrect behavior before, of
> >    model 9201-16i.
> >    It does appear to contain the fixes for this problem.
> 
> This is great news, finally! 
> Thanks for testing and reporting!
>

Hmm, I checked the P17 firmware changelog PDFs for LSI 9211-8i, 9207-8i and 9201-16i,
and I can't see anything about this issue being fixed.. 

But if you say it's now fixed, then I guess it means LSI doesn't list every change in the changelog..

-- Pasi
 
> 
> >    - Rich
> > 
> >    On Mon, Apr 22, 2013 at 8:39 PM, Pasi Kärkkäinen <[1]pasik@iki.fi> wrote:
> > 
> >      On Mon, Apr 22, 2013 at 08:28:58PM -0400, Rich wrote:
> >      >    I'm told that the fix won't actually be in until P17, because it
> >      involved
> >      >    touching a large number of codepaths, but that it will be in P17.
> >      >
> > 
> >      That's unfortunate.. so another 5-6 months.
> > 
> >      Thanks for the info!
> > 
> >      -- Pasi
> > 
> >      >    - Rich
> >      >
> >      >    On Mon, Apr 22, 2013 at 8:19 PM, Pasi KÃ*rkkÃ*inen
> >      <[1][2]pasik@iki.fi>
> >      >    wrote:
> >      >
> >      >      On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi KÃ*rkkÃ*inen
> >      wrote:
> >      >      > On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
> >      >      > > Â  Â Nope, I'm wrong.
> >      >      >
> >      >      > :(
> >      >      >
> >      >      > > Â  Â I flashed P15 on a machine, and the same behavior
> >      persisted,
> >      >      right up to
> >      >      > > Â  Â and including the "groups of 3 devices light up when I
> >      do my
> >      >      own
> >      >      > > Â  Â smp_write_gpio".
> >      >      > > Â  Â Whereas if I flash the experimental blob I was handed by
> >      >      support to try
> >      >      > > Â  Â and confirm they had resolved the issue, it does the
> >      correct
> >      >      thing.
> >      >      > > Â  Â I wonder why this change didn't make it into P15.
> >      >      >
> >      >      > Hmm.. if you have open contact channel with LSI support please
> >      ask
> >      >      them..
> >      >      > it'd be nice to get the fix for wider audience..
> >      >      >
> >      >
> >      >      It seems LSI P16 firmware has been released.. in the FW changelog
> >      I can
> >      >      see at least this:
> >      >
> >      >      "Disable SGPIO Group ID support in Channel NVDATA XML's. This
> >      allows the
> >      >      use of manufacturing page 7 or default slot mapping setting for
> >      direct
> >      >      connected drive slots."
> >      >
> >      >      -- Pasi
> >      >
> >      >      >
> >      >      > > Â  Â - Rich
> >      >      > >
> >      >      > > Â  Â On Wed, Dec 19, 2012 at 2:00 PM, Rich
> >      >      <[1][2][3]rercola@pha.jhu.edu> wrote:
> >      >      > >
> >      >      > > Â  Â  Â From the LSI P15 F/W release notes:
> >      >      > > Â  Â  Â SCGCQ00342805 (DFCT) Ã* - SlotStatus updates to SES
> >      managed
> >      >      Enclosure may
> >      >      > > Â  Â  Â update incorrect slots
> >      >      > > Â  Â  Â "Modified FW to use SES diag page 0Ah mapping only if
> >      SMP
> >      >      Discover
> >      >      > > Â  Â  Â DeviceSlotNum is used for Encl PhyÃ* Slot
> >      enumeration."
> >      >      > > Â  Â  Â SCGCQ00345867 (DFCT) Ã* - Channel NVDATA internal Phy
> >      >      reverse setting for
> >      >      > > Â  Â  Â 9207-4i4e 9207-8i 9217-4i4eÃ* 9217-8i and 9201-16i
> >      >      > > Â  Â  Â "ISSUE DESC:Ã* Internal PHY orders are reversed for
> >      the
> >      >      channel boards
> >      >      > > Â  Â  Â above."
> >      >      > > Â  Â  Â So I would submit this is likely fixed by this FW
> >      rev.
> >      >      > > Â  Â  Â - Rich
> >      >      > >
> >      >      > > Â  Â  Â On Fri, Dec 7, 2012 at 8:46 AM, Pasi
> >      KÃ*â*¬rkkÃ*â*¬inen
> >      >      <[2][3][4]pasik@iki.fi>
> >      >      > > Â  Â  Â wrote:
> >      >      > >
> >      >      > > Â  Â  Â  Â On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich
> >      wrote:
> >      >      > > Â  Â  Â  Â > On Sun, Oct 21, 2012 at 8:46 AM, Pasi
> >      >      KÃ*â*¬rkkÃ*â*¬inen <[3][4][5]pasik@iki.fi>
> >      >      > > Â  Â  Â  Â wrote:
> >      >      > > Â  Â  Â  Â > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi
> >      >      KÃ*â*¬rkkÃ*â*¬inen wrote:
> >      >      > > Â  Â  Â  Â > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400,
> >      Rich
> >      >      wrote:
> >      >      > > Â  Â  Â  Â > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi
> >      >      KÃ*â*¬rkkÃ*â*¬inen
> >      >      > > Â  Â  Â  Â <[4][5][6]pasik@iki.fi> wrote:
> >      >      > > Â  Â  Â  Â > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200,
> >      >      Emmanuel Florac
> >      >      > > Â  Â  Â  Â wrote:
> >      >      > > Â  Â  Â  Â > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
> >      >      > > Â  Â  Â  Â > >> > >> Pasi KÃ*â*¬rkkÃ*â*¬inen
> >      <[5][6][7]pasik@iki.fi>
> >      >      Ã*©crivait:
> >      >      > > Â  Â  Â  Â > >> > >>
> >      >      > > Â  Â  Â  Â > >> > >> > Any replies from Supermicro/LSI ?
> >      >      > > Â  Â  Â  Â > >> > >> >
> >      >      > > Â  Â  Â  Â > >> > >>
> >      >      > > Â  Â  Â  Â > >> > >> Only loosely related, but Supermicro
> >      replaced
> >      >      recently my
> >      >      > > Â  Â  Â  Â 846E26 (dual
> >      >      > > Â  Â  Â  Â > >> > >> expander backplane) with 846E16 (single
> >      >      expander).
> >      >      > > Â  Â  Â  Â Apparently they
> >      >      > > Â  Â  Â  Â > >> > >> gave up getting the E26 to work properly
> >      or
> >      >      something: LSI
> >      >      > > Â  Â  Â  Â expander
> >      >      > > Â  Â  Â  Â > >> > >> firmware problem.
> >      >      > > Â  Â  Â  Â > >> > >>
> >      >      > > Â  Â  Â  Â > >> > >> In another (very large scale, high end)
> >      setup,
> >      >      many
> >      >      > > Â  Â  Â  Â different 60 slots
> >      >      > > Â  Â  Â  Â > >> > >> 5 LSI expanders chassis had a general
> >      failure
> >      >      of the 5th
> >      >      > > Â  Â  Â  Â drawer.
> >      >      > > Â  Â  Â  Â > >> > >> Another LSI SAS-2 expander firmware
> >      problem.
> >      >      > > Â  Â  Â  Â > >> > >>
> >      >      > > Â  Â  Â  Â > >> > >> I could start a rant about the evil of
> >      >      proprietary firmware,
> >      >      > > Â  Â  Â  Â etc. You
> >      >      > > Â  Â  Â  Â > >> > >> get my meaning :)
> >      >      > > Â  Â  Â  Â > >> > >>
> >      >      > > Â  Â  Â  Â > >> > >
> >      >      > > Â  Â  Â  Â > >> > > Yeah, this is a good example why we're
> >      trying to
> >      >      get the LEDs
> >      >      > > Â  Â  Â  Â working with
> >      >      > > Â  Â  Â  Â > >> > > direct attach (non-expander) backplanes
> >      :)
> >      >      > > Â  Â  Â  Â > >> > >
> >      >      > > Â  Â  Â  Â > >> > > -- Pasi
> >      >      > > Â  Â  Â  Â > >> > >
> >      >      > > Â  Â  Â  Â > >> >
> >      >      > > Â  Â  Â  Â > >> > I don't have anything useful for people,
> >      other
> >      >      than that they
> >      >      > > Â  Â  Â  Â have
> >      >      > > Â  Â  Â  Â > >> > shown me an HBA firmware that fixes the LED
> >      >      problem but has
> >      >      > > Â  Â  Â  Â other
> >      >      > > Â  Â  Â  Â > >> > problems they're still debugging.
> >      >      > > Â  Â  Â  Â > >> >
> >      >      > > Â  Â  Â  Â > >> > So there does exist code for this firmware
> >      which
> >      >      will fix this
> >      >      > > Â  Â  Â  Â problem.
> >      >      > > Â  Â  Â  Â > >> >
> >      >      > > Â  Â  Â  Â > >>
> >      >      > > Â  Â  Â  Â > >> That's good to know! Let's hope the fix ends
> >      up in
> >      >      an official
> >      >      > > Â  Â  Â  Â > >> LSI HBA firmware update in not-so-distant
> >      future.
> >      >      > > Â  Â  Â  Â > >>
> >      >      > > Â  Â  Â  Â > >
> >      >      > > Â  Â  Â  Â > > Btw what was the version number of the
> >      LED-fixed LSI
> >      >      firmware?
> >      >      > > Â  Â  Â  Â > > I'm just wondering in which firmware series
> >      the fix
> >      >      might end up
> >      >      > > Â  Â  Â  Â being included..
> >      >      > > Â  Â  Â  Â > >
> >      >      > > Â  Â  Â  Â > > Also: Any updates on this?
> >      >      > > Â  Â  Â  Â > >
> >      >      > > Â  Â  Â  Â > > Thanks,
> >      >      > > Â  Â  Â  Â > >
> >      >      > > Â  Â  Â  Â > > -- Pasi
> >      >      > > Â  Â  Â  Â > >
> >      >      > > Â  Â  Â  Â >
> >      >      > > Â  Â  Â  Â > The fixed FW I had demonstrated for me was still
> >      >      14.0.0.0 - I've
> >      >      > > Â  Â  Â  Â been
> >      >      > > Â  Â  Â  Â > told it'll be rolled into the FW release
> >      currently on
> >      >      the site and
> >      >      > > Â  Â  Â  Â > posted at some point, but that they have no ETA
> >      for
> >      >      that.
> >      >      > > Â  Â  Â  Â >
> >      >      > >
> >      >      > > Â  Â  Â  Â I can now see P15 firmware available on LSI's
> >      website for
> >      >      9211-8i
> >      >      > > Â  Â  Â  Â (SAS2008 based HBA).
> >      >      > > Â  Â  Â  Â Sadly it's missing the releasenotes/changelogs for
> >      both
> >      >      the LSI bios
> >      >      > > Â  Â  Â  Â and firmware..
> >      >      > > Â  Â  Â  Â -- Pasi
> >      >      > >
> >      >      > > References
> >      >      > >
> >      >      > > Â  Â Visible links
> >      >      > > Â  Â 1. mailto:[7][8]rercola@pha.jhu.edu
> >      >      > > Â  Â 2. mailto:[8][9]pasik@iki.fi
> >      >      > > Â  Â 3. mailto:[9][10]pasik@iki.fi
> >      >      > > Â  Â 4. mailto:[10][11]pasik@iki.fi
> >      >      > > Â  Â 5. mailto:[11][12]pasik@iki.fi
> >      >      > --
> >      >      > To unsubscribe from this list: send the line "unsubscribe
> >      linux-scsi"
> >      >      in
> >      >      > the body of a message to [12][13]majordomo@vger.kernel.org
> >      >      > More majordomo info at
> >      >      Â [13][14]http://vger.kernel.org/majordomo-info.html
> >      >
> >      > References
> >      >
> >      >    Visible links
> >      >    1. mailto:[15]pasik@iki.fi
> >      >    2. mailto:[16]rercola@pha.jhu.edu
> >      >    3. mailto:[17]pasik@iki.fi
> >      >    4. mailto:[18]pasik@iki.fi
> >      >    5. mailto:[19]pasik@iki.fi
> >      >    6. mailto:[20]pasik@iki.fi
> >      >    7. mailto:[21]rercola@pha.jhu.edu
> >      >    8. mailto:[22]pasik@iki.fi
> >      >    9. mailto:[23]pasik@iki.fi
> >      >   10. mailto:[24]pasik@iki.fi
> >      >   11. mailto:[25]pasik@iki.fi
> >      >   12. mailto:[26]majordomo@vger.kernel.org
> >      >   13. [27]http://vger.kernel.org/majordomo-info.html
> > 
> > References
> > 
> >    Visible links
> >    1. mailto:pasik@iki.fi
> >    2. mailto:pasik@iki.fi
> >    3. mailto:rercola@pha.jhu.edu
> >    4. mailto:pasik@iki.fi
> >    5. mailto:pasik@iki.fi
> >    6. mailto:pasik@iki.fi
> >    7. mailto:pasik@iki.fi
> >    8. mailto:rercola@pha.jhu.edu
> >    9. mailto:pasik@iki.fi
> >   10. mailto:pasik@iki.fi
> >   11. mailto:pasik@iki.fi
> >   12. mailto:pasik@iki.fi
> >   13. mailto:majordomo@vger.kernel.org
> >   14. http://vger.kernel.org/majordomo-info.html
> >   15. mailto:pasik@iki.fi
> >   16. mailto:rercola@pha.jhu.edu
> >   17. mailto:pasik@iki.fi
> >   18. mailto:pasik@iki.fi
> >   19. mailto:pasik@iki.fi
> >   20. mailto:pasik@iki.fi
> >   21. mailto:rercola@pha.jhu.edu
> >   22. mailto:pasik@iki.fi
> >   23. mailto:pasik@iki.fi
> >   24. mailto:pasik@iki.fi
> >   25. mailto:pasik@iki.fi
> >   26. mailto:majordomo@vger.kernel.org
> >   27. http://vger.kernel.org/majordomo-info.html
> --
> 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
--
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

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

[Pasi Kärkkäinen]

On Mon, Sep 02, 2013 at 05:44:35PM +0300, Pasi Kärkkäinen wrote:
> On Sun, Sep 01, 2013 at 08:13:02PM +0300, Pasi Kärkkäinen wrote:
> > On Fri, Aug 30, 2013 at 05:38:04PM -0400, Rich wrote:
> > >    Apparently, only about 4 months.
> > >    P17 firmware is out.
> > >    Tested on a card which was demonstrating the incorrect behavior before, of
> > >    model 9201-16i.
> > >    It does appear to contain the fixes for this problem.
> > 
> > This is great news, finally! 
> > Thanks for testing and reporting!
> >
> 
> Hmm, I checked the P17 firmware changelog PDFs for LSI 9211-8i, 9207-8i and 9201-16i,
> and I can't see anything about this issue being fixed.. 
> 
> But if you say it's now fixed, then I guess it means LSI doesn't list every change in the changelog..
> 

I just had some time today to test the new P17 IT firmware with LSI 9211-8i SAS HBAs.

It seems also the "LOCATE" function of LSI sas2ircu tool now actually works and makes 
the red/failure leds blink on the Supermicro passive (direct-attach) backplane! Finally.. 

Btw do you guys have any scripts/tools to control the LEDs on these passive backplanes? 
smp_read_gpio/smp_write_gpio isn't the most userfriendly interface ;) Should I try ledmon/ledctl? 

I can probably hack something myself too.. but there are many other tasks on the todo-list before this :)

Thanks,

-- Pasi

>  
> > 
> > >    - Rich
> > > 
> > >    On Mon, Apr 22, 2013 at 8:39 PM, Pasi Kärkkäinen <[1]pasik@iki.fi> wrote:
> > > 
> > >      On Mon, Apr 22, 2013 at 08:28:58PM -0400, Rich wrote:
> > >      >    I'm told that the fix won't actually be in until P17, because it
> > >      involved
> > >      >    touching a large number of codepaths, but that it will be in P17.
> > >      >
> > > 
> > >      That's unfortunate.. so another 5-6 months.
> > > 
> > >      Thanks for the info!
> > > 
> > >      -- Pasi
> > > 
> > >      >    - Rich
> > >      >
> > >      >    On Mon, Apr 22, 2013 at 8:19 PM, Pasi KÃ*rkkÃ*inen
> > >      <[1][2]pasik@iki.fi>
> > >      >    wrote:
> > >      >
> > >      >      On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi KÃ*rkkÃ*inen
> > >      wrote:
> > >      >      > On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
> > >      >      > > Â  Â Nope, I'm wrong.
> > >      >      >
> > >      >      > :(
> > >      >      >
> > >      >      > > Â  Â I flashed P15 on a machine, and the same behavior
> > >      persisted,
> > >      >      right up to
> > >      >      > > Â  Â and including the "groups of 3 devices light up when I
> > >      do my
> > >      >      own
> > >      >      > > Â  Â smp_write_gpio".
> > >      >      > > Â  Â Whereas if I flash the experimental blob I was handed by
> > >      >      support to try
> > >      >      > > Â  Â and confirm they had resolved the issue, it does the
> > >      correct
> > >      >      thing.
> > >      >      > > Â  Â I wonder why this change didn't make it into P15.
> > >      >      >
> > >      >      > Hmm.. if you have open contact channel with LSI support please
> > >      ask
> > >      >      them..
> > >      >      > it'd be nice to get the fix for wider audience..
> > >      >      >
> > >      >
> > >      >      It seems LSI P16 firmware has been released.. in the FW changelog
> > >      I can
> > >      >      see at least this:
> > >      >
> > >      >      "Disable SGPIO Group ID support in Channel NVDATA XML's. This
> > >      allows the
> > >      >      use of manufacturing page 7 or default slot mapping setting for
> > >      direct
> > >      >      connected drive slots."
> > >      >
> > >      >      -- Pasi
> > >      >
> > >      >      >
> > >      >      > > Â  Â - Rich
> > >      >      > >
> > >      >      > > Â  Â On Wed, Dec 19, 2012 at 2:00 PM, Rich
> > >      >      <[1][2][3]rercola@pha.jhu.edu> wrote:
> > >      >      > >
> > >      >      > > Â  Â  Â From the LSI P15 F/W release notes:
> > >      >      > > Â  Â  Â SCGCQ00342805 (DFCT) Ã* - SlotStatus updates to SES
> > >      managed
> > >      >      Enclosure may
> > >      >      > > Â  Â  Â update incorrect slots
> > >      >      > > Â  Â  Â "Modified FW to use SES diag page 0Ah mapping only if
> > >      SMP
> > >      >      Discover
> > >      >      > > Â  Â  Â DeviceSlotNum is used for Encl PhyÃ* Slot
> > >      enumeration."
> > >      >      > > Â  Â  Â SCGCQ00345867 (DFCT) Ã* - Channel NVDATA internal Phy
> > >      >      reverse setting for
> > >      >      > > Â  Â  Â 9207-4i4e 9207-8i 9217-4i4eÃ* 9217-8i and 9201-16i
> > >      >      > > Â  Â  Â "ISSUE DESC:Ã* Internal PHY orders are reversed for
> > >      the
> > >      >      channel boards
> > >      >      > > Â  Â  Â above."
> > >      >      > > Â  Â  Â So I would submit this is likely fixed by this FW
> > >      rev.
> > >      >      > > Â  Â  Â - Rich
> > >      >      > >
> > >      >      > > Â  Â  Â On Fri, Dec 7, 2012 at 8:46 AM, Pasi
> > >      KÃ*â*¬rkkÃ*â*¬inen
> > >      >      <[2][3][4]pasik@iki.fi>
> > >      >      > > Â  Â  Â wrote:
> > >      >      > >
> > >      >      > > Â  Â  Â  Â On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich
> > >      wrote:
> > >      >      > > Â  Â  Â  Â > On Sun, Oct 21, 2012 at 8:46 AM, Pasi
> > >      >      KÃ*â*¬rkkÃ*â*¬inen <[3][4][5]pasik@iki.fi>
> > >      >      > > Â  Â  Â  Â wrote:
> > >      >      > > Â  Â  Â  Â > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi
> > >      >      KÃ*â*¬rkkÃ*â*¬inen wrote:
> > >      >      > > Â  Â  Â  Â > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400,
> > >      Rich
> > >      >      wrote:
> > >      >      > > Â  Â  Â  Â > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi
> > >      >      KÃ*â*¬rkkÃ*â*¬inen
> > >      >      > > Â  Â  Â  Â <[4][5][6]pasik@iki.fi> wrote:
> > >      >      > > Â  Â  Â  Â > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200,
> > >      >      Emmanuel Florac
> > >      >      > > Â  Â  Â  Â wrote:
> > >      >      > > Â  Â  Â  Â > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
> > >      >      > > Â  Â  Â  Â > >> > >> Pasi KÃ*â*¬rkkÃ*â*¬inen
> > >      <[5][6][7]pasik@iki.fi>
> > >      >      Ã*©crivait:
> > >      >      > > Â  Â  Â  Â > >> > >>
> > >      >      > > Â  Â  Â  Â > >> > >> > Any replies from Supermicro/LSI ?
> > >      >      > > Â  Â  Â  Â > >> > >> >
> > >      >      > > Â  Â  Â  Â > >> > >>
> > >      >      > > Â  Â  Â  Â > >> > >> Only loosely related, but Supermicro
> > >      replaced
> > >      >      recently my
> > >      >      > > Â  Â  Â  Â 846E26 (dual
> > >      >      > > Â  Â  Â  Â > >> > >> expander backplane) with 846E16 (single
> > >      >      expander).
> > >      >      > > Â  Â  Â  Â Apparently they
> > >      >      > > Â  Â  Â  Â > >> > >> gave up getting the E26 to work properly
> > >      or
> > >      >      something: LSI
> > >      >      > > Â  Â  Â  Â expander
> > >      >      > > Â  Â  Â  Â > >> > >> firmware problem.
> > >      >      > > Â  Â  Â  Â > >> > >>
> > >      >      > > Â  Â  Â  Â > >> > >> In another (very large scale, high end)
> > >      setup,
> > >      >      many
> > >      >      > > Â  Â  Â  Â different 60 slots
> > >      >      > > Â  Â  Â  Â > >> > >> 5 LSI expanders chassis had a general
> > >      failure
> > >      >      of the 5th
> > >      >      > > Â  Â  Â  Â drawer.
> > >      >      > > Â  Â  Â  Â > >> > >> Another LSI SAS-2 expander firmware
> > >      problem.
> > >      >      > > Â  Â  Â  Â > >> > >>
> > >      >      > > Â  Â  Â  Â > >> > >> I could start a rant about the evil of
> > >      >      proprietary firmware,
> > >      >      > > Â  Â  Â  Â etc. You
> > >      >      > > Â  Â  Â  Â > >> > >> get my meaning :)
> > >      >      > > Â  Â  Â  Â > >> > >>
> > >      >      > > Â  Â  Â  Â > >> > >
> > >      >      > > Â  Â  Â  Â > >> > > Yeah, this is a good example why we're
> > >      trying to
> > >      >      get the LEDs
> > >      >      > > Â  Â  Â  Â working with
> > >      >      > > Â  Â  Â  Â > >> > > direct attach (non-expander) backplanes
> > >      :)
> > >      >      > > Â  Â  Â  Â > >> > >
> > >      >      > > Â  Â  Â  Â > >> > > -- Pasi
> > >      >      > > Â  Â  Â  Â > >> > >
> > >      >      > > Â  Â  Â  Â > >> >
> > >      >      > > Â  Â  Â  Â > >> > I don't have anything useful for people,
> > >      other
> > >      >      than that they
> > >      >      > > Â  Â  Â  Â have
> > >      >      > > Â  Â  Â  Â > >> > shown me an HBA firmware that fixes the LED
> > >      >      problem but has
> > >      >      > > Â  Â  Â  Â other
> > >      >      > > Â  Â  Â  Â > >> > problems they're still debugging.
> > >      >      > > Â  Â  Â  Â > >> >
> > >      >      > > Â  Â  Â  Â > >> > So there does exist code for this firmware
> > >      which
> > >      >      will fix this
> > >      >      > > Â  Â  Â  Â problem.
> > >      >      > > Â  Â  Â  Â > >> >
> > >      >      > > Â  Â  Â  Â > >>
> > >      >      > > Â  Â  Â  Â > >> That's good to know! Let's hope the fix ends
> > >      up in
> > >      >      an official
> > >      >      > > Â  Â  Â  Â > >> LSI HBA firmware update in not-so-distant
> > >      future.
> > >      >      > > Â  Â  Â  Â > >>
> > >      >      > > Â  Â  Â  Â > >
> > >      >      > > Â  Â  Â  Â > > Btw what was the version number of the
> > >      LED-fixed LSI
> > >      >      firmware?
> > >      >      > > Â  Â  Â  Â > > I'm just wondering in which firmware series
> > >      the fix
> > >      >      might end up
> > >      >      > > Â  Â  Â  Â being included..
> > >      >      > > Â  Â  Â  Â > >
> > >      >      > > Â  Â  Â  Â > > Also: Any updates on this?
> > >      >      > > Â  Â  Â  Â > >
> > >      >      > > Â  Â  Â  Â > > Thanks,
> > >      >      > > Â  Â  Â  Â > >
> > >      >      > > Â  Â  Â  Â > > -- Pasi
> > >      >      > > Â  Â  Â  Â > >
> > >      >      > > Â  Â  Â  Â >
> > >      >      > > Â  Â  Â  Â > The fixed FW I had demonstrated for me was still
> > >      >      14.0.0.0 - I've
> > >      >      > > Â  Â  Â  Â been
> > >      >      > > Â  Â  Â  Â > told it'll be rolled into the FW release
> > >      currently on
> > >      >      the site and
> > >      >      > > Â  Â  Â  Â > posted at some point, but that they have no ETA
> > >      for
> > >      >      that.
> > >      >      > > Â  Â  Â  Â >
> > >      >      > >
> > >      >      > > Â  Â  Â  Â I can now see P15 firmware available on LSI's
> > >      website for
> > >      >      9211-8i
> > >      >      > > Â  Â  Â  Â (SAS2008 based HBA).
> > >      >      > > Â  Â  Â  Â Sadly it's missing the releasenotes/changelogs for
> > >      both
> > >      >      the LSI bios
> > >      >      > > Â  Â  Â  Â and firmware..
> > >      >      > > Â  Â  Â  Â -- Pasi
> > >      >      > >
> > >      >      > > References
> > >      >      > >
> > >      >      > > Â  Â Visible links
> > >      >      > > Â  Â 1. mailto:[7][8]rercola@pha.jhu.edu
> > >      >      > > Â  Â 2. mailto:[8][9]pasik@iki.fi
> > >      >      > > Â  Â 3. mailto:[9][10]pasik@iki.fi
> > >      >      > > Â  Â 4. mailto:[10][11]pasik@iki.fi
> > >      >      > > Â  Â 5. mailto:[11][12]pasik@iki.fi
> > >      >      > --
> > >      >      > To unsubscribe from this list: send the line "unsubscribe
> > >      linux-scsi"
> > >      >      in
> > >      >      > the body of a message to [12][13]majordomo@vger.kernel.org
> > >      >      > More majordomo info at
> > >      >      Â [13][14]http://vger.kernel.org/majordomo-info.html
> > >      >
> > >      > References
> > >      >
> > >      >    Visible links
> > >      >    1. mailto:[15]pasik@iki.fi
> > >      >    2. mailto:[16]rercola@pha.jhu.edu
> > >      >    3. mailto:[17]pasik@iki.fi
> > >      >    4. mailto:[18]pasik@iki.fi
> > >      >    5. mailto:[19]pasik@iki.fi
> > >      >    6. mailto:[20]pasik@iki.fi
> > >      >    7. mailto:[21]rercola@pha.jhu.edu
> > >      >    8. mailto:[22]pasik@iki.fi
> > >      >    9. mailto:[23]pasik@iki.fi
> > >      >   10. mailto:[24]pasik@iki.fi
> > >      >   11. mailto:[25]pasik@iki.fi
> > >      >   12. mailto:[26]majordomo@vger.kernel.org
> > >      >   13. [27]http://vger.kernel.org/majordomo-info.html
> > > 
> > > References
> > > 
> > >    Visible links
> > >    1. mailto:pasik@iki.fi
> > >    2. mailto:pasik@iki.fi
> > >    3. mailto:rercola@pha.jhu.edu
> > >    4. mailto:pasik@iki.fi
> > >    5. mailto:pasik@iki.fi
> > >    6. mailto:pasik@iki.fi
> > >    7. mailto:pasik@iki.fi
> > >    8. mailto:rercola@pha.jhu.edu
> > >    9. mailto:pasik@iki.fi
> > >   10. mailto:pasik@iki.fi
> > >   11. mailto:pasik@iki.fi
> > >   12. mailto:pasik@iki.fi
> > >   13. mailto:majordomo@vger.kernel.org
> > >   14. http://vger.kernel.org/majordomo-info.html
> > >   15. mailto:pasik@iki.fi
> > >   16. mailto:rercola@pha.jhu.edu
> > >   17. mailto:pasik@iki.fi
> > >   18. mailto:pasik@iki.fi
> > >   19. mailto:pasik@iki.fi
> > >   20. mailto:pasik@iki.fi
> > >   21. mailto:rercola@pha.jhu.edu
> > >   22. mailto:pasik@iki.fi
> > >   23. mailto:pasik@iki.fi
> > >   24. mailto:pasik@iki.fi
> > >   25. mailto:pasik@iki.fi
> > >   26. mailto:majordomo@vger.kernel.org
> > >   27. http://vger.kernel.org/majordomo-info.html
> > --
> > 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
> --
> 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
--
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

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

[Rich]

I, and a few others, have scripted the hell out of sas2ircu and a few
other things on various platforms.

I haven't had time to clean up mine and post it publicly yet (it's all
in VCS, I use it a lot, on Windows + Linux + Solaris...), but
https://github.com/swacquie/DiskMap is an example on Solaris.

I may take some time this weekend and clean up the bleeding edges
remaining and make my repo public for people to use...

- Rich

On Thu, Oct 3, 2013 at 3:11 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Mon, Sep 02, 2013 at 05:44:35PM +0300, Pasi Kärkkäinen wrote:
>> On Sun, Sep 01, 2013 at 08:13:02PM +0300, Pasi Kärkkäinen wrote:
>> > On Fri, Aug 30, 2013 at 05:38:04PM -0400, Rich wrote:
>> > >    Apparently, only about 4 months.
>> > >    P17 firmware is out.
>> > >    Tested on a card which was demonstrating the incorrect behavior before, of
>> > >    model 9201-16i.
>> > >    It does appear to contain the fixes for this problem.
>> >
>> > This is great news, finally!
>> > Thanks for testing and reporting!
>> >
>>
>> Hmm, I checked the P17 firmware changelog PDFs for LSI 9211-8i, 9207-8i and 9201-16i,
>> and I can't see anything about this issue being fixed..
>>
>> But if you say it's now fixed, then I guess it means LSI doesn't list every change in the changelog..
>>
>
> I just had some time today to test the new P17 IT firmware with LSI 9211-8i SAS HBAs.
>
> It seems also the "LOCATE" function of LSI sas2ircu tool now actually works and makes
> the red/failure leds blink on the Supermicro passive (direct-attach) backplane! Finally..
>
> Btw do you guys have any scripts/tools to control the LEDs on these passive backplanes?
> smp_read_gpio/smp_write_gpio isn't the most userfriendly interface ;) Should I try ledmon/ledctl?
>
> I can probably hack something myself too.. but there are many other tasks on the todo-list before this :)
>
> Thanks,
>
> -- Pasi
>
>>
>> >
>> > >    - Rich
>> > >
>> > >    On Mon, Apr 22, 2013 at 8:39 PM, Pasi Kärkkäinen <[1]pasik@iki.fi> wrote:
>> > >
>> > >      On Mon, Apr 22, 2013 at 08:28:58PM -0400, Rich wrote:
>> > >      >    I'm told that the fix won't actually be in until P17, because it
>> > >      involved
>> > >      >    touching a large number of codepaths, but that it will be in P17.
>> > >      >
>> > >
>> > >      That's unfortunate.. so another 5-6 months.
>> > >
>> > >      Thanks for the info!
>> > >
>> > >      -- Pasi
>> > >
>> > >      >    - Rich
>> > >      >
>> > >      >    On Mon, Apr 22, 2013 at 8:19 PM, Pasi KÃ*rkkÃ*inen
>> > >      <[1][2]pasik@iki.fi>
>> > >      >    wrote:
>> > >      >
>> > >      >      On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi KÃ*rkkÃ*inen
>> > >      wrote:
>> > >      >      > On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
>> > >      >      > > Â  Â Nope, I'm wrong.
>> > >      >      >
>> > >      >      > :(
>> > >      >      >
>> > >      >      > > Â  Â I flashed P15 on a machine, and the same behavior
>> > >      persisted,
>> > >      >      right up to
>> > >      >      > > Â  Â and including the "groups of 3 devices light up when I
>> > >      do my
>> > >      >      own
>> > >      >      > > Â  Â smp_write_gpio".
>> > >      >      > > Â  Â Whereas if I flash the experimental blob I was handed by
>> > >      >      support to try
>> > >      >      > > Â  Â and confirm they had resolved the issue, it does the
>> > >      correct
>> > >      >      thing.
>> > >      >      > > Â  Â I wonder why this change didn't make it into P15.
>> > >      >      >
>> > >      >      > Hmm.. if you have open contact channel with LSI support please
>> > >      ask
>> > >      >      them..
>> > >      >      > it'd be nice to get the fix for wider audience..
>> > >      >      >
>> > >      >
>> > >      >      It seems LSI P16 firmware has been released.. in the FW changelog
>> > >      I can
>> > >      >      see at least this:
>> > >      >
>> > >      >      "Disable SGPIO Group ID support in Channel NVDATA XML's. This
>> > >      allows the
>> > >      >      use of manufacturing page 7 or default slot mapping setting for
>> > >      direct
>> > >      >      connected drive slots."
>> > >      >
>> > >      >      -- Pasi
>> > >      >
>> > >      >      >
>> > >      >      > > Â  Â - Rich
>> > >      >      > >
>> > >      >      > > Â  Â On Wed, Dec 19, 2012 at 2:00 PM, Rich
>> > >      >      <[1][2][3]rercola@pha.jhu.edu> wrote:
>> > >      >      > >
>> > >      >      > > Â  Â  Â From the LSI P15 F/W release notes:
>> > >      >      > > Â  Â  Â SCGCQ00342805 (DFCT) Ã* - SlotStatus updates to SES
>> > >      managed
>> > >      >      Enclosure may
>> > >      >      > > Â  Â  Â update incorrect slots
>> > >      >      > > Â  Â  Â "Modified FW to use SES diag page 0Ah mapping only if
>> > >      SMP
>> > >      >      Discover
>> > >      >      > > Â  Â  Â DeviceSlotNum is used for Encl PhyÃ* Slot
>> > >      enumeration."
>> > >      >      > > Â  Â  Â SCGCQ00345867 (DFCT) Ã* - Channel NVDATA internal Phy
>> > >      >      reverse setting for
>> > >      >      > > Â  Â  Â 9207-4i4e 9207-8i 9217-4i4eÃ* 9217-8i and 9201-16i
>> > >      >      > > Â  Â  Â "ISSUE DESC:Ã* Internal PHY orders are reversed for
>> > >      the
>> > >      >      channel boards
>> > >      >      > > Â  Â  Â above."
>> > >      >      > > Â  Â  Â So I would submit this is likely fixed by this FW
>> > >      rev.
>> > >      >      > > Â  Â  Â - Rich
>> > >      >      > >
>> > >      >      > > Â  Â  Â On Fri, Dec 7, 2012 at 8:46 AM, Pasi
>> > >      KÃ*â*¬rkkÃ*â*¬inen
>> > >      >      <[2][3][4]pasik@iki.fi>
>> > >      >      > > Â  Â  Â wrote:
>> > >      >      > >
>> > >      >      > > Â  Â  Â  Â On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich
>> > >      wrote:
>> > >      >      > > Â  Â  Â  Â > On Sun, Oct 21, 2012 at 8:46 AM, Pasi
>> > >      >      KÃ*â*¬rkkÃ*â*¬inen <[3][4][5]pasik@iki.fi>
>> > >      >      > > Â  Â  Â  Â wrote:
>> > >      >      > > Â  Â  Â  Â > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi
>> > >      >      KÃ*â*¬rkkÃ*â*¬inen wrote:
>> > >      >      > > Â  Â  Â  Â > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400,
>> > >      Rich
>> > >      >      wrote:
>> > >      >      > > Â  Â  Â  Â > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi
>> > >      >      KÃ*â*¬rkkÃ*â*¬inen
>> > >      >      > > Â  Â  Â  Â <[4][5][6]pasik@iki.fi> wrote:
>> > >      >      > > Â  Â  Â  Â > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200,
>> > >      >      Emmanuel Florac
>> > >      >      > > Â  Â  Â  Â wrote:
>> > >      >      > > Â  Â  Â  Â > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
>> > >      >      > > Â  Â  Â  Â > >> > >> Pasi KÃ*â*¬rkkÃ*â*¬inen
>> > >      <[5][6][7]pasik@iki.fi>
>> > >      >      Ã*©crivait:
>> > >      >      > > Â  Â  Â  Â > >> > >>
>> > >      >      > > Â  Â  Â  Â > >> > >> > Any replies from Supermicro/LSI ?
>> > >      >      > > Â  Â  Â  Â > >> > >> >
>> > >      >      > > Â  Â  Â  Â > >> > >>
>> > >      >      > > Â  Â  Â  Â > >> > >> Only loosely related, but Supermicro
>> > >      replaced
>> > >      >      recently my
>> > >      >      > > Â  Â  Â  Â 846E26 (dual
>> > >      >      > > Â  Â  Â  Â > >> > >> expander backplane) with 846E16 (single
>> > >      >      expander).
>> > >      >      > > Â  Â  Â  Â Apparently they
>> > >      >      > > Â  Â  Â  Â > >> > >> gave up getting the E26 to work properly
>> > >      or
>> > >      >      something: LSI
>> > >      >      > > Â  Â  Â  Â expander
>> > >      >      > > Â  Â  Â  Â > >> > >> firmware problem.
>> > >      >      > > Â  Â  Â  Â > >> > >>
>> > >      >      > > Â  Â  Â  Â > >> > >> In another (very large scale, high end)
>> > >      setup,
>> > >      >      many
>> > >      >      > > Â  Â  Â  Â different 60 slots
>> > >      >      > > Â  Â  Â  Â > >> > >> 5 LSI expanders chassis had a general
>> > >      failure
>> > >      >      of the 5th
>> > >      >      > > Â  Â  Â  Â drawer.
>> > >      >      > > Â  Â  Â  Â > >> > >> Another LSI SAS-2 expander firmware
>> > >      problem.
>> > >      >      > > Â  Â  Â  Â > >> > >>
>> > >      >      > > Â  Â  Â  Â > >> > >> I could start a rant about the evil of
>> > >      >      proprietary firmware,
>> > >      >      > > Â  Â  Â  Â etc. You
>> > >      >      > > Â  Â  Â  Â > >> > >> get my meaning :)
>> > >      >      > > Â  Â  Â  Â > >> > >>
>> > >      >      > > Â  Â  Â  Â > >> > >
>> > >      >      > > Â  Â  Â  Â > >> > > Yeah, this is a good example why we're
>> > >      trying to
>> > >      >      get the LEDs
>> > >      >      > > Â  Â  Â  Â working with
>> > >      >      > > Â  Â  Â  Â > >> > > direct attach (non-expander) backplanes
>> > >      :)
>> > >      >      > > Â  Â  Â  Â > >> > >
>> > >      >      > > Â  Â  Â  Â > >> > > -- Pasi
>> > >      >      > > Â  Â  Â  Â > >> > >
>> > >      >      > > Â  Â  Â  Â > >> >
>> > >      >      > > Â  Â  Â  Â > >> > I don't have anything useful for people,
>> > >      other
>> > >      >      than that they
>> > >      >      > > Â  Â  Â  Â have
>> > >      >      > > Â  Â  Â  Â > >> > shown me an HBA firmware that fixes the LED
>> > >      >      problem but has
>> > >      >      > > Â  Â  Â  Â other
>> > >      >      > > Â  Â  Â  Â > >> > problems they're still debugging.
>> > >      >      > > Â  Â  Â  Â > >> >
>> > >      >      > > Â  Â  Â  Â > >> > So there does exist code for this firmware
>> > >      which
>> > >      >      will fix this
>> > >      >      > > Â  Â  Â  Â problem.
>> > >      >      > > Â  Â  Â  Â > >> >
>> > >      >      > > Â  Â  Â  Â > >>
>> > >      >      > > Â  Â  Â  Â > >> That's good to know! Let's hope the fix ends
>> > >      up in
>> > >      >      an official
>> > >      >      > > Â  Â  Â  Â > >> LSI HBA firmware update in not-so-distant
>> > >      future.
>> > >      >      > > Â  Â  Â  Â > >>
>> > >      >      > > Â  Â  Â  Â > >
>> > >      >      > > Â  Â  Â  Â > > Btw what was the version number of the
>> > >      LED-fixed LSI
>> > >      >      firmware?
>> > >      >      > > Â  Â  Â  Â > > I'm just wondering in which firmware series
>> > >      the fix
>> > >      >      might end up
>> > >      >      > > Â  Â  Â  Â being included..
>> > >      >      > > Â  Â  Â  Â > >
>> > >      >      > > Â  Â  Â  Â > > Also: Any updates on this?
>> > >      >      > > Â  Â  Â  Â > >
>> > >      >      > > Â  Â  Â  Â > > Thanks,
>> > >      >      > > Â  Â  Â  Â > >
>> > >      >      > > Â  Â  Â  Â > > -- Pasi
>> > >      >      > > Â  Â  Â  Â > >
>> > >      >      > > Â  Â  Â  Â >
>> > >      >      > > Â  Â  Â  Â > The fixed FW I had demonstrated for me was still
>> > >      >      14.0.0.0 - I've
>> > >      >      > > Â  Â  Â  Â been
>> > >      >      > > Â  Â  Â  Â > told it'll be rolled into the FW release
>> > >      currently on
>> > >      >      the site and
>> > >      >      > > Â  Â  Â  Â > posted at some point, but that they have no ETA
>> > >      for
>> > >      >      that.
>> > >      >      > > Â  Â  Â  Â >
>> > >      >      > >
>> > >      >      > > Â  Â  Â  Â I can now see P15 firmware available on LSI's
>> > >      website for
>> > >      >      9211-8i
>> > >      >      > > Â  Â  Â  Â (SAS2008 based HBA).
>> > >      >      > > Â  Â  Â  Â Sadly it's missing the releasenotes/changelogs for
>> > >      both
>> > >      >      the LSI bios
>> > >      >      > > Â  Â  Â  Â and firmware..
>> > >      >      > > Â  Â  Â  Â -- Pasi
>> > >      >      > >
>> > >      >      > > References
>> > >      >      > >
>> > >      >      > > Â  Â Visible links
>> > >      >      > > Â  Â 1. mailto:[7][8]rercola@pha.jhu.edu
>> > >      >      > > Â  Â 2. mailto:[8][9]pasik@iki.fi
>> > >      >      > > Â  Â 3. mailto:[9][10]pasik@iki.fi
>> > >      >      > > Â  Â 4. mailto:[10][11]pasik@iki.fi
>> > >      >      > > Â  Â 5. mailto:[11][12]pasik@iki.fi
>> > >      >      > --
>> > >      >      > To unsubscribe from this list: send the line "unsubscribe
>> > >      linux-scsi"
>> > >      >      in
>> > >      >      > the body of a message to [12][13]majordomo@vger.kernel.org
>> > >      >      > More majordomo info at
>> > >      >      Â [13][14]http://vger.kernel.org/majordomo-info.html
>> > >      >
>> > >      > References
>> > >      >
>> > >      >    Visible links
>> > >      >    1. mailto:[15]pasik@iki.fi
>> > >      >    2. mailto:[16]rercola@pha.jhu.edu
>> > >      >    3. mailto:[17]pasik@iki.fi
>> > >      >    4. mailto:[18]pasik@iki.fi
>> > >      >    5. mailto:[19]pasik@iki.fi
>> > >      >    6. mailto:[20]pasik@iki.fi
>> > >      >    7. mailto:[21]rercola@pha.jhu.edu
>> > >      >    8. mailto:[22]pasik@iki.fi
>> > >      >    9. mailto:[23]pasik@iki.fi
>> > >      >   10. mailto:[24]pasik@iki.fi
>> > >      >   11. mailto:[25]pasik@iki.fi
>> > >      >   12. mailto:[26]majordomo@vger.kernel.org
>> > >      >   13. [27]http://vger.kernel.org/majordomo-info.html
>> > >
>> > > References
>> > >
>> > >    Visible links
>> > >    1. mailto:pasik@iki.fi
>> > >    2. mailto:pasik@iki.fi
>> > >    3. mailto:rercola@pha.jhu.edu
>> > >    4. mailto:pasik@iki.fi
>> > >    5. mailto:pasik@iki.fi
>> > >    6. mailto:pasik@iki.fi
>> > >    7. mailto:pasik@iki.fi
>> > >    8. mailto:rercola@pha.jhu.edu
>> > >    9. mailto:pasik@iki.fi
>> > >   10. mailto:pasik@iki.fi
>> > >   11. mailto:pasik@iki.fi
>> > >   12. mailto:pasik@iki.fi
>> > >   13. mailto:majordomo@vger.kernel.org
>> > >   14. http://vger.kernel.org/majordomo-info.html
>> > >   15. mailto:pasik@iki.fi
>> > >   16. mailto:rercola@pha.jhu.edu
>> > >   17. mailto:pasik@iki.fi
>> > >   18. mailto:pasik@iki.fi
>> > >   19. mailto:pasik@iki.fi
>> > >   20. mailto:pasik@iki.fi
>> > >   21. mailto:rercola@pha.jhu.edu
>> > >   22. mailto:pasik@iki.fi
>> > >   23. mailto:pasik@iki.fi
>> > >   24. mailto:pasik@iki.fi
>> > >   25. mailto:pasik@iki.fi
>> > >   26. mailto:majordomo@vger.kernel.org
>> > >   27. http://vger.kernel.org/majordomo-info.html
>> > --
>> > 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
>> --
>> 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
--
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

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

[Pasi Kärkkäinen]

On Thu, Oct 03, 2013 at 04:07:31PM -0400, Rich wrote:
> I, and a few others, have scripted the hell out of sas2ircu and a few
> other things on various platforms.
> 

Been there, done that :) I was mostly wondering if there are other tools
so I could evaluate if it makes sense to continue wrapping sas2ircu with custom scripts,
or if there are better tools out there.. 

> I haven't had time to clean up mine and post it publicly yet (it's all
> in VCS, I use it a lot, on Windows + Linux + Solaris...), but
> https://github.com/swacquie/DiskMap is an example on Solaris.
> 
> I may take some time this weekend and clean up the bleeding edges
> remaining and make my repo public for people to use...
> 

That'd be nice! Looking forward to it.. 

-- Pasi

> - Rich
> 
> On Thu, Oct 3, 2013 at 3:11 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Mon, Sep 02, 2013 at 05:44:35PM +0300, Pasi Kärkkäinen wrote:
> >> On Sun, Sep 01, 2013 at 08:13:02PM +0300, Pasi Kärkkäinen wrote:
> >> > On Fri, Aug 30, 2013 at 05:38:04PM -0400, Rich wrote:
> >> > >    Apparently, only about 4 months.
> >> > >    P17 firmware is out.
> >> > >    Tested on a card which was demonstrating the incorrect behavior before, of
> >> > >    model 9201-16i.
> >> > >    It does appear to contain the fixes for this problem.
> >> >
> >> > This is great news, finally!
> >> > Thanks for testing and reporting!
> >> >
> >>
> >> Hmm, I checked the P17 firmware changelog PDFs for LSI 9211-8i, 9207-8i and 9201-16i,
> >> and I can't see anything about this issue being fixed..
> >>
> >> But if you say it's now fixed, then I guess it means LSI doesn't list every change in the changelog..
> >>
> >
> > I just had some time today to test the new P17 IT firmware with LSI 9211-8i SAS HBAs.
> >
> > It seems also the "LOCATE" function of LSI sas2ircu tool now actually works and makes
> > the red/failure leds blink on the Supermicro passive (direct-attach) backplane! Finally..
> >
> > Btw do you guys have any scripts/tools to control the LEDs on these passive backplanes?
> > smp_read_gpio/smp_write_gpio isn't the most userfriendly interface ;) Should I try ledmon/ledctl?
> >
> > I can probably hack something myself too.. but there are many other tasks on the todo-list before this :)
> >
> > Thanks,
> >
> > -- Pasi
> >
> >>
> >> >
> >> > >    - Rich
> >> > >
> >> > >    On Mon, Apr 22, 2013 at 8:39 PM, Pasi Kärkkäinen <[1]pasik@iki.fi> wrote:
> >> > >
> >> > >      On Mon, Apr 22, 2013 at 08:28:58PM -0400, Rich wrote:
> >> > >      >    I'm told that the fix won't actually be in until P17, because it
> >> > >      involved
> >> > >      >    touching a large number of codepaths, but that it will be in P17.
> >> > >      >
> >> > >
> >> > >      That's unfortunate.. so another 5-6 months.
> >> > >
> >> > >      Thanks for the info!
> >> > >
> >> > >      -- Pasi
> >> > >
> >> > >      >    - Rich
> >> > >      >
> >> > >      >    On Mon, Apr 22, 2013 at 8:19 PM, Pasi KÃ*rkkÃ*inen
> >> > >      <[1][2]pasik@iki.fi>
> >> > >      >    wrote:
> >> > >      >
> >> > >      >      On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi KÃ*rkkÃ*inen
> >> > >      wrote:
> >> > >      >      > On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
> >> > >      >      > > Â  Â Nope, I'm wrong.
> >> > >      >      >
> >> > >      >      > :(
> >> > >      >      >
> >> > >      >      > > Â  Â I flashed P15 on a machine, and the same behavior
> >> > >      persisted,
> >> > >      >      right up to
> >> > >      >      > > Â  Â and including the "groups of 3 devices light up when I
> >> > >      do my
> >> > >      >      own
> >> > >      >      > > Â  Â smp_write_gpio".
> >> > >      >      > > Â  Â Whereas if I flash the experimental blob I was handed by
> >> > >      >      support to try
> >> > >      >      > > Â  Â and confirm they had resolved the issue, it does the
> >> > >      correct
> >> > >      >      thing.
> >> > >      >      > > Â  Â I wonder why this change didn't make it into P15.
> >> > >      >      >
> >> > >      >      > Hmm.. if you have open contact channel with LSI support please
> >> > >      ask
> >> > >      >      them..
> >> > >      >      > it'd be nice to get the fix for wider audience..
> >> > >      >      >
> >> > >      >
> >> > >      >      It seems LSI P16 firmware has been released.. in the FW changelog
> >> > >      I can
> >> > >      >      see at least this:
> >> > >      >
> >> > >      >      "Disable SGPIO Group ID support in Channel NVDATA XML's. This
> >> > >      allows the
> >> > >      >      use of manufacturing page 7 or default slot mapping setting for
> >> > >      direct
> >> > >      >      connected drive slots."
> >> > >      >
> >> > >      >      -- Pasi
> >> > >      >
> >> > >      >      >
> >> > >      >      > > Â  Â - Rich
> >> > >      >      > >
> >> > >      >      > > Â  Â On Wed, Dec 19, 2012 at 2:00 PM, Rich
> >> > >      >      <[1][2][3]rercola@pha.jhu.edu> wrote:
> >> > >      >      > >
> >> > >      >      > > Â  Â  Â From the LSI P15 F/W release notes:
> >> > >      >      > > Â  Â  Â SCGCQ00342805 (DFCT) Ã* - SlotStatus updates to SES
> >> > >      managed
> >> > >      >      Enclosure may
> >> > >      >      > > Â  Â  Â update incorrect slots
> >> > >      >      > > Â  Â  Â "Modified FW to use SES diag page 0Ah mapping only if
> >> > >      SMP
> >> > >      >      Discover
> >> > >      >      > > Â  Â  Â DeviceSlotNum is used for Encl PhyÃ* Slot
> >> > >      enumeration."
> >> > >      >      > > Â  Â  Â SCGCQ00345867 (DFCT) Ã* - Channel NVDATA internal Phy
> >> > >      >      reverse setting for
> >> > >      >      > > Â  Â  Â 9207-4i4e 9207-8i 9217-4i4eÃ* 9217-8i and 9201-16i
> >> > >      >      > > Â  Â  Â "ISSUE DESC:Ã* Internal PHY orders are reversed for
> >> > >      the
> >> > >      >      channel boards
> >> > >      >      > > Â  Â  Â above."
> >> > >      >      > > Â  Â  Â So I would submit this is likely fixed by this FW
> >> > >      rev.
> >> > >      >      > > Â  Â  Â - Rich
> >> > >      >      > >
> >> > >      >      > > Â  Â  Â On Fri, Dec 7, 2012 at 8:46 AM, Pasi
> >> > >      KÃ*â*¬rkkÃ*â*¬inen
> >> > >      >      <[2][3][4]pasik@iki.fi>
> >> > >      >      > > Â  Â  Â wrote:
> >> > >      >      > >
> >> > >      >      > > Â  Â  Â  Â On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich
> >> > >      wrote:
> >> > >      >      > > Â  Â  Â  Â > On Sun, Oct 21, 2012 at 8:46 AM, Pasi
> >> > >      >      KÃ*â*¬rkkÃ*â*¬inen <[3][4][5]pasik@iki.fi>
> >> > >      >      > > Â  Â  Â  Â wrote:
> >> > >      >      > > Â  Â  Â  Â > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi
> >> > >      >      KÃ*â*¬rkkÃ*â*¬inen wrote:
> >> > >      >      > > Â  Â  Â  Â > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400,
> >> > >      Rich
> >> > >      >      wrote:
> >> > >      >      > > Â  Â  Â  Â > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi
> >> > >      >      KÃ*â*¬rkkÃ*â*¬inen
> >> > >      >      > > Â  Â  Â  Â <[4][5][6]pasik@iki.fi> wrote:
> >> > >      >      > > Â  Â  Â  Â > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200,
> >> > >      >      Emmanuel Florac
> >> > >      >      > > Â  Â  Â  Â wrote:
> >> > >      >      > > Â  Â  Â  Â > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
> >> > >      >      > > Â  Â  Â  Â > >> > >> Pasi KÃ*â*¬rkkÃ*â*¬inen
> >> > >      <[5][6][7]pasik@iki.fi>
> >> > >      >      Ã*©crivait:
> >> > >      >      > > Â  Â  Â  Â > >> > >>
> >> > >      >      > > Â  Â  Â  Â > >> > >> > Any replies from Supermicro/LSI ?
> >> > >      >      > > Â  Â  Â  Â > >> > >> >
> >> > >      >      > > Â  Â  Â  Â > >> > >>
> >> > >      >      > > Â  Â  Â  Â > >> > >> Only loosely related, but Supermicro
> >> > >      replaced
> >> > >      >      recently my
> >> > >      >      > > Â  Â  Â  Â 846E26 (dual
> >> > >      >      > > Â  Â  Â  Â > >> > >> expander backplane) with 846E16 (single
> >> > >      >      expander).
> >> > >      >      > > Â  Â  Â  Â Apparently they
> >> > >      >      > > Â  Â  Â  Â > >> > >> gave up getting the E26 to work properly
> >> > >      or
> >> > >      >      something: LSI
> >> > >      >      > > Â  Â  Â  Â expander
> >> > >      >      > > Â  Â  Â  Â > >> > >> firmware problem.
> >> > >      >      > > Â  Â  Â  Â > >> > >>
> >> > >      >      > > Â  Â  Â  Â > >> > >> In another (very large scale, high end)
> >> > >      setup,
> >> > >      >      many
> >> > >      >      > > Â  Â  Â  Â different 60 slots
> >> > >      >      > > Â  Â  Â  Â > >> > >> 5 LSI expanders chassis had a general
> >> > >      failure
> >> > >      >      of the 5th
> >> > >      >      > > Â  Â  Â  Â drawer.
> >> > >      >      > > Â  Â  Â  Â > >> > >> Another LSI SAS-2 expander firmware
> >> > >      problem.
> >> > >      >      > > Â  Â  Â  Â > >> > >>
> >> > >      >      > > Â  Â  Â  Â > >> > >> I could start a rant about the evil of
> >> > >      >      proprietary firmware,
> >> > >      >      > > Â  Â  Â  Â etc. You
> >> > >      >      > > Â  Â  Â  Â > >> > >> get my meaning :)
> >> > >      >      > > Â  Â  Â  Â > >> > >>
> >> > >      >      > > Â  Â  Â  Â > >> > >
> >> > >      >      > > Â  Â  Â  Â > >> > > Yeah, this is a good example why we're
> >> > >      trying to
> >> > >      >      get the LEDs
> >> > >      >      > > Â  Â  Â  Â working with
> >> > >      >      > > Â  Â  Â  Â > >> > > direct attach (non-expander) backplanes
> >> > >      :)
> >> > >      >      > > Â  Â  Â  Â > >> > >
> >> > >      >      > > Â  Â  Â  Â > >> > > -- Pasi
> >> > >      >      > > Â  Â  Â  Â > >> > >
> >> > >      >      > > Â  Â  Â  Â > >> >
> >> > >      >      > > Â  Â  Â  Â > >> > I don't have anything useful for people,
> >> > >      other
> >> > >      >      than that they
> >> > >      >      > > Â  Â  Â  Â have
> >> > >      >      > > Â  Â  Â  Â > >> > shown me an HBA firmware that fixes the LED
> >> > >      >      problem but has
> >> > >      >      > > Â  Â  Â  Â other
> >> > >      >      > > Â  Â  Â  Â > >> > problems they're still debugging.
> >> > >      >      > > Â  Â  Â  Â > >> >
> >> > >      >      > > Â  Â  Â  Â > >> > So there does exist code for this firmware
> >> > >      which
> >> > >      >      will fix this
> >> > >      >      > > Â  Â  Â  Â problem.
> >> > >      >      > > Â  Â  Â  Â > >> >
> >> > >      >      > > Â  Â  Â  Â > >>
> >> > >      >      > > Â  Â  Â  Â > >> That's good to know! Let's hope the fix ends
> >> > >      up in
> >> > >      >      an official
> >> > >      >      > > Â  Â  Â  Â > >> LSI HBA firmware update in not-so-distant
> >> > >      future.
> >> > >      >      > > Â  Â  Â  Â > >>
> >> > >      >      > > Â  Â  Â  Â > >
> >> > >      >      > > Â  Â  Â  Â > > Btw what was the version number of the
> >> > >      LED-fixed LSI
> >> > >      >      firmware?
> >> > >      >      > > Â  Â  Â  Â > > I'm just wondering in which firmware series
> >> > >      the fix
> >> > >      >      might end up
> >> > >      >      > > Â  Â  Â  Â being included..
> >> > >      >      > > Â  Â  Â  Â > >
> >> > >      >      > > Â  Â  Â  Â > > Also: Any updates on this?
> >> > >      >      > > Â  Â  Â  Â > >
> >> > >      >      > > Â  Â  Â  Â > > Thanks,
> >> > >      >      > > Â  Â  Â  Â > >
> >> > >      >      > > Â  Â  Â  Â > > -- Pasi
> >> > >      >      > > Â  Â  Â  Â > >
> >> > >      >      > > Â  Â  Â  Â >
> >> > >      >      > > Â  Â  Â  Â > The fixed FW I had demonstrated for me was still
> >> > >      >      14.0.0.0 - I've
> >> > >      >      > > Â  Â  Â  Â been
> >> > >      >      > > Â  Â  Â  Â > told it'll be rolled into the FW release
> >> > >      currently on
> >> > >      >      the site and
> >> > >      >      > > Â  Â  Â  Â > posted at some point, but that they have no ETA
> >> > >      for
> >> > >      >      that.
> >> > >      >      > > Â  Â  Â  Â >
> >> > >      >      > >
> >> > >      >      > > Â  Â  Â  Â I can now see P15 firmware available on LSI's
> >> > >      website for
> >> > >      >      9211-8i
> >> > >      >      > > Â  Â  Â  Â (SAS2008 based HBA).
> >> > >      >      > > Â  Â  Â  Â Sadly it's missing the releasenotes/changelogs for
> >> > >      both
> >> > >      >      the LSI bios
> >> > >      >      > > Â  Â  Â  Â and firmware..
> >> > >      >      > > Â  Â  Â  Â -- Pasi
> >> > >      >      > >
> >> > >      >      > > References
> >> > >      >      > >
> >> > >      >      > > Â  Â Visible links
> >> > >      >      > > Â  Â 1. mailto:[7][8]rercola@pha.jhu.edu
> >> > >      >      > > Â  Â 2. mailto:[8][9]pasik@iki.fi
> >> > >      >      > > Â  Â 3. mailto:[9][10]pasik@iki.fi
> >> > >      >      > > Â  Â 4. mailto:[10][11]pasik@iki.fi
> >> > >      >      > > Â  Â 5. mailto:[11][12]pasik@iki.fi
> >> > >      >      > --
> >> > >      >      > To unsubscribe from this list: send the line "unsubscribe
> >> > >      linux-scsi"
> >> > >      >      in
> >> > >      >      > the body of a message to [12][13]majordomo@vger.kernel.org
> >> > >      >      > More majordomo info at
> >> > >      >      Â [13][14]http://vger.kernel.org/majordomo-info.html
> >> > >      >
> >> > >      > References
> >> > >      >
> >> > >      >    Visible links
> >> > >      >    1. mailto:[15]pasik@iki.fi
> >> > >      >    2. mailto:[16]rercola@pha.jhu.edu
> >> > >      >    3. mailto:[17]pasik@iki.fi
> >> > >      >    4. mailto:[18]pasik@iki.fi
> >> > >      >    5. mailto:[19]pasik@iki.fi
> >> > >      >    6. mailto:[20]pasik@iki.fi
> >> > >      >    7. mailto:[21]rercola@pha.jhu.edu
> >> > >      >    8. mailto:[22]pasik@iki.fi
> >> > >      >    9. mailto:[23]pasik@iki.fi
> >> > >      >   10. mailto:[24]pasik@iki.fi
> >> > >      >   11. mailto:[25]pasik@iki.fi
> >> > >      >   12. mailto:[26]majordomo@vger.kernel.org
> >> > >      >   13. [27]http://vger.kernel.org/majordomo-info.html
> >> > >
> >> > > References
> >> > >
> >> > >    Visible links
> >> > >    1. mailto:pasik@iki.fi
> >> > >    2. mailto:pasik@iki.fi
> >> > >    3. mailto:rercola@pha.jhu.edu
> >> > >    4. mailto:pasik@iki.fi
> >> > >    5. mailto:pasik@iki.fi
> >> > >    6. mailto:pasik@iki.fi
> >> > >    7. mailto:pasik@iki.fi
> >> > >    8. mailto:rercola@pha.jhu.edu
> >> > >    9. mailto:pasik@iki.fi
> >> > >   10. mailto:pasik@iki.fi
> >> > >   11. mailto:pasik@iki.fi
> >> > >   12. mailto:pasik@iki.fi
> >> > >   13. mailto:majordomo@vger.kernel.org
> >> > >   14. http://vger.kernel.org/majordomo-info.html
> >> > >   15. mailto:pasik@iki.fi
> >> > >   16. mailto:rercola@pha.jhu.edu
> >> > >   17. mailto:pasik@iki.fi
> >> > >   18. mailto:pasik@iki.fi
> >> > >   19. mailto:pasik@iki.fi
> >> > >   20. mailto:pasik@iki.fi
> >> > >   21. mailto:rercola@pha.jhu.edu
> >> > >   22. mailto:pasik@iki.fi
> >> > >   23. mailto:pasik@iki.fi
> >> > >   24. mailto:pasik@iki.fi
> >> > >   25. mailto:pasik@iki.fi
> >> > >   26. mailto:majordomo@vger.kernel.org
> >> > >   27. http://vger.kernel.org/majordomo-info.html
> >> > --
> >> > 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
> >> --
> >> 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
--
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

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

[Douglas Gilbert]

On 13-10-03 03:11 PM, Pasi Kärkkäinen wrote:
> On Mon, Sep 02, 2013 at 05:44:35PM +0300, Pasi Kärkkäinen wrote:
>> On Sun, Sep 01, 2013 at 08:13:02PM +0300, Pasi Kärkkäinen wrote:
>>> On Fri, Aug 30, 2013 at 05:38:04PM -0400, Rich wrote:
>>>>     Apparently, only about 4 months.
>>>>     P17 firmware is out.
>>>>     Tested on a card which was demonstrating the incorrect behavior before, of
>>>>     model 9201-16i.
>>>>     It does appear to contain the fixes for this problem.
>>>
>>> This is great news, finally!
>>> Thanks for testing and reporting!
>>>
>>
>> Hmm, I checked the P17 firmware changelog PDFs for LSI 9211-8i, 9207-8i and 9201-16i,
>> and I can't see anything about this issue being fixed..
>>
>> But if you say it's now fixed, then I guess it means LSI doesn't list every change in the changelog..
>>
>
> I just had some time today to test the new P17 IT firmware with LSI 9211-8i SAS HBAs.
>
> It seems also the "LOCATE" function of LSI sas2ircu tool now actually works and makes
> the red/failure leds blink on the Supermicro passive (direct-attach) backplane! Finally..
>
> Btw do you guys have any scripts/tools to control the LEDs on these passive backplanes?
> smp_read_gpio/smp_write_gpio isn't the most userfriendly interface ;) Should I try ledmon/ledctl?

There isn't much information about the SMP READ_GPIO and
WRITE_GPIO (and extended variants) in the older SAS
standards and now they have been pushed out of the recent
SAS (SPL-3) drafts. SFF-8485 ain't much help in that
respect either. If anyone has information (not covered by
an NDA) about how these are used, please send it to me.

As for blinking the LED on a SAS disk: in the sdparm package,
in the 'scripts' directory, try the sas_disk_blink script.

Doug Gilbert

> I can probably hack something myself too.. but there are many other tasks on the todo-list before this :)
>
> Thanks,
>
> -- Pasi
>
>>
>>>
>>>>     - Rich
>>>>
>>>>     On Mon, Apr 22, 2013 at 8:39 PM, Pasi Kärkkäinen <[1]pasik@iki.fi> wrote:
>>>>
>>>>       On Mon, Apr 22, 2013 at 08:28:58PM -0400, Rich wrote:
>>>>       >    I'm told that the fix won't actually be in until P17, because it
>>>>       involved
>>>>       >    touching a large number of codepaths, but that it will be in P17.
>>>>       >
>>>>
>>>>       That's unfortunate.. so another 5-6 months.
>>>>
>>>>       Thanks for the info!
>>>>
>>>>       -- Pasi
>>>>
>>>>       >    - Rich
>>>>       >
>>>>       >    On Mon, Apr 22, 2013 at 8:19 PM, Pasi KÃ*rkkÃ*inen
>>>>       <[1][2]pasik@iki.fi>
>>>>       >    wrote:
>>>>       >
>>>>       >      On Wed, Dec 19, 2012 at 09:41:42PM +0200, Pasi KÃ*rkkÃ*inen
>>>>       wrote:
>>>>       >      > On Wed, Dec 19, 2012 at 02:35:02PM -0500, Rich wrote:
>>>>       >      > > Â  Â Nope, I'm wrong.
>>>>       >      >
>>>>       >      > :(
>>>>       >      >
>>>>       >      > > Â  Â I flashed P15 on a machine, and the same behavior
>>>>       persisted,
>>>>       >      right up to
>>>>       >      > > Â  Â and including the "groups of 3 devices light up when I
>>>>       do my
>>>>       >      own
>>>>       >      > > Â  Â smp_write_gpio".
>>>>       >      > > Â  Â Whereas if I flash the experimental blob I was handed by
>>>>       >      support to try
>>>>       >      > > Â  Â and confirm they had resolved the issue, it does the
>>>>       correct
>>>>       >      thing.
>>>>       >      > > Â  Â I wonder why this change didn't make it into P15.
>>>>       >      >
>>>>       >      > Hmm.. if you have open contact channel with LSI support please
>>>>       ask
>>>>       >      them..
>>>>       >      > it'd be nice to get the fix for wider audience..
>>>>       >      >
>>>>       >
>>>>       >      It seems LSI P16 firmware has been released.. in the FW changelog
>>>>       I can
>>>>       >      see at least this:
>>>>       >
>>>>       >      "Disable SGPIO Group ID support in Channel NVDATA XML's. This
>>>>       allows the
>>>>       >      use of manufacturing page 7 or default slot mapping setting for
>>>>       direct
>>>>       >      connected drive slots."
>>>>       >
>>>>       >      -- Pasi
>>>>       >
>>>>       >      >
>>>>       >      > > Â  Â - Rich
>>>>       >      > >
>>>>       >      > > Â  Â On Wed, Dec 19, 2012 at 2:00 PM, Rich
>>>>       >      <[1][2][3]rercola@pha.jhu.edu> wrote:
>>>>       >      > >
>>>>       >      > > Â  Â  Â From the LSI P15 F/W release notes:
>>>>       >      > > Â  Â  Â SCGCQ00342805 (DFCT) Ã* - SlotStatus updates to SES
>>>>       managed
>>>>       >      Enclosure may
>>>>       >      > > Â  Â  Â update incorrect slots
>>>>       >      > > Â  Â  Â "Modified FW to use SES diag page 0Ah mapping only if
>>>>       SMP
>>>>       >      Discover
>>>>       >      > > Â  Â  Â DeviceSlotNum is used for Encl PhyÃ* Slot
>>>>       enumeration."
>>>>       >      > > Â  Â  Â SCGCQ00345867 (DFCT) Ã* - Channel NVDATA internal Phy
>>>>       >      reverse setting for
>>>>       >      > > Â  Â  Â 9207-4i4e 9207-8i 9217-4i4eÃ* 9217-8i and 9201-16i
>>>>       >      > > Â  Â  Â "ISSUE DESC:Ã* Internal PHY orders are reversed for
>>>>       the
>>>>       >      channel boards
>>>>       >      > > Â  Â  Â above."
>>>>       >      > > Â  Â  Â So I would submit this is likely fixed by this FW
>>>>       rev.
>>>>       >      > > Â  Â  Â - Rich
>>>>       >      > >
>>>>       >      > > Â  Â  Â On Fri, Dec 7, 2012 at 8:46 AM, Pasi
>>>>       KÃ*â*¬rkkÃ*â*¬inen
>>>>       >      <[2][3][4]pasik@iki.fi>
>>>>       >      > > Â  Â  Â wrote:
>>>>       >      > >
>>>>       >      > > Â  Â  Â  Â On Thu, Nov 01, 2012 at 11:55:25AM -0400, Rich
>>>>       wrote:
>>>>       >      > > Â  Â  Â  Â > On Sun, Oct 21, 2012 at 8:46 AM, Pasi
>>>>       >      KÃ*â*¬rkkÃ*â*¬inen <[3][4][5]pasik@iki.fi>
>>>>       >      > > Â  Â  Â  Â wrote:
>>>>       >      > > Â  Â  Â  Â > > On Mon, Sep 10, 2012 at 07:13:15PM +0300, Pasi
>>>>       >      KÃ*â*¬rkkÃ*â*¬inen wrote:
>>>>       >      > > Â  Â  Â  Â > >> On Mon, Sep 10, 2012 at 12:07:45PM -0400,
>>>>       Rich
>>>>       >      wrote:
>>>>       >      > > Â  Â  Â  Â > >> > On Mon, Sep 10, 2012 at 12:04 PM, Pasi
>>>>       >      KÃ*â*¬rkkÃ*â*¬inen
>>>>       >      > > Â  Â  Â  Â <[4][5][6]pasik@iki.fi> wrote:
>>>>       >      > > Â  Â  Â  Â > >> > > On Mon, Sep 10, 2012 at 06:01:42PM +0200,
>>>>       >      Emmanuel Florac
>>>>       >      > > Â  Â  Â  Â wrote:
>>>>       >      > > Â  Â  Â  Â > >> > >> Le Mon, 10 Sep 2012 16:47:11 +0300
>>>>       >      > > Â  Â  Â  Â > >> > >> Pasi KÃ*â*¬rkkÃ*â*¬inen
>>>>       <[5][6][7]pasik@iki.fi>
>>>>       >      Ã*©crivait:
>>>>       >      > > Â  Â  Â  Â > >> > >>
>>>>       >      > > Â  Â  Â  Â > >> > >> > Any replies from Supermicro/LSI ?
>>>>       >      > > Â  Â  Â  Â > >> > >> >
>>>>       >      > > Â  Â  Â  Â > >> > >>
>>>>       >      > > Â  Â  Â  Â > >> > >> Only loosely related, but Supermicro
>>>>       replaced
>>>>       >      recently my
>>>>       >      > > Â  Â  Â  Â 846E26 (dual
>>>>       >      > > Â  Â  Â  Â > >> > >> expander backplane) with 846E16 (single
>>>>       >      expander).
>>>>       >      > > Â  Â  Â  Â Apparently they
>>>>       >      > > Â  Â  Â  Â > >> > >> gave up getting the E26 to work properly
>>>>       or
>>>>       >      something: LSI
>>>>       >      > > Â  Â  Â  Â expander
>>>>       >      > > Â  Â  Â  Â > >> > >> firmware problem.
>>>>       >      > > Â  Â  Â  Â > >> > >>
>>>>       >      > > Â  Â  Â  Â > >> > >> In another (very large scale, high end)
>>>>       setup,
>>>>       >      many
>>>>       >      > > Â  Â  Â  Â different 60 slots
>>>>       >      > > Â  Â  Â  Â > >> > >> 5 LSI expanders chassis had a general
>>>>       failure
>>>>       >      of the 5th
>>>>       >      > > Â  Â  Â  Â drawer.
>>>>       >      > > Â  Â  Â  Â > >> > >> Another LSI SAS-2 expander firmware
>>>>       problem.
>>>>       >      > > Â  Â  Â  Â > >> > >>
>>>>       >      > > Â  Â  Â  Â > >> > >> I could start a rant about the evil of
>>>>       >      proprietary firmware,
>>>>       >      > > Â  Â  Â  Â etc. You
>>>>       >      > > Â  Â  Â  Â > >> > >> get my meaning :)
>>>>       >      > > Â  Â  Â  Â > >> > >>
>>>>       >      > > Â  Â  Â  Â > >> > >
>>>>       >      > > Â  Â  Â  Â > >> > > Yeah, this is a good example why we're
>>>>       trying to
>>>>       >      get the LEDs
>>>>       >      > > Â  Â  Â  Â working with
>>>>       >      > > Â  Â  Â  Â > >> > > direct attach (non-expander) backplanes
>>>>       :)
>>>>       >      > > Â  Â  Â  Â > >> > >
>>>>       >      > > Â  Â  Â  Â > >> > > -- Pasi
>>>>       >      > > Â  Â  Â  Â > >> > >
>>>>       >      > > Â  Â  Â  Â > >> >
>>>>       >      > > Â  Â  Â  Â > >> > I don't have anything useful for people,
>>>>       other
>>>>       >      than that they
>>>>       >      > > Â  Â  Â  Â have
>>>>       >      > > Â  Â  Â  Â > >> > shown me an HBA firmware that fixes the LED
>>>>       >      problem but has
>>>>       >      > > Â  Â  Â  Â other
>>>>       >      > > Â  Â  Â  Â > >> > problems they're still debugging.
>>>>       >      > > Â  Â  Â  Â > >> >
>>>>       >      > > Â  Â  Â  Â > >> > So there does exist code for this firmware
>>>>       which
>>>>       >      will fix this
>>>>       >      > > Â  Â  Â  Â problem.
>>>>       >      > > Â  Â  Â  Â > >> >
>>>>       >      > > Â  Â  Â  Â > >>
>>>>       >      > > Â  Â  Â  Â > >> That's good to know! Let's hope the fix ends
>>>>       up in
>>>>       >      an official
>>>>       >      > > Â  Â  Â  Â > >> LSI HBA firmware update in not-so-distant
>>>>       future.
>>>>       >      > > Â  Â  Â  Â > >>
>>>>       >      > > Â  Â  Â  Â > >
>>>>       >      > > Â  Â  Â  Â > > Btw what was the version number of the
>>>>       LED-fixed LSI
>>>>       >      firmware?
>>>>       >      > > Â  Â  Â  Â > > I'm just wondering in which firmware series
>>>>       the fix
>>>>       >      might end up
>>>>       >      > > Â  Â  Â  Â being included..
>>>>       >      > > Â  Â  Â  Â > >
>>>>       >      > > Â  Â  Â  Â > > Also: Any updates on this?
>>>>       >      > > Â  Â  Â  Â > >
>>>>       >      > > Â  Â  Â  Â > > Thanks,
>>>>       >      > > Â  Â  Â  Â > >
>>>>       >      > > Â  Â  Â  Â > > -- Pasi
>>>>       >      > > Â  Â  Â  Â > >
>>>>       >      > > Â  Â  Â  Â >
>>>>       >      > > Â  Â  Â  Â > The fixed FW I had demonstrated for me was still
>>>>       >      14.0.0.0 - I've
>>>>       >      > > Â  Â  Â  Â been
>>>>       >      > > Â  Â  Â  Â > told it'll be rolled into the FW release
>>>>       currently on
>>>>       >      the site and
>>>>       >      > > Â  Â  Â  Â > posted at some point, but that they have no ETA
>>>>       for
>>>>       >      that.
>>>>       >      > > Â  Â  Â  Â >
>>>>       >      > >
>>>>       >      > > Â  Â  Â  Â I can now see P15 firmware available on LSI's
>>>>       website for
>>>>       >      9211-8i
>>>>       >      > > Â  Â  Â  Â (SAS2008 based HBA).
>>>>       >      > > Â  Â  Â  Â Sadly it's missing the releasenotes/changelogs for
>>>>       both
>>>>       >      the LSI bios
>>>>       >      > > Â  Â  Â  Â and firmware..
>>>>       >      > > Â  Â  Â  Â -- Pasi
>>>>       >      > >
>>>>       >      > > References
>>>>       >      > >
>>>>       >      > > Â  Â Visible links
>>>>       >      > > Â  Â 1. mailto:[7][8]rercola@pha.jhu.edu
>>>>       >      > > Â  Â 2. mailto:[8][9]pasik@iki.fi
>>>>       >      > > Â  Â 3. mailto:[9][10]pasik@iki.fi
>>>>       >      > > Â  Â 4. mailto:[10][11]pasik@iki.fi
>>>>       >      > > Â  Â 5. mailto:[11][12]pasik@iki.fi
>>>>       >      > --
>>>>       >      > To unsubscribe from this list: send the line "unsubscribe
>>>>       linux-scsi"
>>>>       >      in
>>>>       >      > the body of a message to [12][13]majordomo@vger.kernel.org
>>>>       >      > More majordomo info at
>>>>       >      Â [13][14]http://vger.kernel.org/majordomo-info.html
>>>>       >
>>>>       > References
>>>>       >
>>>>       >    Visible links
>>>>       >    1. mailto:[15]pasik@iki.fi
>>>>       >    2. mailto:[16]rercola@pha.jhu.edu
>>>>       >    3. mailto:[17]pasik@iki.fi
>>>>       >    4. mailto:[18]pasik@iki.fi
>>>>       >    5. mailto:[19]pasik@iki.fi
>>>>       >    6. mailto:[20]pasik@iki.fi
>>>>       >    7. mailto:[21]rercola@pha.jhu.edu
>>>>       >    8. mailto:[22]pasik@iki.fi
>>>>       >    9. mailto:[23]pasik@iki.fi
>>>>       >   10. mailto:[24]pasik@iki.fi
>>>>       >   11. mailto:[25]pasik@iki.fi
>>>>       >   12. mailto:[26]majordomo@vger.kernel.org
>>>>       >   13. [27]http://vger.kernel.org/majordomo-info.html
>>>>
>>>> References
>>>>
>>>>     Visible links
>>>>     1. mailto:pasik@iki.fi
>>>>     2. mailto:pasik@iki.fi
>>>>     3. mailto:rercola@pha.jhu.edu
>>>>     4. mailto:pasik@iki.fi
>>>>     5. mailto:pasik@iki.fi
>>>>     6. mailto:pasik@iki.fi
>>>>     7. mailto:pasik@iki.fi
>>>>     8. mailto:rercola@pha.jhu.edu
>>>>     9. mailto:pasik@iki.fi
>>>>    10. mailto:pasik@iki.fi
>>>>    11. mailto:pasik@iki.fi
>>>>    12. mailto:pasik@iki.fi
>>>>    13. mailto:majordomo@vger.kernel.org
>>>>    14. http://vger.kernel.org/majordomo-info.html
>>>>    15. mailto:pasik@iki.fi
>>>>    16. mailto:rercola@pha.jhu.edu
>>>>    17. mailto:pasik@iki.fi
>>>>    18. mailto:pasik@iki.fi
>>>>    19. mailto:pasik@iki.fi
>>>>    20. mailto:pasik@iki.fi
>>>>    21. mailto:rercola@pha.jhu.edu
>>>>    22. mailto:pasik@iki.fi
>>>>    23. mailto:pasik@iki.fi
>>>>    24. mailto:pasik@iki.fi
>>>>    25. mailto:pasik@iki.fi
>>>>    26. mailto:majordomo@vger.kernel.org
>>>>    27. http://vger.kernel.org/majordomo-info.html
>>> --
>>> 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
>> --
>> 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
> --
> 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
>

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