Date: Thu, 27 Nov 2014 20:25:30 +0000 From: Ruslan Bukin <br@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r274914 - in head/sys: kern sys ufs/ffs vm Message-ID: <20141127202530.GA84608@bsdpad.com> In-Reply-To: <CAJ-Vmon9OMxvxAp9saOoCEQL%2B7npCt--Q4cyvMHFqDoHFY5iUg@mail.gmail.com> References: <20141124180356.GA47782@bsdpad.com> <20141124192902.GQ47144@FreeBSD.org> <20141124211620.GA49975@bsdpad.com> <20141125073145.GT47144@FreeBSD.org> <20141125122754.GA57252@bsdpad.com> <20141125152922.GX47144@FreeBSD.org> <20141125173830.GA60905@bsdpad.com> <CAJ-Vmo=vaLj6gR7%2BZ2r_a%2B__DcsAjBEjgWGMSsQedezhi7LNKg@mail.gmail.com> <20141127183629.GA83207@bsdpad.com> <CAJ-Vmon9OMxvxAp9saOoCEQL%2B7npCt--Q4cyvMHFqDoHFY5iUg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 27, 2014 at 11:28:31AM -0800, Adrian Chadd wrote: > On 27 November 2014 at 10:36, Ruslan Bukin <br@freebsd.org> wrote: > > Hi, > > > > There is a theory that a problem is related to CPU caches, and it can be BERI-cpu > > specific only. > > > > And sorry I didn't realized virtio was still in the kernel when I was trying > > MDROOT (we do dcache operations in virtio). > > > > The workaround I found is to disable all the instruction cache invalidation calls > > (there are a few calls on cpu startup only). > > > > Hm, can we test this on real MIPS hardware, just to be sure? > > I can spin this up on MIPS24k/MIPS74k hardware early next week. > It can be helpfull. It is easy to test, just insert mips_dcache_wbinv_all() call in some driver and ensure mips_cache_ops.mco_sdcache_wbinv_all is not NULL on your hardware, so the dcache invalidation call will invalidate both primary and secondary data caches. With virtio we are calling mips_dcache_wbinv_all() a few times per second (the good idea here is supposed to be more selective with physical addresses invalidation, but it should not hurt to data consistent as it do both writeback and flush) Ruslan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141127202530.GA84608>