Date: Sun, 1 Nov 2015 07:01:16 -0600 From: Jason Harmening <jason.harmening@gmail.com> To: 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: <CAM=8qa=4EqPvRoUnMytQBe32GtvPRZRE_s34tOzmVNCLe8c=Fw@mail.gmail.com> In-Reply-To: <56348FF8.3010602@gmail.com> References: <201510221638.t9MGc1cc053885@repo.freebsd.org> <CAGtf9xOx_iSNqsPT7OdTmAy-ER_wFzOC9YxFigpQ%2B0wLj7=ytQ@mail.gmail.com> <56348FF8.3010602@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM=8qa=4EqPvRoUnMytQBe32GtvPRZRE_s34tOzmVNCLe8c=Fw>