Date: Sun, 1 Nov 2015 14:31:53 +0100 From: Michal Meloun <mmel@freebsd.org> To: svn-src-head@freebsd.org Subject: Re: svn commit: r289759 - in head/sys/arm: arm include Message-ID: <56361449.3010709@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dne 01.11.2015 v 14:01 Jason Harmening napsal(a): > > > On Sat, Oct 31, 2015 at 4:55 AM, Jason Harmening > <jason.harmening@gmail.com <mailto: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 <mailto: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 > <mailto: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. > The problem is already identified. ARM uses VM_PHYSSEG_SPARSE memory. This means that not all used memory is backed by vm_page_array, i.e kernel code, data, bss sections and initial CPU stacks are outside of this array. Unfortunately, some drivers (MMC for example) initiates DMA transfer to buffers on initial stack, (statically allocated buffers in bss or data section is second example). I have prepared (idea quality) patch, and I can confirm that works (for Ganbold). See: https://gist.github.com/strejda/d5ca3ed202427a2e0557 Michal -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWNhRJAAoJEGkesmtexaqq4g8H/imNISydjQC667Xh3Xe+wp3g 2yL3y1vijJwoIjIwhXC8UdFY1cTh4h7eReVPA6emreo2IFWPADWXbtHjJP50x/Sy SVT3vteQu2Z8EOrPdUxbVJQFs/ZA2wLHWKsKQruuFQzdyE+zd52G/L77nodmU4+O Zrq3NACqGp9/VPNQtwlMx347wE4V/a6QHYE2jh+s9rp1zkt/MhoTZWDmgNMRn1KR eiIfXf48l2m6TsRMTdJlroa5Vaxv8QWfx7aqO6/5XSu1MyGuxbeD51iJkNsUYO42 nzP+nodx5xonyPgtLbqWPwFpTM8//ipLCBWF2w0VYws/N4FcCNChbxS0fLL3Fho= =PfNh -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56361449.3010709>