Date: Fri, 10 Jul 2009 08:07:47 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: mih@semihalf.com, tinguely@casselton.net Cc: freebsd-arm@freebsd.org Subject: Re: pmap problem in FreeBSD current Message-ID: <200907101307.n6AD7lZT081110@casselton.net> In-Reply-To: <4A56FB72.9040807@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi Mark, > We've diagnosed the problem and it was related to arm_nocache_remap(). > When the page was remaped into non-cacheable virtual memory region > there was no dcache write-back operation, so count of free items in > slab had differ value then should had. > This write-back operation should have been done in pmap_set_cache_entry() > but PVF_REF flag was missing so this part of code was omitted. > > I think that we should enable PVF_REF flag in pmap_enter_pv(). > > ================================================ > > diff --git a/sys/arm/arm/pmap.c b/sys/arm/arm/pmap.c > index 3cdab65..133dc6d 100644 > --- a/sys/arm/arm/pmap.c > +++ b/sys/arm/arm/pmap.c > @@ -1683,7 +1683,7 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry > *pve, pmap_t pm, > /* PMAP_ASSERT_LOCKED(pmap_kernel()); */ > pve->pv_pmap = pmap_kernel(); > pve->pv_va = pg->md.pv_kva; > - pve->pv_flags = PVF_WRITE | PVF_UNMAN; > + pve->pv_flags = PVF_WRITE | PVF_UNMAN | PVF_REF; > pg->md.pv_kva = 0; > > TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); > > ================================================= > > With this patch I've had no panics. > > Many thanks, > Michał Hajduk > Good job. This strange, your inclusion writes back the whole page of the original buffer. This writeback of just the original buffer size should be done in bus_dmamem_alloc() in busdma_machdep.c after the arm_remap_nocache() with the line "cpu_idcache_wbinv_range(vm_offset_t)*vaddr, dmat->maxsize)". I wonder if your cpu_idcache_wbinv_range() implementation correctly wb/invalidates when the buffer is not cache line aligned or is smaller than a cache-line? The other situation that would do this is if your cache line larger than you think. I know the ARMv7 use 64 byte caches instead of the more traditional 32 bytes. This should not be your case because last week I looked up your processor information and thought it said it used a 32 byte cache line. Did http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff fix the lock problems? Thank-you for the test information and the code scouting. --Mark Tinguely.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907101307.n6AD7lZT081110>