Date: Thu, 23 May 2013 14:44:41 +0530 From: "Desai, Kashyap" <Kashyap.Desai@lsi.com> To: Steven Hartland <killing@multiplay.co.uk>, "Saxena, Sumit" <Sumit.Saxena@lsi.com>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org> Subject: RE: LSI megaRAID controller: Kernel panic on virtual disk creation Message-ID: <B2FD678A64EAAD45B089B123FDFC3ED76076415061@inbmail01.lsi.com> In-Reply-To: <61D801516363429F9401F2D11FC214E3@multiplay.co.uk> References: <088E451FE1854947BD9145EF8C016FF4139FE16FFC@inbmail01.lsi.com> <61D801516363429F9401F2D11FC214E3@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve:
Thanks for your suggestion. We found the root cause of this issue. In our e=
nvironment we had few drives which fails to respond READ CAP 16 even though=
it is SPC-3 complaint.=20
Recently upstream kernel added code for read cap 16 predication based on SP=
C-3 flag from Inquiry in side "daregister(struct cam_periph *periph, void *=
arg)"
/* Predict whether device may support READ CAPACITY(16). */
if (SID_ANSI_REV(&cgd->inq_data) >=3D SCSI_REV_SPC3) {
softc->flags |=3D DA_FLAG_CAN_RC16;
softc->state =3D DA_STATE_PROBE_RC16;
}
Above code will force OS to only send READ CAP 16 for drives which are SPC3=
compliant. They never try REAC CAP 10.
Check below link. There is already discussion at upstream to debate this is=
sue.=20
http://lists.freebsd.org/pipermail/freebsd-fs/2013-January/016278.html
There may be some drives which are SPC-3 complaint but do not follow comple=
te spec and will have failure for some SCSI commands.
So considering SCSI_REV_SPC3 or greater does not means all Drives will alwa=
ys respond to READ CAP16.=20
We should try to fall back to READ CAP 10 if Read cap 16 fails.
Thanks, Kashyap
> -----Original Message-----
> From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd-
> scsi@freebsd.org] On Behalf Of Steven Hartland
> Sent: Friday, May 17, 2013 7:46 PM
> To: Saxena, Sumit; freebsd-scsi@freebsd.org
> Subject: Re: LSI megaRAID controller: Kernel panic on virtual disk
> creation
>=20
> That indeed doesn't look like look like an issue unrelated to driver.
>=20
> Could you provide information on which version your running and what the
> exact command you where running to create the panic?
>=20
> While I'm here IIRC 9286 is a 2208 chipset card, so MegaRAI based, which
> I did some significant fixes for our MFI driver in r247367 &
> r247369 so might be worth reviewing to see if any of thats needed in
> mrsas?
>=20
> Regards
> Steve
> ----- Original Message -----
> > Hi ,
> >
> > While doing some testing on "mrsas" driver(LSIs' latest driver for
> > next generation MegaRAID controllers- which will soon be submitted to
> > upstream kernel), I am facing kernel panic while creating Virtual
> drive(RAID0) on LSI controller-9286-e (6 Gb/s RAID controller). I am
> using latest upstream kernel. The error message seen on panic is:
> >
> > "reboot after panic: Provider da1 lacks sectorsize"
> >
> > Below is the call stack:
> >
> > ----------------------------------------------
> > kdb_enter() at kdb_enter+0x3e/frame 0xffffff8000285920
> > vpanic() at vpanic+0x146/frame 0xffffff8000285960
> > kassert_panic() at kassert_panic+0x136/frame 0xffffff80002859d0
> > g_access() at g_access+0x3ba/frame 0xffffff8000285a60
> > g_raid_md_taste_jmicron() at g_raid_md_taste_jmicron+0x6d/frame
> > 0xffffff8000285b00
> > g_raid_taste() at g_raid_taste+0x17f/frame 0xffffff8000285b50
> > g_new_provider_event() at g_new_provider_event+0xda/frame
> > 0xffffff8000285b70
> > g_run_events() at g_run_events+0x1a7/frame 0xffffff8000285bb0
> > fork_exit() at fork_exit+0x84/frame 0xffffff8000285bf0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8000285bf0
> > --- trap 0, rip =3D 0, rsp =3D 0xffffff8000285cb0, rbp =3D 0 ---
> > -------------------------------------------------
> >
> > "/dev/da1" is virtual drive created.
> >
> > The problem does not seems to be related to <mrsas> driver. call stack
> indicates that panic is observed in GEOM module.
> > Has someone face such issue earlier related to GEOM module?
>=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> This e.mail is private and confidential between Multiplay (UK) Ltd. and
> the person or entity to whom it is addressed. In the event of
> misdirection, the recipient is prohibited from using, copying, printing
> or otherwise disseminating it or any information contained in it.
>=20
> In the event of misdirection, illegible or incomplete transmission
> please telephone +44 845 868 1337 or return the E.mail to
> postmaster@multiplay.co.uk.
>=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?B2FD678A64EAAD45B089B123FDFC3ED76076415061>