Date: Wed, 2 Oct 2013 13:30:23 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: freebsd-hackers@freebsd.org, Alexander Motin <mav@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking Message-ID: <201310021330.23251.jhb@freebsd.org> In-Reply-To: <522AC88D.4070005@FreeBSD.org> References: <5224511D.4090503@FreeBSD.org> <20130906230236.GI43281@caravan.chchile.org> <522AC88D.4070005@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: > On 07.09.2013 02:02, Jeremie Le Hen wrote: > > On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: > >> On 06.09.2013 11:06, Jeremie Le Hen wrote: > >>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labb=E9 wro= te: > >>>> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin <mav@freebsd.org>=20 wrote: > >>>>> I've found and fixed possible double request completion, that could= =20 cause > >>>>> such symptoms if happened. Updated patch located as usual: > >>>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.pat= ch > >>>>> > >>> With this new one I cannot boot any more (I also updated the source > >>> tree). This is a hand transcripted version: > >>> > >>> Trying to mount root from zfs:zroot/root []... > >>> panic: Batch flag already set > >>> cpuid =3D 1 > >>> KDB: stack backtrace: > >>> db_trace_self_wrapper() > >>> kdb_backtrace() > >>> vpanic() > >>> kassert_panic() > >>> xpt_batch_start() > >>> ata_interrupt() > >>> softclock_call_cc() > >>> softclock() > >>> ithread_loop() > >>> fork_exit() > >>> fork_trampoline() > >> > >> Thank you for the report. I see my fault. It is probably specific to > >> ata(4) driver only. I've workarounded that in new patch version, but > >> probably that area needs some rethinking. > >> > >> http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch > > > > I'm not sure you needed a confirmation, but it boots. Thanks :). > > > > I didn't quite understand the thread; is direct dispatch enabled for > > amd64? ISTR you said only i386 but someone else posted the macro for > > amd64. >=20 > Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd64. =46YI, I tested mfi with this patch set and mfid worked fine for handling g= _up directly: Index: dev/mfi/mfi_disk.c =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- dev/mfi/mfi_disk.c (revision 257407) +++ dev/mfi/mfi_disk.c (working copy) @@ -162,6 +162,7 @@ sc->ld_disk->d_unit =3D sc->ld_unit; sc->ld_disk->d_sectorsize =3D secsize; sc->ld_disk->d_mediasize =3D sectors * secsize; + sc->ld_disk->d_flags =3D DISKFLAG_DIRECT_COMPLETION; if (sc->ld_disk->d_mediasize >=3D (1 * 1024 * 1024)) { sc->ld_disk->d_fwheads =3D 255; sc->ld_disk->d_fwsectors =3D 63; = =20 =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310021330.23251.jhb>