Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Feb 2012 12:59:18 -0700
From:      Jason Wolfe <nitroboost@gmail.com>
To:        "Desai, Kashyap" <Kashyap.Desai@lsi.com>
Cc:        "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "McConnell, Stephen" <Stephen.McConnell@lsi.com>
Subject:   Re: LSI2008 controller clobbers first disk with new LSI mps driver
Message-ID:  <CAAAm0r2x4wAkPzpJkCJ8FYnFkxb3RrXnENRZi-Kgfh=y3ZuqEA@mail.gmail.com>
In-Reply-To: <B2FD678A64EAAD45B089B123FDFC3ED72B96D34840@inbmail01.lsi.com>
References:  <CAAAm0r2NFhF=eh2bOPMnVN8E6e2o0KfaST0N-M_gWoJHpFOLmQ@mail.gmail.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D344F2@inbmail01.lsi.com> <CAAAm0r02bXNve6Do5C1m1RyzLhWA9xx97KKMeLhcHC66U2SF4g@mail.gmail.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34500@inbmail01.lsi.com> <CAFPOs6pwb44oNabH5vabDPJyFutMKa5mhgvHY=HkQVpV20YiYw@mail.gmail.com> <CAAAm0r1pWN-F=madGdk7N%2BoRuZmSD5_MAYwLh6By126L0CTGuw@mail.gmail.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34558@inbmail01.lsi.com> <CAAAm0r1x15_ho2MD0tX7Y7A6mnU2N6zihNOz_Qz=jpsyBkDCWQ@mail.gmail.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D3455B@inbmail01.lsi.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34626@inbmail01.lsi.com> <CAAAm0r3_S2jTG=Te4UhLqHPqiXq7_aAOHNp=W3jb4KLJx9PTRg@mail.gmail.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34748@inbmail01.lsi.com> <CAAAm0r3oRTcfipyVcp9nE1CL3dcK7cft8AUSf%2BfGYVK90b2A0w@mail.gmail.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D347BB@inbmail01.lsi.com> <4F450814.4020100@interlog.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34840@inbmail01.lsi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 22, 2012 at 9:11 AM, Desai, Kashyap <Kashyap.Desai@lsi.com> wro=
te:
>
>
>> -----Original Message-----
>> From: Douglas Gilbert [mailto:dgilbert@interlog.com]
>> Sent: Wednesday, February 22, 2012 8:52 PM
>> To: Desai, Kashyap
>> Cc: Jason Wolfe; freebsd-scsi@freebsd.org; McConnell, Stephen
>> Subject: Re: LSI2008 controller clobbers first disk with new LSI mps
>> driver
>>
>> On 12-02-22 03:39 AM, Desai, Kashyap wrote:
>> > Here is a possible root cause of this issue.
>> >
>> > Enclosure which you are using in your setup (might be) not configured
>> properly.
>> >
>> > You have Enclosure with 12 Slots + 1 SES Device.
>> > See below detail from the log.
>> >
>> > =A0 =A0 EventDataLength: 5
>> > =A0 =A0 AckRequired: 0
>> > =A0 =A0 Event: SasEnclDeviceStatusChange (0x1d)
>> > =A0 =A0 EventContext: 0x0
>> > =A0 =A0 EnclosureHandle: 0x2
>> > =A0 =A0 ReasonCode: Added
>> > =A0 =A0 PhysicalPort: 0
>> > =A0 =A0 NumSlots: 13
>> > =A0 =A0 StartSlot: 0
>> > =A0 =A0 PhyBits: 0xff
>> >
>> > StartSlot is 0 in this case.
>> > Correct behavior should be each device on your enclosure must have
>> different slot number starting from 0 till 12.
>> > I have doubt that SES device has not configured well and it is using
>> slot-0 as default. This can create issue for actual device which is
>> connected to slot-0.
>> > So In your setup you will have slot-0 till slot-11 assigned for actual
>> Phys of your enclosures and again slot-0 is assigned for SES device
>> instead of Slot-12.
>>
>> No. SAS-2 expanders typically have an integral SES device on an
>> expander _virtual_ phy (see SMP DISCOVER (LIST) response). Once
>> you see that virtual phy flag the slot number is irrelevant.
>
> Doug,
>
> I need some more info so that I can understand your point better.
>
> I have one Enclosure setup on FreeBSD. Here is smp_discover output. (smp_=
discover_list is failing for me)
>
> phy =A0 0: inaccessible (phy vacant)
> =A0phy =A0 1: inaccessible (phy vacant)
> =A0phy =A0 2: inaccessible (phy vacant)
> =A0phy =A0 3: inaccessible (phy vacant)
> =A0phy =A0 4:S:attached:[500605b012345888:03 =A0i(SSP+STP+SMP)] =A06 Gbps
> =A0phy =A0 5:S:attached:[500605b012345888:02 =A0i(SSP+STP+SMP)] =A06 Gbps
> =A0phy =A0 6:S:attached:[500605b012345888:01 =A0i(SSP+STP+SMP)] =A06 Gbps
> =A0phy =A0 7:S:attached:[500605b012345888:00 =A0i(SSP+STP+SMP)] =A06 Gbps
> =A0phy =A012:D:attached:[5000c5003bc2c389:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A013:D:attached:[500000e116ee91e2:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A014:D:attached:[5000c5003bc308e5:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A015:D:attached:[5000c5003bc2f0d1:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A016:D:attached:[5000c5003bc2ff3d:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A017:D:attached:[5000c5003bae5fdd:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A018:D:attached:[5000c5003bae5eb1:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A019:D:attached:[5000c5003bc2d135:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A020:D:attached:[5000c5003baea36d:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A021:D:attached:[5000c5003bc2a8c9:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A022:D:attached:[5000c5003bc237a9:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A023:D:attached:[5000c5003bc2cec1:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A024:D:attached:[500000e01d92cb52:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A025:D:attached:[500000e01d74cfb2:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A026:D:attached:[500000e01d656052:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A027:D:attached:[500000e01d7cad52:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A028:D:attached:[500c04f2b64cdd1c:00 =A0t(SATA)] =A03 Gbps
> =A0phy =A029:D:attached:[500c04f2b64cdd1d:00 =A0t(SATA)] =A03 Gbps
> =A0phy =A030:D:attached:[500000e01d73c262:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A031:D:attached:[500000e01d536b22:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A032:D:attached:[500000e01d92cab2:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A033:D:attached:[500000e01afd8792:00 =A0t(SSP)] =A03 Gbps
> =A0phy =A034:D:attached:[5000c5003bc30301:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A035:D:attached:[5000c5003bb09a69:00 =A0t(SSP)] =A06 Gbps
> =A0phy =A036:D:attached:[500c04f2b64cdd3d:00 =A0V i(SSP) t(SSP)] =A06 Gbp=
s =A0 <--- This has virtual phy set.
>
> What I understood from your explanation is if we have virt_phy field set,=
 we should not trust slot for that entry.
> You are suggesting to use phy index instead of slot. Just for info: But h=
ow to see Slot details mapping with phy ?
>
> ~ Kashyap
>
>>
>> Doug Gilbert

Kashyap,

Let me know if there are any changes agreed upon, I'm happy to test
out patches as this is affecting a large number of our machines.  I
can only imagine the same for others as they start to upgrade, as this
is standard SuperMicro hardware.

Thanks,
Jason



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAAm0r2x4wAkPzpJkCJ8FYnFkxb3RrXnENRZi-Kgfh=y3ZuqEA>