Test Run with Alternative pmap Implementation

[Svatopluk Kraus]

On Mon, Nov 24, 2014 at 3:53 PM, Ian Lepore <ian at freebsd.org> wrote:

> On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote:
> > Hello,
> >
> > as a starting point I have build an image (crochet, wandboard-quad) with
> > the source tree from here (751adfd(master)):
> >
> > https://github.com/strejda/freebsd
> >
> > Then I build the kernel with new pmap and rebuild the whole systen.
> > The system I used for the test run is entirely build on the
> > wandboard-quad.
> > [...]
>
> I've also been testing those pmap changes this weekend.  The only change
> I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel
> config.  In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that
> in effect I'm also testing the recent busdma changes).
>
> I've had two wandboard quads doing builds continuously all weekend.  I
> did the builds that have previously been reported as problems here --
> buildworld -j10, ports libX11, plus a lot of other ports including much
> of the full xorg (until it ran into some x86 device drivers and died),
> some of libreoffice (it had a problem that wasn't related to crashing or
> anything), python, bash, emacs, boost, rsync.
>
> After all that I just set both boards to continuously doing "rm
> -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still
> running.  One is using an SSD drive and the other is using NFS.
>
> In all that building all weekend the only glitches I've seen are this:
>
>   warning: pmap_remove_pages called with non-current pmap
>
> that appeared twice on the board using NFS root.
>
>


It could be false positive prints due to the way how current pmap is got
there. Even if I know that PCPU_GET() is not atomic and need to be wrapped
in this case at least by sched_pin() and sched_unpin() calls, I missed
it there.

Svata




> For anyone else wanting to test, there is currently one conflict when
> applying the patches, in busdma_machdep-v6.c, because some of the
> changes in the patch have already been applied.  Just resolve the
> conflict by skipping that file / restoring the original unpatched file.
>
> This stuff is looking really good.  It wouldn't hurt at all if some more
> people were testing it, especially on other hardware including rpi and
> beaglebone.
>
> -- Ian
>
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>