Date: Wed, 06 Mar 2013 09:08:04 -0800 From: Thomas Skibo <ThomasSkibo@sbcglobal.net> To: freebsd-arm@freebsd.org Subject: Re: Weird kernel mode data abort panic on Zedboard. Message-ID: <513777F4.60302@sbcglobal.net> In-Reply-To: <51358BEB.50603@sbcglobal.net> References: <51354125.4060500@sbcglobal.net> <51358BEB.50603@sbcglobal.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/4/13 10:08 PM, Thomas Skibo wrote: > > Oleksandr Tymoshenko : >> >> Just a hunch here - looks like TLB entry is not update properly. Might >> be missing >> PTE_SYNC in pmap-v6.c. Or current PTE_SYNC implementation does not cover >> all requirements for your platform. I'd say latter - but without proper >> debugging >> it's just guesswork. >> > > Thanks. On my platform, PMAP_NEEDS_PTE_SYNC was 0 and I convinced > myself earlier that the page tables were properly configured with > write-through caching and didn't need PTE_SYNC() anyway. I've had a chance to look at this some more. According to the Cortex-A9 manual, when the MMU is configured for write-through cacheing, it goes directly to external memory to read the page-table. So, PMAP_NEEDS_PTE_SYNC=0 is correct for my platform but I need PTE_SYNC() for the call to cpu_drain_writebuf(). I looked around again for missing PTE_SYNC()s and the only thing suspicious to me is that vector_page_setprot() doesn't have one. I think when I forced PMAP_NEEDS_PTE_SYNC to 1, the (unnecessary) cache ops just changed the timing of some kind of race condition somewhere else. I'll try to see what the other threads are doing when it crashes. THanks, -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?513777F4.60302>