Date: Wed, 24 Sep 2014 12:16:55 -0400 From: Ryan Stone <rysto32@gmail.com> To: Bryan Drewery <bdrewery@freebsd.org> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: Cam panic on r271170 Message-ID: <CAFMmRNzGTjOd98UP_vPYauRJBBG%2B4inMVPNsGURZz%2BbEeed_Vg@mail.gmail.com> In-Reply-To: <5422E7C4.8070801@FreeBSD.org> References: <5418F1B9.2000903@FreeBSD.org> <5419AB24.9050809@FreeBSD.org> <5422E7C4.8070801@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 24, 2014 at 11:48 AM, Bryan Drewery <bdrewery@freebsd.org> wrote: > Another, with much more information here: > https://people.freebsd.org/~bdrewery/cam.panic.txt > > This was with memguard (vm.memguard.desc="CAM CCB") and a KASSERT in > malloc(9) and uma_zalloc_arg() to prevent M_WAITOK in non-sleepable > threads. Neither triggered. Well that's unfortunate. Are CCBs ever the target of DMA? Does your hardware have an Intel chipset and is it new enough to support an IOMMU? You might try enabling the IOMMU, which would catch out-of-bounds DMA by hardware: http://svnweb.freebsd.org/changeset/base/257251 One caveat is that while I understand that the busdma infrastructure for this is quite well tested, individual drivers and devices need to be well-behaved so it's possible that this won't work on your hardware right now. Also, don't enable this if you use BHyve with PCI Passthrough.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNzGTjOd98UP_vPYauRJBBG%2B4inMVPNsGURZz%2BbEeed_Vg>