Skip site navigation (1)Skip section navigation (2)
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>