On 09/06/2014 17:36, Adrian Chadd wrote: > On 6 September 2014 15:01, Alan Cox <a...@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? _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"