Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Jun 2012 19:17:11 -0500
From:      Dustin Wenz <dustinwenz@ebureau.com>
To:        Kyle Creyts <kcreyts@merit.edu>
Cc:        "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>
Subject:   Re: Marginal disks prevent boot with mps(4)
Message-ID:  <404902E8-1144-4B39-9C03-FAC38FAA853C@ebureau.com>
In-Reply-To: <y984pnvpgpi3v7gt5e0rytw2.1339216725549@email.android.com>
References:  <y984pnvpgpi3v7gt5e0rytw2.1339216725549@email.android.com>

next in thread | previous in thread | raw e-mail | index | archive | help
That workaround is effective, but hard to execute when the system is on the o=
ther side of town. It is also difficult to identify the affected disk when t=
here are several dozen connected in a JBOD chassis. As Ken suggested, I'm go=
ing to investigate possible HBA and expander firmware issues on Monday.=20

    - .Dustin

On Jun 8, 2012, at 11:38 PM, Kyle Creyts <kcreyts@merit.edu> wrote:

> Pop the offending disk out, then back in after boot. Consider replacing.
>=20
> Dustin Wenz <dustinwenz@ebureau.com> wrote:
>=20
> I just installed a build of 9.0-STABLE in order to test the changes since r=
elease. I was hoping that some of the error-handling in mps would alter the b=
ehavior I've seen with some SATA disks (particularly, Seagate ST3000DM001 di=
sks) connected through an LSI SAS 9201-16e HBA.
>=20
> It is apparently possible for these disks to get in a state where their pr=
esence prevents the machine from booting. This problem has existed for some t=
ime, according to some archive-searching I've done, but there isn't much con=
sensus on how to fix it.
>=20
> The disks are good enough that they can be probed at startup, but some par=
t of initialization cannot complete. This is the message I see repeated fore=
ver upon boot (the probe number does change slightly):
>=20
>    (probe14:mps0:0:14:0): INQUIRY. CDB: 12 0 0 0 24 0 length 36 SMID 215 t=
erminated ioc 804b scsi 0 state c xfer 0
>=20
> There is a comment in mps_sas.c which suggests that this error is usually t=
ransient, but that seems not to be the case here. Can anyone suggest a modif=
ication that might permit booting in this state?
>=20
>    - .Dustin
>=20
> _______________________________________________
> freebsd-scsi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?404902E8-1144-4B39-9C03-FAC38FAA853C>