Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 Sep 2014 18:03:09 -0500
From:      Alan Cox <alc@rice.edu>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>
Subject:   Re: svn commit: r269577 - in head/sys: amd64/include arm/arm arm/include conf i386/i386 i386/include kern mips/include mips/mips  powerpc/include powerpc/powerpc sparc64/include sparc64/sparc64 sys
Message-ID:  <540B92AD.6020905@rice.edu>
In-Reply-To: <CAJ-VmokfZ00PC6cS__T4aGxSqremJvf5giQ2jnbKrkwAD%2BHFPA@mail.gmail.com>
References:  <53e0a76b.5936.428818a9@svn.freebsd.org>	<CAJ-Vmo=unqEzguB5jh9KdbF7dfJfgv5B_MBzntAq92EJD0%2BYVw@mail.gmail.com>	<540B8457.2020500@rice.edu> <CAJ-VmokfZ00PC6cS__T4aGxSqremJvf5giQ2jnbKrkwAD%2BHFPA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 09/06/2014 17:36, Adrian Chadd wrote:
> On 6 September 2014 15:01, Alan Cox <alc@rice.edu> wrote:
>> On 09/06/2014 16:15, Adrian Chadd wrote:
>>> Hi Gleb!
>>>
>>> This commit has broken mips32 on my 128MB RAM routerstation pro board.
>>>
>>> I've tested the commit before this one (and it works).
>>>
>>> I've also tested today's -HEAD as there was some subsequent fixes to
>>> the sfbuf code. It hasn't completely fixed things - I still see
>>> processes throwing VM errors:
>>
>> Before this commit, the sf_buf code did not cache mappings on MIPS.
>> Now, it does.  So, I suspect that you're experiencing cache consistency
>> issues.  To return to the pre-commit state, you'll need to define
>> machine-dependent sf_buf_{un,}map() functions in mips/include/sf_buf.h
>> for mips32 that call pmap_q{remove,enter}, respectively.  Look at arm
>> for a similar configuration.
> Yup, I just noticed that, fixed it, and updated the bug (bug 193400.)
>
> Is this something that should be fixed in the vm/pmap code somewhere,
> or is this just the correct behaviour?

No.  However, if you feel like tinkering, you could replace the body of
sf_buf_unmap() with

mips_dcache_wbinv_range_index(va, PAGE_SIZE);
return (0);

and see what happens.

Can you remind me what the cache configuration is on mip32?  Does
software only have to worry about I and D cache consistency?




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540B92AD.6020905>