Date: Sun, 01 Nov 2015 09:11:51 -0700 From: Ian Lepore <ian@freebsd.org> To: Jason Harmening <jason.harmening@gmail.com>, Ganbold Tsagaankhuu <ganbold@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r289759 - in head/sys/arm: arm include Message-ID: <1446394311.91534.236.camel@freebsd.org> In-Reply-To: <CAM=8qa=4EqPvRoUnMytQBe32GtvPRZRE_s34tOzmVNCLe8c=Fw@mail.gmail.com> References: <201510221638.t9MGc1cc053885@repo.freebsd.org> <CAGtf9xOx_iSNqsPT7OdTmAy-ER_wFzOC9YxFigpQ%2B0wLj7=ytQ@mail.gmail.com> <56348FF8.3010602@gmail.com> <CAM=8qa=4EqPvRoUnMytQBe32GtvPRZRE_s34tOzmVNCLe8c=Fw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2015-11-01 at 07:01 -0600, Jason Harmening wrote: > On Sat, Oct 31, 2015 at 4:55 AM, Jason Harmening < > jason.harmening@gmail.com> > wrote: > > > > > > > On 10/31/15 03:21, Ganbold Tsagaankhuu wrote: > > > On Fri, Oct 23, 2015 at 12:38 AM, Jason A. Harmening < > > > jah@freebsd.org> > > > wrote: > > > > > > > Author: jah > > > > Date: Thu Oct 22 16:38:01 2015 > > > > New Revision: 289759 > > > > URL: https://svnweb.freebsd.org/changeset/base/289759 > > > > > > > > Log: > > > > Use pmap_quick* functions in armv6 busdma, for bounce buffers > > > > and > > cache > > > > maintenance. This makes it safe to sync buffers that have no > > > > VA mapping > > > > associated with the busdma map, but may have other mappings, > > > > possibly on > > > > different CPUs. This also makes it safe to sync unmapped > > > > bounce > > buffers in > > > > non-sleepable thread contexts. > > > > > > > > Similar to r286787 for x86, this treats userspace buffers the > > > > same as > > > > unmapped buffers and no longer borrows the UVA for sync > > > > operations. > > > > > > > > Submitted by: Svatopluk Kraus <onwahe@gmail.com> > > > > (earlier > > > > revision) > > > > Tested by: Svatopluk Kraus > > > > Differential Revision: > > > > https://reviews.freebsd.org/D3869 > > > > > > > > > > > > It seems I can't boot Odroid C1 with this change. > > > > > > http://pastebin.ca/3227678 > > > > > > r289758 works for me. > > > > > > Am I missing something? > > > > > > thanks, > > > > > > Ganbold > > > > > > > > > > Hmmm, the fault address of 0x20 and the fact that this is happening > > during mi_startup() make me wonder if the per-cpu pageframes used > > by > > pmap_quick* haven't been initialized yet. > > > > I wonder if changing the order of qpages_init in > > sys/arm/arm/pmap-v6[-new].c to something other than SI_ORDER_ANY > > would > > help? > > > > It seems like we'd want SI_ORDER_FOURTH or SI_ORDER_MIDDLE, since > > mp_start() is SI_ORDER_THIRD. > > > > It would be nice to know what's calling bus_dmamap_sync() in this > > case. > > I can't figure that out, but maybe that's because I haven't had > > coffee > > yet. > > > > > Can you build the kernel with 'options VERBOSE_SYSINIT' ? > That will add some spew to the boot log, but it should confirm > whether this > is a sysinit ordering issue. It's almost certainly not related to sysinit ordering. This exception is happening during mmc probing after interrupts are enabled. It appears that the problem is the faulting code is running on one of the very early pre-allocated kernel stacks (perhaps in an interrupt handler on an idle thread stack), and these stacks are not in memory represented in the vm page arrays. The mmc code is using a 64-byte buffer on the stack and mapping it for DMA. Normally that causes a bounce for cacheline alignment, but unluckily in this case that buffer on the stack just happened to be aligned to a cacheline boundary and a multiple of the cacheline size, so no bounce. That causes the new sync logic that is based on keeping vm_page_t pointers and offsets to get a NULL pointer back from PHYS_TO_VM_PAGE when mapping, then it dies at sync time trying to dereference that. It used to work because the sync logic used to use the vaddr, not a page pointer. Michal was working on a patch yesterday. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1446394311.91534.236.camel>