From owner-svn-src-head@freebsd.org Sun Nov 1 16:11:59 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4361A2389C for ; Sun, 1 Nov 2015 16:11:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9277A14CE for ; Sun, 1 Nov 2015 16:11:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 1 Nov 2015 16:12:20 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tA1GBpo4040907; Sun, 1 Nov 2015 09:11:51 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1446394311.91534.236.camel@freebsd.org> Subject: Re: svn commit: r289759 - in head/sys/arm: arm include From: Ian Lepore To: Jason Harmening , Ganbold Tsagaankhuu Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Sun, 01 Nov 2015 09:11:51 -0700 In-Reply-To: References: <201510221638.t9MGc1cc053885@repo.freebsd.org> <56348FF8.3010602@gmail.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 16:11:59 -0000 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 > > > > (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