From owner-freebsd-mips@FreeBSD.ORG Tue Jun 29 20:04:55 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 02A05106566B for ; Tue, 29 Jun 2010 20:04:55 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 916048FC12 for ; Tue, 29 Jun 2010 20:04:54 +0000 (UTC) Received: by pvc30 with SMTP id 30so9178pvc.13 for ; Tue, 29 Jun 2010 13:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5HmlC5+gxnq+uAtl1s/7u8KJxRSYwTYSdAXNN9vwg7I=; b=hnl8YPxMutiuQeG25KFaWXWjhDZgGFITJDej7tVcCtPBSO/wPAnD1etJxAGjw0u2rC 7dGEob2+E5QUnu44hcltOFIik7ud4cjmBnQZaQKhMlm4PPyBJngWa0oPMQbXZ0+eXqL3 K2l+hpFEq+uDZDn/AK/Zbvh2M7DfPTzb4R3AE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tXsW3gQUDYefsQ/fROMZE8TEnH7MnaEkBH5UwXOrgh81gdeTi2EPZRJ/2oTiuWR4cY 9TXi7tTX7zh/5NLOixVEGNxVPvrND3YAXrjrPxDPDgrBQujHldeLStOrWQtcBKdZYi4U DB4sYEOlLvdxPBbkhBXPphRzjtHrY5Wf2qK1Q= MIME-Version: 1.0 Received: by 10.142.215.19 with SMTP id n19mr3779880wfg.336.1277841872631; Tue, 29 Jun 2010 13:04:32 -0700 (PDT) Received: by 10.142.126.2 with HTTP; Tue, 29 Jun 2010 13:04:32 -0700 (PDT) In-Reply-To: <20100629.112421.25793712605171655.imp@bsdimp.com> References: <20100629.112421.25793712605171655.imp@bsdimp.com> Date: Tue, 29 Jun 2010 13:04:32 -0700 Message-ID: From: Neel Natu To: "M. Warner Losh" 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:04:55 -0000 Hi, On Tue, Jun 29, 2010 at 10:24 AM, M. Warner Losh wrote: > In message: > =A0 =A0 =A0 =A0 =A0 =A0"Jayachandran C." write= s: > : 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 failing= , > : >> may be the new tlb_update code causes this. =A0Can you apply the > : >> attached patch and see if the problem still persists, it replaces th= e > : >> new tlb_update code with the older version. > : >> > : >> Obviously not a fix, but if we can narrow it down to this function, > : >> fixing will be easier. > : >> > : >> JC. > : >> > : > > : > JC, > : > > : > This fix the problem ! Thanks ! Now, at least, you know where to look= :) > : > : The new tlb_update does not seem to update the tlb entry if the tlbp > : 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 could als= o > : try try the nop-change.diff attached. It tries to switch the ssnop > : used for delay in the new code with 'nop' which was used by the old > : code. > > ssnop is a mips32r2/mips64r2 addition. =A0We likely need to get smarter > about the nop stuff, based on the CPU we configure. =A0I can't recall if > the Atheros is misp32 or mips32r2. =A0IIRC, the idt RC32434 is mips32, > as is the adm5120... > It seems that ssnop should be identical to nop on non-superscalar processor= s. 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? best Neel > Warner > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >