From owner-freebsd-mips@FreeBSD.ORG Tue Jun 29 20:30:59 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354B3106567A for ; Tue, 29 Jun 2010 20:30:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DCC5E8FC18 for ; Tue, 29 Jun 2010 20:30:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5TKOvPP014167; Tue, 29 Jun 2010 14:24:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 29 Jun 2010 14:25:11 -0600 (MDT) Message-Id: <20100629.142511.47726460528861958.imp@bsdimp.com> To: neelnatu@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100629.112421.25793712605171655.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: Merging 64 bit changes to -HEAD X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 20:30:59 -0000 In message: Neel Natu writes: : Hi, : = : On Tue, Jun 29, 2010 at 10:24 AM, M. Warner Losh wro= te: : > In message: : > =A0 =A0 =A0 =A0 =A0 =A0"Jayachandran C." = writes: : > : On Tue, Jun 29, 2010 at 2:28 AM, Luiz Otavio O Souza wrote: : > : >> Thanks for the the update. Looks like pmap_map for kernel is f= ailing, : > : >> may be the new tlb_update code causes this. =A0Can you apply t= he : > : >> attached patch and see if the problem still persists, it repla= ces the : > : >> new tlb_update code with the older version. : > : >> : > : >> Obviously not a fix, but if we can narrow it down to this func= tion, : > : >> fixing will be easier. : > : >> : > : >> JC. : > : >> : > : > : > : > JC, : > : > : > : > This fix the problem ! Thanks ! Now, at least, you know where t= o look :) : > : : > : The new tlb_update does not seem to update the tlb entry if the t= lbp : > : fails. =A0Here's a patch that should make the new function behave= like : > : the older one. =A0The patch is in attached file 'tlb-update.diff'= .= : > : : > : If that does not work, I'm not sure what the issue is. =A0You cou= ld also : > : try try the nop-change.diff attached. It tries to switch the ssno= p : > : used for delay in the new code with 'nop' which was used by the o= ld : > : code. : > : > ssnop is a mips32r2/mips64r2 addition. =A0We likely need to get sma= rter : > about the nop stuff, based on the CPU we configure. =A0I can't reca= ll if : > the Atheros is misp32 or mips32r2. =A0IIRC, the idt RC32434 is mips= 32, : > as is the adm5120... : > : = : It seems that ssnop should be identical to nop on non-superscalar pro= cessors. : = : Here is the snippet from vol2 of the mips64 architecture manual. : = : : Format: : MIPS32 : SSNOP : Purpose: : Break superscalar issue on a superscalar processor. : Description: : SSNOP is the assembly idiom used to denote superscalar no operation. : The actual instruction is interpreted by the : hardware as SLL r0, r0, 1. : This instruction alters the instruction issue behavior on a : superscalar processor by forcing the SSNOP instruction to : single-issue. The processor must then end the current instruction : issue between the instruction previous to the SSNOP : and the SSNOP. The SSNOP then issues alone in the next issue slot. : On a single-issue processor, this instruction is a NOP that takes an = issue slot. : : = : It may lead to less efficient code on multiple issue processors but : replacing a nop with an ssnop should be always be safe, right? You're right. For processors that don't support ssnop, it is identical to nop. But a single ssnop may not be sufficient on all processors. But, as a practical matter, I think that 4 ssnops is the same as 4 nops and sufficient for tlb hazards. However, I was confusing ssnop with ehb (and jump variants). ehb in MIPS{32,64}R2 processors so that a single instruction will delay the right amount to prevent any CP0 and other hazards. I'd argue we should use these instructions on R2 processors, since they are more efficient than guessing the right number of nops. Shorter too :) Warner