From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 02:48:40 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 13DA3106566B; Tue, 26 Jan 2010 02:48:40 +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 CA8938FC15; Tue, 26 Jan 2010 02:48:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0Q2fJ7r061568; Mon, 25 Jan 2010 19:41:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 25 Jan 2010 19:42:07 -0700 (MST) Message-Id: <20100125.194207.1000278277145525469.imp@bsdimp.com> To: rrs@lakerest.net From: "M. Warner Losh" In-Reply-To: <20100125.191959.956847443352467531.imp@bsdimp.com> References: <489828.45501.qm@web34403.mail.mud.yahoo.com> <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> <20100125.191959.956847443352467531.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=us-ascii Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: AR71XX RTC 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, 26 Jan 2010 02:48:40 -0000 In message: <20100125.191959.956847443352467531.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> : Randall Stewart writes: : : Thanks that makes a LOT of sense.. So basically the : : mtx passed is NOT what is currently in td_lock and we : : want it updated as we switch. : : Yes. : : I think there still might be a bit of oddness here and there, since : the cavium port has a weird access to sysctl issue when a rm_lock is : involved. I'm not at all sure why that would be... It may be : scheduling related, but it may also just be some minor init the cavium : is doing that's just a bit off... Looks like the oddness was due to problems in octeon init code... We're past that now... Warner