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>