From owner-svn-src-head@FreeBSD.ORG Sat Sep 6 23:03:14 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B783CA9; Sat, 6 Sep 2014 23:03:14 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47FA510BA; Sat, 6 Sep 2014 23:03:13 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s86N2Nmj012874; Sat, 6 Sep 2014 18:03:11 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp2.rice.edu with ESMTP id 1p7nyb09nm-1; Sat, 06 Sep 2014 18:03:10 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 5D1D84C01C5; Sat, 6 Sep 2014 18:03:10 -0500 (CDT) Message-ID: <540B92AD.6020905@rice.edu> Date: Sat, 06 Sep 2014 18:03:09 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Chadd 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 References: <53e0a76b.5936.428818a9@svn.freebsd.org> <540B8457.2020500@rice.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.605690798989426 urlsuspect_oldscore=0.00569079898942585 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.605690798989426 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409060267 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Gleb Smirnoff , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 23:03:14 -0000 On 09/06/2014 17:36, Adrian Chadd wrote: > On 6 September 2014 15:01, Alan Cox 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?