Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Feb 2012 13:54:53 +0530
From:      "Desai, Kashyap" <Kashyap.Desai@lsi.com>
To:        Jason Wolfe <nitroboost@gmail.com>
Cc:        "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>
Subject:   RE: LSI2008 controller clobbers first disk with new LSI mps driver
Message-ID:  <B2FD678A64EAAD45B089B123FDFC3ED72B96D344F2@inbmail01.lsi.com>
In-Reply-To: <CAAAm0r3MVHZixAKDF=ChD977PbNUC8dyiBFB=NzC30S8FeZ3Nw@mail.gmail.com>
References:  <CAAAm0r2NFhF=eh2bOPMnVN8E6e2o0KfaST0N-M_gWoJHpFOLmQ@mail.gmail.com> <CAAAm0r37H0Pf_HvFTqo%2B1RSCV%2BBkzD5EcXj5M40H9xGREr%2Bfow@mail.gmail.com> <B2FD678A64EAAD45B089B123FDFC3ED72B96D344CA@inbmail01.lsi.com> <CAAAm0r3MVHZixAKDF=ChD977PbNUC8dyiBFB=NzC30S8FeZ3Nw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jason,

Me also surprised when I see so many queries on <mps>.
Really wonderful to know that there are good amount of <mpslsi> driver use =
as well.

I was under impression that if you keep same FW and just change Driver, the=
re should not be any difference in Target IDs assigned to Device connected =
behind that HBA.

Is this possible for you to keep everything unchanged and just change Drive=
r version and see how things behaves. Please share "dmesg" logs of your bot=
h drivers.  BTW, did you tested "13.00.00.00-fbsd" and "11.00.00.00"  on sa=
me machine ?=20

FYI: We never observe this kind of issue in our lab.

` Kashyap

From: Jason Wolfe [mailto:nitroboost@gmail.com]=20
Sent: Friday, February 17, 2012 1:31 PM
To: Desai, Kashyap
Cc: freebsd-scsi@freebsd.org
Subject: Re: LSI2008 controller clobbers first disk with new LSI mps driver

Kashyap,

Ah a response from LSI, that's a pleasant surprise :) =A0Everything you've =
stated looks correct to me, the FreeBSD developed driver that has been repl=
aced by the LSI driver has no issues with either firmware. =A0Your likely a=
ware, but just to confirm, here is the history of the 3 various LSI drivers=
 that have the issue on the 10.00.02.00 FW:

11.00.00.00 - binary driver I had received from you guys in mid =A02011, mp=
slsi.ko, one for each 7.2-RELEASE and 8.2-RELEASE

11.255.03.00-fbsd - initial LSI driver committed to 8-STABLE on 2/2, r23092=
2

13.00.00.00-fbsd - commited to 8-STABLE on 2/14, r231680

I have about 40 boxes with the 10.00.02.00 FW I've tested, so I'm fairly ce=
rtain it's not bad hardware or a fluke. =A0You guys haven't seen anything l=
ike this in house? =A0I'd hate to hear I have to update the FW on these box=
es as they are all quite a ways from me, though it seems there is some way =
to work around the behavior in the driver as the FreeBSD one does? =A0I hav=
e a few of these boxes out of service so I'm game to try some things out sh=
ould that help.

Thank for the response,
Jason=A0

On Thu, Feb 16, 2012 at 11:29 PM, Desai, Kashyap <Kashyap.Desai@lsi.com> wr=
ote:
Jason,

I have gone through your data provided in this thread. It is well understoo=
d because of your descriptive data.

So What I understood here is:

1. You tested with HBA Fw "07.00.00.00" and "10.00.02.00"

2. you have run your test on two different LSI BIOS versions.
Grabbed from below line.
MPT2BIOS-7.11.00.00 (2010.07.29) / PRODUCT REVISION 7.00.00.00
MPT2BIOS-7.19.00.00 (2011.05.16) / PRODUCT REVISION 10.00.02.00

Now I am able to see below three difference in your setup.

See FW version and check starting target id, all three has different way of=
 assigning TargetIDs.
For first two case target id start with "8" but SES device assignment is di=
fferent.
Last case target id start with "1"


mps0: Firmware: 07.00.00.00, Driver: 11.255.03.00-fbsd (OR) 13.00.00.00-fbs=
d
> > <SEAGATE ST91000640SS 0001> at scbus0 target 8 lun 0 (pass0,da0)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 9 lun 0 (pass1,da1)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 10 lun 0 (pass2,da2)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 11 lun 0 (pass3,da3)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 12 lun 0 (pass4,da4)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 13 lun 0 (pass5,da5)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 14 lun 0 (pass6,da6)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 15 lun 0 (pass7,da7)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 16 lun 0 (pass8,da8)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 17 lun 0 (pass9,da9)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 18 lun 0 (pass10,da10)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 19 lun 0 (pass11,da11)
> > <LSI CORP SAS2X28 0717> at scbus0 target 20 lun 0 (ses0,pass12)

mps0: Firmware: 10.00.02.00, Driver: 13.00.00.00-fbsd
mps0: Firmware: 10.00.02.00, Driver: 11.00.00.00 (OR) 8.2-STABLE Inbox
> > <LSI CORP SAS2X28 0717> at scbus0 target 8 lun 0 (ses0,pass0)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 9 lun 0 (da0,pass1)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 10 lun 0 (da1,pass2)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 11 lun 0 (da2,pass3)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 12 lun 0 (da3,pass4)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 13 lun 0 (da4,pass5)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 14 lun 0 (da5,pass6)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 15 lun 0 (da6,pass7)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 16 lun 0 (da7,pass8)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 17 lun 0 (da8,pass9)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 18 lun 0 (da9,pass10)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 19 lun 0 (da10,pass11)

On the FBSD developed driver active in 8-STABLE prior to the LSI
Release (Firmware: 10.00.02.00)

> > <SEAGATE ST91000640SS 0001> at scbus0 target 1 lun 0 (pass0,da0)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 2 lun 0 (pass1,da1)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 3 lun 0 (pass2,da2)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 4 lun 0 (pass3,da3)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 5 lun 0 (pass4,da4)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 6 lun 0 (pass5,da5)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 7 lun 0 (pass6,da6)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 8 lun 0 (pass7,da7)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 9 lun 0 (pass8,da8)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 10 lun 0 (pass9,da9)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 11 lun 0 (pass10,da10)
> > <SEAGATE ST91000640SS 0001> at scbus0 target 12 lun 0 (pass11,da11)
> > <LSI CORP SAS2X28 0717> at scbus0 target 13 lun 0 (ses0,pass12)


In summary, =A0(please confirm)
1. you have not seen any issue if you use "07.00.00.00" FW version.
2. _but_ when you use "10.00.02.00" FW, with "13.00.00.00-fbsd" driver vers=
ion you are seeing
SES is detected before Drives as pass0.
3. When you use "10.00.02.00" FW with 8-STABLE inbox FBSD driver, you are f=
inding SES device detected after Drives.


All driver is doing here is asking CAM layer to scan Bus when there is any =
device added on that bus.
So depending upon actual target Id =A0assigned by FW, it will be detected t=
o camcontrol.

So bottom line is FW plays major role in sequencing Drives behind LSI contr=
oller.

=A0~ Kashyap



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