From owner-freebsd-mips@FreeBSD.ORG Sun Nov 11 16:32:30 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 840C9254; Sun, 11 Nov 2012 16:32:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3480A8FC57; Sun, 11 Nov 2012 16:32:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGWQu4095875; Sun, 11 Nov 2012 11:32:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGWQJq095872; Sun, 11 Nov 2012 16:32:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:32:26 GMT Message-Id: <201211111632.qABGWQJq095872@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:32:30 -0000 TB --- 2012-11-11 16:26:13 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:26:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:26:13 - starting HEAD tinderbox run for mips/mips TB --- 2012-11-11 16:26:13 - cleaning the object tree TB --- 2012-11-11 16:26:13 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:26:13 - cd /tinderbox/HEAD/mips/mips TB --- 2012-11-11 16:26:13 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:26:23 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:35 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:27:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:27:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:27:18 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:28:18 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:28:31 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:28:31 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:30:01 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:30:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:30:13 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:32:13 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:32:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:32:26 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:32:26 - 2.59 user 6.09 system 372.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Sun Nov 11 16:41:26 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B37D61C7; Sun, 11 Nov 2012 16:41:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4E58FC9B; Sun, 11 Nov 2012 16:41:23 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGfMmD022783; Sun, 11 Nov 2012 16:41:22 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qABGfMxZ022777; Sun, 11 Nov 2012 16:41:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:41:22 GMT Message-Id: <201211111641.qABGfMxZ022777@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:41:26 -0000 TB --- 2012-11-11 16:33:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-11-11 16:33:00 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:33:00 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-11-11 16:33:00 - cleaning the object tree TB --- 2012-11-11 16:33:00 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-11-11 16:33:00 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-11-11 16:33:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:33:09 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:33:43 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:33:43 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:34:13 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:35:03 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:35:03 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:36:03 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:36:38 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:36:38 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:38:08 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:38:45 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:38:45 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:40:45 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:41:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:41:22 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:41:22 - 1.57 user 4.97 system 502.58 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Sun Nov 11 16:42:32 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 113048B5; Sun, 11 Nov 2012 16:42:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id AA8078FC96; Sun, 11 Nov 2012 16:42:28 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGgSJB011161; Sun, 11 Nov 2012 16:42:28 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qABGgSkY011158; Sun, 11 Nov 2012 16:42:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:42:28 GMT Message-Id: <201211111642.qABGgSkY011158@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:42:32 -0000 TB --- 2012-11-11 16:34:21 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-11 16:34:21 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-11 16:34:21 - starting RELENG_9 tinderbox run for mips/mips TB --- 2012-11-11 16:34:21 - cleaning the object tree TB --- 2012-11-11 16:34:21 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2012-11-11 16:34:21 - cd /tinderbox/RELENG_9/mips/mips TB --- 2012-11-11 16:34:21 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:34:53 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:35:28 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:35:28 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:35:58 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:36:25 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:36:25 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:37:25 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:37:53 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:37:53 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:39:23 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:39:51 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:39:51 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:41:51 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:42:28 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:42:28 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:42:28 - 3.66 user 4.81 system 486.33 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D47F8BD; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 56A9C8FC15; Sun, 11 Nov 2012 16:07:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABG7Dd6095649; Sun, 11 Nov 2012 11:07:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABG7DM8095647; Sun, 11 Nov 2012 16:07:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:07:13 GMT Message-Id: <201211111607.qABG7DM8095647@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 15:58:43 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 15:58:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 15:58:43 - starting HEAD tinderbox run for mips/mips TB --- 2012-11-11 15:58:43 - cleaning the object tree TB --- 2012-11-11 15:58:43 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 15:58:43 - cd /tinderbox/HEAD/mips/mips TB --- 2012-11-11 15:58:43 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:01:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:01:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:01:22 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:01:52 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:02:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:02:05 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:03:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:03:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:03:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:04:48 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:05:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:05:00 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:07:00 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:13 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:07:13 - 2.62 user 4.49 system 510.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Mon Nov 12 11:06:46 2012 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1155A0E for ; Mon, 12 Nov 2012 11:06:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C56798FC1A for ; Mon, 12 Nov 2012 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qACB6kV0000407 for ; Mon, 12 Nov 2012 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qACB6k1r000405 for freebsd-mips@FreeBSD.org; Mon, 12 Nov 2012 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Nov 2012 11:06:46 GMT Message-Id: <201211121106.qACB6k1r000405@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-mips@FreeBSD.org Subject: Current problem reports assigned to freebsd-mips@FreeBSD.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165951 mips [ar913x] [ath] DDR flush isn't being done for the WMAC p kern/163670 mips [mips][arge] arge can't allocate ring buffer on multip 2 problems total. From owner-freebsd-mips@FreeBSD.ORG Tue Nov 13 20:04:05 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAA22994; Tue, 13 Nov 2012 20:04:05 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id 833568FC13; Tue, 13 Nov 2012 20:04:05 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 764044C0243; Tue, 13 Nov 2012 14:04:04 -0600 (CST) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 74D984C0235; Tue, 13 Nov 2012 14:04:04 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id R8hsA5VhGzKj; Tue, 13 Nov 2012 14:04:04 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (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 A6BC84C0248; Tue, 13 Nov 2012 14:04:03 -0600 (CST) Message-ID: <50A2A7B2.2020302@rice.edu> Date: Tue, 13 Nov 2012 14:04:02 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> <20121112133638.GZ73505@kib.kiev.ua> <50A1336E.5040401@rice.edu> In-Reply-To: <50A1336E.5040401@rice.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , alc@freebsd.org, mips@freebsd.org, "Sears, Steven" , pho@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:04:05 -0000 On 11/12/2012 11:35, Alan Cox wrote: > On 11/12/2012 07:36, Konstantin Belousov wrote: >> On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote: >>> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: >>> >>>> On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: >>>>> I have a memory subsystem design question that I'm hoping someone can >>>> answer. >>>>> I've been looking at a machine that is completely out of memory, as in >>>>> >>>>> v_free_count = 0, >>>>> v_cache_count = 0, >>>>> >>>>> I wondered how a machine could completely run out of memory like this, >>>> especially after finding a lack of interrupt storms or other pathologies >>>> that would tend to overcommit memory. So I started investigating. >>>>> Most allocators come down to vm_page_alloc(), which has this guard: >>>>> >>>>> if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) { >>>>> page_req = VM_ALLOC_SYSTEM; >>>>> }; >>>>> >>>>> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || >>>>> (page_req == VM_ALLOC_SYSTEM && >>>>> cnt.v_free_count + cnt.v_cache_count > >>>> cnt.v_interrupt_free_min) || >>>>> (page_req == VM_ALLOC_INTERRUPT && >>>>> cnt.v_free_count + cnt.v_cache_count > 0)) { >>>>> >>>>> The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate >>>> every last page. >>>>> >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare, >>>> perhaps only used from interrupt threads. Not so, see kmem_malloc() or >>>> uma_small_alloc() which both contain this mapping: >>>>> if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>>>> pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>>>> else >>>>> pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>>>> >>>>> Note that M_USE_RESERVE has been deprecated and is used in just a >>>> handful of places. Also note that lots of code paths come through these >>>> routines. >>>>> What this means is essentially _any_ allocation using M_NOWAIT will >>>> bypass whatever reserves have been held back and will take every last page >>>> available. >>>>> There is no documentation stating M_NOWAIT has this side effect of >>>> essentially being privileged, so any innocuous piece of code that can't >>>> block will use it. And of course M_NOWAIT is literally used all over. >>>>> It looks to me like the design goal of the BSD allocators is on >>>> recovery; it will give all pages away knowing it can recover. >>>>> Am I missing anything? I would have expected some small number of pages >>>> to be held in reserve just in case. And I didn't expect M_NOWAIT to be a >>>> sort of back door for grabbing memory. >>>> Your analysis is right, there is nothing to add or correct. >>>> This is the reason to strongly prefer M_WAITOK. >>>> >>> Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was >>> well understand that it should only be used by interrupt handlers. >>> >>> The trouble is that M_NOWAIT conflates two orthogonal things. The obvious >>> being that the allocation shouldn't sleep. The other being how far we're >>> willing to deplete the cache/free page queues. >>> >>> When fine-grained locking got sprinkled throughout the kernel, we all to >>> often found ourselves wanting to do allocations without the possibility of >>> blocking. So, M_NOWAIT became commonplace, where it wasn't before. >>> >>> This had the unintended consequence of introducing a lot of memory >>> allocations in the top-half of the kernel, i.e., non-interrupt handling >>> code, that were digging deep into the cache/free page queues. >>> >>> Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" >>> allocation is less likely to succeed than an "M_NOWAIT" allocation. >>> However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it >>> could only allocate a free page. M_USE_RESERVE said that it ok to allocate >>> a cached page even though M_NOWAIT was specified. Consequently, the system >>> wouldn't dig as far into the free page queue if M_USE_RESERVE was >>> specified, because it was allowed to reclaim a cached page. >>> >>> In conclusion, I think it's time that we change M_NOWAIT so that it doesn't >>> dig any deeper into the cache/free page queues than M_WAITOK does and >>> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >>> cache/free page queues. The trouble is that we then need to identify all >>> of those places that are implicitly depending on the current behavior of >>> M_NOWAIT also digging deep into the cache/free page queues so that we can >>> add an explicit M_USE_RESERVE. >>> >>> Alan >>> >>> P.S. I suspect that we should also increase the size of the "page reserve" >>> that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How >>> many legitimate users of a new M_USE_RESERVE-like flag in today's kernel >>> could actually be satisfied by two pages? >> I am almost sure that most of people who put the M_NOWAIT flag, do not >> know the 'allow the deeper drain of free queue' effect. As such, I believe >> we should flip the meaning of M_NOWAIT/M_USE_RESERVE. My only expectations >> of the problematic places would be in the swapout path. >> >> I found a single explicit use of M_USE_RESERVE in the kernel, >> so the flip is relatively simple. > Agreed. Most recently I eliminated several uses from the arm pmap > implementations. There is, however, one other use: > > ofed/include/linux/gfp.h:#define GFP_ATOMIC (M_NOWAIT | > M_USE_RESERVE) > >> Below is the patch which I only compile-tested on amd64, and which booted >> fine. >> >> Peter, could you, please, give it a run, to see obvious deadlocks, if any ? >> >> diff --git a/sys/amd64/amd64/uma_machdep.c b/sys/amd64/amd64/uma_machdep.c >> index dc9c307..ab1e869 100644 >> --- a/sys/amd64/amd64/uma_machdep.c >> +++ b/sys/amd64/amd64/uma_machdep.c >> @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); >> >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> int pflags; >> >> *flags = UMA_SLAB_PRIV; >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >> - else >> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >> - if (wait & M_ZERO) >> - pflags |= VM_ALLOC_ZERO; >> + pflags = m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); >> for (;;) { >> m = vm_page_alloc(NULL, 0, pflags); >> if (m == NULL) { >> diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c >> index f60cdb1..75366e3 100644 >> --- a/sys/arm/arm/vm_machdep.c >> +++ b/sys/arm/arm/vm_machdep.c >> @@ -651,12 +651,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> ret = ((void *)kmem_malloc(kmem_map, bytes, M_NOWAIT)); >> return (ret); >> } >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >> - else >> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >> - if (wait & M_ZERO) >> - pflags |= VM_ALLOC_ZERO; >> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >> for (;;) { >> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >> if (m == NULL) { >> diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c >> index 71caa29..2ce1ca6 100644 >> --- a/sys/fs/devfs/devfs_devs.c >> +++ b/sys/fs/devfs/devfs_devs.c >> @@ -121,7 +121,7 @@ devfs_alloc(int flags) >> struct cdev *cdev; >> struct timespec ts; >> >> - cdp = malloc(sizeof *cdp, M_CDEVP, M_USE_RESERVE | M_ZERO | >> + cdp = malloc(sizeof *cdp, M_CDEVP, M_ZERO | >> ((flags & MAKEDEV_NOWAIT) ? M_NOWAIT : M_WAITOK)); >> if (cdp == NULL) >> return (NULL); >> diff --git a/sys/ia64/ia64/uma_machdep.c b/sys/ia64/ia64/uma_machdep.c >> index 37353ff..9f77762 100644 >> --- a/sys/ia64/ia64/uma_machdep.c >> +++ b/sys/ia64/ia64/uma_machdep.c >> @@ -46,12 +46,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> int pflags; >> >> *flags = UMA_SLAB_PRIV; >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >> - else >> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >> - if (wait & M_ZERO) >> - pflags |= VM_ALLOC_ZERO; >> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >> >> for (;;) { >> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >> diff --git a/sys/mips/mips/uma_machdep.c b/sys/mips/mips/uma_machdep.c >> index 798e632..24baef0 100644 >> --- a/sys/mips/mips/uma_machdep.c >> +++ b/sys/mips/mips/uma_machdep.c >> @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> void *va; >> >> *flags = UMA_SLAB_PRIV; >> - >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT; >> - else >> - pflags = VM_ALLOC_SYSTEM; >> + pflags = m2vm_flags(wait, 0); >> >> for (;;) { >> m = pmap_alloc_direct_page(0, pflags); > > This smells fishy, but not because of anything that you did. It appears > that the mips uma_small_alloc() is unconditionally asking for a > pre-zeroed page. I'll take a look at this later today. > I verified this. The current implementation of uma_small_alloc() on MIPS unconditionally zeroes the page. Moreover, if M_ZERO is specified to uma_small_alloc(), the same page is zeroed twice, once in pmap_alloc_direct_page() and again in uma_small_alloc(). I expect to commit the following patch tomorrow. Kostik, it will trivially conflict with your current patch. Index: mips/include/pmap.h =================================================================== --- mips/include/pmap.h (revision 242939) +++ mips/include/pmap.h (working copy) @@ -179,7 +179,6 @@ void pmap_kenter_temporary_free(vm_paddr_t pa); void pmap_flush_pvcache(vm_page_t m); int pmap_emulate_modified(pmap_t pmap, vm_offset_t va); void pmap_grow_direct_page_cache(void); -vm_page_t pmap_alloc_direct_page(unsigned int index, int req); #endif /* _KERNEL */ Index: mips/mips/pmap.c =================================================================== --- mips/mips/pmap.c (revision 242939) +++ mips/mips/pmap.c (working copy) @@ -163,6 +163,7 @@ static vm_page_t pmap_pv_reclaim(pmap_t locked_pma static void pmap_pvh_free(struct md_page *pvh, pmap_t pmap, vm_offset_t va); static pv_entry_t pmap_pvh_remove(struct md_page *pvh, pmap_t pmap, vm_offset_t va); +static vm_page_t pmap_alloc_direct_page(unsigned int index, int req); static vm_page_t pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va, vm_page_t m, vm_prot_t prot, vm_page_t mpte); static int pmap_remove_pte(struct pmap *pmap, pt_entry_t *ptq, vm_offset_t va, @@ -1041,7 +1042,7 @@ pmap_grow_direct_page_cache() #endif } -vm_page_t +static vm_page_t pmap_alloc_direct_page(unsigned int index, int req) { vm_page_t m; Index: mips/mips/uma_machdep.c =================================================================== --- mips/mips/uma_machdep.c (revision 242939) +++ mips/mips/uma_machdep.c (working copy) @@ -50,12 +50,14 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8 *flags = UMA_SLAB_PRIV; if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) - pflags = VM_ALLOC_INTERRUPT; + pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; else - pflags = VM_ALLOC_SYSTEM; + pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; + if (wait & M_ZERO) + pflags |= VM_ALLOC_ZERO; for (;;) { - m = pmap_alloc_direct_page(0, pflags); + m = vm_page_alloc_freelist(VM_FREELIST_DIRECT, pflags); if (m == NULL) { if (wait & M_NOWAIT) return (NULL); From owner-freebsd-mips@FreeBSD.ORG Tue Nov 13 20:13:34 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94E9BCC8; Tue, 13 Nov 2012 20:13:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEBB8FC0C; Tue, 13 Nov 2012 20:13:33 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so630637pbc.13 for ; Tue, 13 Nov 2012 12:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wq/D18NoN540dXG/FHe9zJ/s/tZTkAqFfgiIMuVlh5A=; b=vpwlU6W0rjw/fBtbwY7q+1vuKPf9zu1DPnC0qkvmnax1ZQpNwSVtuj8aIl5570vXlK SbaH8hUCnzzTHvCoZzZi2lah7LHreBVbyToFeqLXg7yCV0K/JICS1r8/BaqXcRguj+tM Zh3lYRKzn8k/UqdJ90yj425QxzZ04QboJj/ctYuPU2h4pXBXEYf+2t3WH8nGdv21bXZk g/48MaujUfVs6qGnHC+yyEr+J+vTCWYa6cL00aZd5BHQZNP+izltzIfKSbMiKyUo8sQH /c8PjSptFMgCenKGC44+ictnG07KGMgogNEhiLQ4uCwSiaW69TpRvyzgAynywmGvZgtT PPhw== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr69602826pbc.105.1352837613714; Tue, 13 Nov 2012 12:13:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Tue, 13 Nov 2012 12:13:33 -0800 (PST) In-Reply-To: <50A2A7B2.2020302@rice.edu> References: <20121110132019.GP73505@kib.kiev.ua> <20121112133638.GZ73505@kib.kiev.ua> <50A1336E.5040401@rice.edu> <50A2A7B2.2020302@rice.edu> Date: Tue, 13 Nov 2012 12:13:33 -0800 X-Google-Sender-Auth: pZCrI_8vcUeb_JQ2fymMp9GLB-Y Message-ID: Subject: Re: Memory reserves or lack thereof From: Adrian Chadd To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Cc: mips@freebsd.org, "Sears, Steven" , alc@freebsd.org, "freebsd-hackers@freebsd.org" , pho@freebsd.org, Konstantin Belousov X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:13:34 -0000 Hey, great catch! adrian On 13 November 2012 12:04, Alan Cox wrote: > On 11/12/2012 11:35, Alan Cox wrote: >> On 11/12/2012 07:36, Konstantin Belousov wrote: >>> On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote: >>>> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: >>>> >>>>> On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: >>>>>> I have a memory subsystem design question that I'm hoping someone can >>>>> answer. >>>>>> I've been looking at a machine that is completely out of memory, as in >>>>>> >>>>>> v_free_count = 0, >>>>>> v_cache_count = 0, >>>>>> >>>>>> I wondered how a machine could completely run out of memory like this, >>>>> especially after finding a lack of interrupt storms or other pathologies >>>>> that would tend to overcommit memory. So I started investigating. >>>>>> Most allocators come down to vm_page_alloc(), which has this guard: >>>>>> >>>>>> if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) { >>>>>> page_req = VM_ALLOC_SYSTEM; >>>>>> }; >>>>>> >>>>>> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || >>>>>> (page_req == VM_ALLOC_SYSTEM && >>>>>> cnt.v_free_count + cnt.v_cache_count > >>>>> cnt.v_interrupt_free_min) || >>>>>> (page_req == VM_ALLOC_INTERRUPT && >>>>>> cnt.v_free_count + cnt.v_cache_count > 0)) { >>>>>> >>>>>> The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate >>>>> every last page. >>>>>> >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare, >>>>> perhaps only used from interrupt threads. Not so, see kmem_malloc() or >>>>> uma_small_alloc() which both contain this mapping: >>>>>> if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>>>>> pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>>>>> else >>>>>> pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>>>>> >>>>>> Note that M_USE_RESERVE has been deprecated and is used in just a >>>>> handful of places. Also note that lots of code paths come through these >>>>> routines. >>>>>> What this means is essentially _any_ allocation using M_NOWAIT will >>>>> bypass whatever reserves have been held back and will take every last page >>>>> available. >>>>>> There is no documentation stating M_NOWAIT has this side effect of >>>>> essentially being privileged, so any innocuous piece of code that can't >>>>> block will use it. And of course M_NOWAIT is literally used all over. >>>>>> It looks to me like the design goal of the BSD allocators is on >>>>> recovery; it will give all pages away knowing it can recover. >>>>>> Am I missing anything? I would have expected some small number of pages >>>>> to be held in reserve just in case. And I didn't expect M_NOWAIT to be a >>>>> sort of back door for grabbing memory. >>>>> Your analysis is right, there is nothing to add or correct. >>>>> This is the reason to strongly prefer M_WAITOK. >>>>> >>>> Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was >>>> well understand that it should only be used by interrupt handlers. >>>> >>>> The trouble is that M_NOWAIT conflates two orthogonal things. The obvious >>>> being that the allocation shouldn't sleep. The other being how far we're >>>> willing to deplete the cache/free page queues. >>>> >>>> When fine-grained locking got sprinkled throughout the kernel, we all to >>>> often found ourselves wanting to do allocations without the possibility of >>>> blocking. So, M_NOWAIT became commonplace, where it wasn't before. >>>> >>>> This had the unintended consequence of introducing a lot of memory >>>> allocations in the top-half of the kernel, i.e., non-interrupt handling >>>> code, that were digging deep into the cache/free page queues. >>>> >>>> Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" >>>> allocation is less likely to succeed than an "M_NOWAIT" allocation. >>>> However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it >>>> could only allocate a free page. M_USE_RESERVE said that it ok to allocate >>>> a cached page even though M_NOWAIT was specified. Consequently, the system >>>> wouldn't dig as far into the free page queue if M_USE_RESERVE was >>>> specified, because it was allowed to reclaim a cached page. >>>> >>>> In conclusion, I think it's time that we change M_NOWAIT so that it doesn't >>>> dig any deeper into the cache/free page queues than M_WAITOK does and >>>> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >>>> cache/free page queues. The trouble is that we then need to identify all >>>> of those places that are implicitly depending on the current behavior of >>>> M_NOWAIT also digging deep into the cache/free page queues so that we can >>>> add an explicit M_USE_RESERVE. >>>> >>>> Alan >>>> >>>> P.S. I suspect that we should also increase the size of the "page reserve" >>>> that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How >>>> many legitimate users of a new M_USE_RESERVE-like flag in today's kernel >>>> could actually be satisfied by two pages? >>> I am almost sure that most of people who put the M_NOWAIT flag, do not >>> know the 'allow the deeper drain of free queue' effect. As such, I believe >>> we should flip the meaning of M_NOWAIT/M_USE_RESERVE. My only expectations >>> of the problematic places would be in the swapout path. >>> >>> I found a single explicit use of M_USE_RESERVE in the kernel, >>> so the flip is relatively simple. >> Agreed. Most recently I eliminated several uses from the arm pmap >> implementations. There is, however, one other use: >> >> ofed/include/linux/gfp.h:#define GFP_ATOMIC (M_NOWAIT | >> M_USE_RESERVE) >> >>> Below is the patch which I only compile-tested on amd64, and which booted >>> fine. >>> >>> Peter, could you, please, give it a run, to see obvious deadlocks, if any ? >>> >>> diff --git a/sys/amd64/amd64/uma_machdep.c b/sys/amd64/amd64/uma_machdep.c >>> index dc9c307..ab1e869 100644 >>> --- a/sys/amd64/amd64/uma_machdep.c >>> +++ b/sys/amd64/amd64/uma_machdep.c >>> @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); >>> >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> int pflags; >>> >>> *flags = UMA_SLAB_PRIV; >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >>> - else >>> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >>> - if (wait & M_ZERO) >>> - pflags |= VM_ALLOC_ZERO; >>> + pflags = m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); >>> for (;;) { >>> m = vm_page_alloc(NULL, 0, pflags); >>> if (m == NULL) { >>> diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c >>> index f60cdb1..75366e3 100644 >>> --- a/sys/arm/arm/vm_machdep.c >>> +++ b/sys/arm/arm/vm_machdep.c >>> @@ -651,12 +651,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> ret = ((void *)kmem_malloc(kmem_map, bytes, M_NOWAIT)); >>> return (ret); >>> } >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>> - else >>> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>> - if (wait & M_ZERO) >>> - pflags |= VM_ALLOC_ZERO; >>> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >>> for (;;) { >>> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >>> if (m == NULL) { >>> diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c >>> index 71caa29..2ce1ca6 100644 >>> --- a/sys/fs/devfs/devfs_devs.c >>> +++ b/sys/fs/devfs/devfs_devs.c >>> @@ -121,7 +121,7 @@ devfs_alloc(int flags) >>> struct cdev *cdev; >>> struct timespec ts; >>> >>> - cdp = malloc(sizeof *cdp, M_CDEVP, M_USE_RESERVE | M_ZERO | >>> + cdp = malloc(sizeof *cdp, M_CDEVP, M_ZERO | >>> ((flags & MAKEDEV_NOWAIT) ? M_NOWAIT : M_WAITOK)); >>> if (cdp == NULL) >>> return (NULL); >>> diff --git a/sys/ia64/ia64/uma_machdep.c b/sys/ia64/ia64/uma_machdep.c >>> index 37353ff..9f77762 100644 >>> --- a/sys/ia64/ia64/uma_machdep.c >>> +++ b/sys/ia64/ia64/uma_machdep.c >>> @@ -46,12 +46,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> int pflags; >>> >>> *flags = UMA_SLAB_PRIV; >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>> - else >>> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>> - if (wait & M_ZERO) >>> - pflags |= VM_ALLOC_ZERO; >>> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >>> >>> for (;;) { >>> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >>> diff --git a/sys/mips/mips/uma_machdep.c b/sys/mips/mips/uma_machdep.c >>> index 798e632..24baef0 100644 >>> --- a/sys/mips/mips/uma_machdep.c >>> +++ b/sys/mips/mips/uma_machdep.c >>> @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> void *va; >>> >>> *flags = UMA_SLAB_PRIV; >>> - >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT; >>> - else >>> - pflags = VM_ALLOC_SYSTEM; >>> + pflags = m2vm_flags(wait, 0); >>> >>> for (;;) { >>> m = pmap_alloc_direct_page(0, pflags); >> >> This smells fishy, but not because of anything that you did. It appears >> that the mips uma_small_alloc() is unconditionally asking for a >> pre-zeroed page. I'll take a look at this later today. >> > > I verified this. The current implementation of uma_small_alloc() on > MIPS unconditionally zeroes the page. Moreover, if M_ZERO is specified > to uma_small_alloc(), the same page is zeroed twice, once in > pmap_alloc_direct_page() and again in uma_small_alloc(). > > I expect to commit the following patch tomorrow. Kostik, it will > trivially conflict with your current patch. > > Index: mips/include/pmap.h > =================================================================== > --- mips/include/pmap.h (revision 242939) > +++ mips/include/pmap.h (working copy) > @@ -179,7 +179,6 @@ void pmap_kenter_temporary_free(vm_paddr_t pa); > void pmap_flush_pvcache(vm_page_t m); > int pmap_emulate_modified(pmap_t pmap, vm_offset_t va); > void pmap_grow_direct_page_cache(void); > -vm_page_t pmap_alloc_direct_page(unsigned int index, int req); > > #endif /* _KERNEL */ > > Index: mips/mips/pmap.c > =================================================================== > --- mips/mips/pmap.c (revision 242939) > +++ mips/mips/pmap.c (working copy) > @@ -163,6 +163,7 @@ static vm_page_t pmap_pv_reclaim(pmap_t locked_pma > static void pmap_pvh_free(struct md_page *pvh, pmap_t pmap, vm_offset_t > va); > static pv_entry_t pmap_pvh_remove(struct md_page *pvh, pmap_t pmap, > vm_offset_t va); > +static vm_page_t pmap_alloc_direct_page(unsigned int index, int req); > static vm_page_t pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va, > vm_page_t m, vm_prot_t prot, vm_page_t mpte); > static int pmap_remove_pte(struct pmap *pmap, pt_entry_t *ptq, > vm_offset_t va, > @@ -1041,7 +1042,7 @@ pmap_grow_direct_page_cache() > #endif > } > > -vm_page_t > +static vm_page_t > pmap_alloc_direct_page(unsigned int index, int req) > { > vm_page_t m; > Index: mips/mips/uma_machdep.c > =================================================================== > --- mips/mips/uma_machdep.c (revision 242939) > +++ mips/mips/uma_machdep.c (working copy) > @@ -50,12 +50,14 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8 > *flags = UMA_SLAB_PRIV; > > if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT; > + pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > else > - pflags = VM_ALLOC_SYSTEM; > + pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > + if (wait & M_ZERO) > + pflags |= VM_ALLOC_ZERO; > > for (;;) { > - m = pmap_alloc_direct_page(0, pflags); > + m = vm_page_alloc_freelist(VM_FREELIST_DIRECT, pflags); > if (m == NULL) { > if (wait & M_NOWAIT) > return (NULL); > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 09:01:54 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E05F236D for ; Thu, 15 Nov 2012 09:01:53 +0000 (UTC) (envelope-from mukunda@pointred.co) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by mx1.freebsd.org (Postfix) with SMTP id 682A78FC08 for ; Thu, 15 Nov 2012 09:01:50 +0000 (UTC) Received: from mail-yh0-f70.google.com ([209.85.213.70]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUKSvfXg1dB/HWmGFs7Fv920naCAfJuhq@postini.com; Thu, 15 Nov 2012 01:01:53 PST Received: by mail-yh0-f70.google.com with SMTP id o21so2700609yho.5 for ; Thu, 15 Nov 2012 01:01:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=DJ3Zog7ZCkkTtfyN6bAfRZUl/4ilx38DzL9Kn09GMVI=; b=lqmaacfVnST523CU9SwfNwR8TgN8KRvEyCmrAiCjsA7XUi3o4letVI2R12kr8N7DF2 df7lz08qUv6Y7JoYxrRY1i4tNfbGbjTvqlMasF4LOmCkfJzfcWRatEzYfwpNRAwrSJ2l HlLGavzAqLsHPkOjJmpfb2AinGFmz5g2CTCbgOQOsPA+ck7MYEAFRafgHUHdApmejmtw 6nDXq2UeCcZC54+npqG97O/NTd6Yu2bvjbUVXoG9m1BZU0DY3YoFoysC+oH8jHwl3Kl1 82FDIf6aoSo5bmmG1KJFxsoLTzt0BRzGQUJJe28C/gu3suHUndeN/gZjx8UPOYrZs3pn VGoQ== Received: by 10.52.67.101 with SMTP id m5mr321581vdt.97.1352968731097; Thu, 15 Nov 2012 00:38:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.67.101 with SMTP id m5mr321573vdt.97.1352968730964; Thu, 15 Nov 2012 00:38:50 -0800 (PST) Received: by 10.58.203.37 with HTTP; Thu, 15 Nov 2012 00:38:50 -0800 (PST) Date: Thu, 15 Nov 2012 14:08:50 +0530 Message-ID: Subject: Trying FreeBSD on AR71XX From: Mukunda Haveri To: freebsd-mips@freebsd.org X-Gm-Message-State: ALoCoQledeOm7iBUXriE4buN29cY31ZOA9Dl+3KVj240Y1wP616/YlHpk9wCtYFq2Dxv+sZbUx+kl4NI3IdNfHpeTM+WeC7W2SciAL4Bn9p74GSvbIPjrQfI6RXPjMuaDjjvrrSXf1YZ5twFK5zARxo/+p8JLpa5esZJRgWlNSSa+/Lc71q7ucE= Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 09:01:54 -0000 Hi, I am currently trying out starting the freebsd kernel on AR7130 board. Midway through the booting process, I get an error "ELF Error : -13". Anyone has an idea what is going on ? Additionally, when I try to boot the same image using a redboot loader, I get the following message, "Only absolute ELF images supported" I am stuck and would appreciate help. Thanks, HSM DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 09:30:21 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48AB7A28 for ; Thu, 15 Nov 2012 09:30:21 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id E06618FC15 for ; Thu, 15 Nov 2012 09:30:20 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TYvly-0003py-Uv; Thu, 15 Nov 2012 01:30:13 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Trying FreeBSD on AR71XX From: Oleksandr Tymoshenko In-Reply-To: Date: Thu, 15 Nov 2012 01:29:52 -0800 Content-Transfer-Encoding: 7bit Message-Id: <6EE692C3-199D-4310-8C7D-45995EB8BE6A@bluezbox.com> References: To: Mukunda Haveri X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-11-15, at 12:38 AM, Mukunda Haveri wrote: > Hi, > I am currently trying out starting the freebsd kernel on AR7130 board. > Midway through the booting process, I get an error "ELF Error : -13". > Anyone has an idea what is going on ? > > Additionally, when I try to boot the same image using a redboot loader, I > get the following message, > "Only absolute ELF images supported" > I am stuck and would appreciate help. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 09:30:21 -0000 On 2012-11-15, at 12:38 AM, Mukunda Haveri wrote: > Hi, > I am currently trying out starting the freebsd kernel on AR7130 board. > Midway through the booting process, I get an error "ELF Error : -13". > Anyone has an idea what is going on ? > > Additionally, when I try to boot the same image using a redboot loader, I > get the following message, > "Only absolute ELF images supported" > I am stuck and would appreciate help. AFAIR this one was due to wrong byte order of kernel ELF image. Try setting TARGET_ARCH to mipsel if it's not set or set to mips. From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 18:25:28 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B179DBF0; Thu, 15 Nov 2012 18:25:28 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by mx1.freebsd.org (Postfix) with ESMTP id 82D2C8FC19; Thu, 15 Nov 2012 18:25:28 +0000 (UTC) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id 74A83401E6; Thu, 15 Nov 2012 12:25:22 -0600 (CST) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id 73A9E401CB; Thu, 15 Nov 2012 12:25:22 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from mh3.mail.rice.edu ([127.0.0.1]) by mh3.mail.rice.edu (mh3.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id czahMvILN02y; Thu, 15 Nov 2012 12:25:22 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id E37F84018B; Thu, 15 Nov 2012 12:25:21 -0600 (CST) Message-ID: <50A53391.4080909@rice.edu> Date: Thu, 15 Nov 2012 12:25:21 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: mips@freebsd.org Subject: ZERO_REGION_SIZE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:25:28 -0000 Given the possibility of L1 cache aliasing on some (many?) MIPS processors, I think that you, i.e., MIPS users, should evaluate the performance effects of the following change: Index: mips/include/vmparam.h =================================================================== --- mips/include/vmparam.h (revision 243091) +++ mips/include/vmparam.h (working copy) @@ -190,6 +190,6 @@ */ #define VM_NFREEORDER 9 -#define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ +#define ZERO_REGION_SIZE 4096 #endif /* !_MACHINE_VMPARAM_H_ */ You can quantify the impact with a simple test like: dd if=/dev/zero of=/dev/null bs=<64 or 128>k count= If possible, please use a kernel without WITNESS or INVARIANTS. Alan P.S. I would also be curious how setting this to 8192 would perform. From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 19:09:50 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 367D3E3F; Thu, 15 Nov 2012 19:09:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01F388FC17; Thu, 15 Nov 2012 19:09:49 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1389624pab.13 for ; Thu, 15 Nov 2012 11:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1gLgA+zkCzMpT93RYQUgTgtjSjcjSNGBm8ZKNgVD4cg=; b=cYrWE0yS5BpbFeLVK+8EO7pE10UMfyBExFedxgPRSk/qyYGyjWpIQ/da36dX05tLK4 /mFzMfMpTWslo9WH75jashj4TucEpXWuIYuwRF6rknx05dGDy/ch19KKuaQ0BbpKmYHH 0z595sizy0jU+75DN9kwO2iyUaWvjv4nwWaBqx3nuqZmsAuvIedlvVZ+JCRHc1wf3xw1 hKWNeTWEs4pwhuuEK8sKNcrv+tIU29mu6vjj7YYPQD/wMuZTbFTV6d3u0baX5k0QSuvz +mdzXYwl8AsKPGUE9gg+HCN98tLyBj91QB0yI+maiYd/SAx9nVIWep2Df6pYA/Ahya1F HMtw== MIME-Version: 1.0 Received: by 10.66.72.136 with SMTP id d8mr6038475pav.4.1353006588940; Thu, 15 Nov 2012 11:09:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 11:09:48 -0800 (PST) In-Reply-To: <50A53391.4080909@rice.edu> References: <50A53391.4080909@rice.edu> Date: Thu, 15 Nov 2012 11:09:48 -0800 X-Google-Sender-Auth: H1HYeqs_4Tv1D0Ix0B9xOJx1b1w Message-ID: Subject: Re: ZERO_REGION_SIZE From: Adrian Chadd To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Cc: "Jayachandran C." , mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:09:50 -0000 Alan, would you like me to send you some MIPS hardwarE? Adrian On 15 November 2012 10:25, Alan Cox wrote: > Given the possibility of L1 cache aliasing on some (many?) MIPS > processors, I think that you, i.e., MIPS users, should evaluate the > performance effects of the following change: > > Index: mips/include/vmparam.h > =================================================================== > --- mips/include/vmparam.h (revision 243091) > +++ mips/include/vmparam.h (working copy) > @@ -190,6 +190,6 @@ > */ > #define VM_NFREEORDER 9 > > -#define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ > +#define ZERO_REGION_SIZE 4096 > > #endif /* !_MACHINE_VMPARAM_H_ */ > > You can quantify the impact with a simple test like: > > dd if=/dev/zero of=/dev/null bs=<64 or 128>k count= > > If possible, please use a kernel without WITNESS or INVARIANTS. > > Alan > > P.S. I would also be curious how setting this to 8192 would perform. > From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 20:13:09 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0817656; Thu, 15 Nov 2012 20:13:09 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1298FC08; Thu, 15 Nov 2012 20:13:09 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 6765060500; Thu, 15 Nov 2012 14:13:03 -0600 (CST) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 65ED7604D2; Thu, 15 Nov 2012 14:13:03 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id PqW0EZgKtPta; Thu, 15 Nov 2012 14:13:03 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id 0D403603D8; Thu, 15 Nov 2012 14:13:02 -0600 (CST) Message-ID: <50A54CCD.8070409@rice.edu> Date: Thu, 15 Nov 2012 14:13:01 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ZERO_REGION_SIZE References: <50A53391.4080909@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." , mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:13:09 -0000 On 11/15/2012 13:09, Adrian Chadd wrote: > Alan, would you like me to send you some MIPS hardwarE? Let me think about that. Now may not be the right time, but I suspect that I'll take you up on that offer in a few months. In the meantime, I'll say that I've always got prompt responses to my requests for testing from people on this list, particularly jchandra@. So, I don't feel like progress on MIPS VM issues is being slowed much by my lack of hardware. Thanks, Alan P.S. I would encourage someone with hardware to look into implementing a non-iterative ffs*() using (d)clz. The MIPS pmap would benefit from this. Basically, most pmap_enter() calls are doing an ffs*(). From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 21:07:35 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E357AE9 for ; Thu, 15 Nov 2012 21:07:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 010008FC12 for ; Thu, 15 Nov 2012 21:07:34 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so2680599obc.13 for ; Thu, 15 Nov 2012 13:07:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2/OxbfAa8raVrEoZZtgcrcCzXjlNwQAWrKKO4aR0qnY=; b=PLBhDHHzML6XiTclB/zr7tWk+ZCIz/fgTgkL7SpjfOOoRlrJ7QWZogc7CA8vp+uf1b VCE0pEPXutTPrkLMvdmbwjScZYg0SYBZQ+3tZP3RkgocPe2x/Qq030TSX7FoXoOECqI5 Ak0hIqEhxH16r+zGyx/MKLaDHamxhoZVtVvYtZw0nh26kxo7l44jPfQRW4LbwjT0u6kl UTUaTDE+o58YF1V3a2j8IV5OrzFoO0xoqjd8NMZ8Ia22mLHKEbXBZTfUZr1p85DIGYrL Faz9/tGgN2NXB9B9QtIJGJuIbtR8UI18dfQ0M5n5ihH4g8W+PYOJ3paxd7lxM2XTViML ARzw== Received: by 10.60.22.33 with SMTP id a1mr2033021oef.97.1353013654071; Thu, 15 Nov 2012 13:07:34 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id l9sm13262195oec.5.2012.11.15.13.07.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 13:07:31 -0800 (PST) Sender: Warner Losh Subject: Re: ZERO_REGION_SIZE Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50A54CCD.8070409@rice.edu> Date: Thu, 15 Nov 2012 14:07:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50A53391.4080909@rice.edu> <50A54CCD.8070409@rice.edu> To: Alan Cox X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl7U0Sw0xoT9zVVzzJrs7WRACS7Kwj3mAa6WqnquAREnzlA9JaUrsm1wxtIiS0u8mUb/smK Cc: "Jayachandran C." , mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:07:35 -0000 On Nov 15, 2012, at 1:13 PM, Alan Cox wrote: > P.S. I would encourage someone with hardware to look into implementing = a > non-iterative ffs*() using (d)clz. The MIPS pmap would benefit from > this. Basically, most pmap_enter() calls are doing an ffs*(). ffs finds the first bit set. clz counts the number of leading zeros and = thus finds the last bit set. Would a non-iterative fls* be helpful? Warner From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 22:03:03 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4485C92 for ; Thu, 15 Nov 2012 22:03:03 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 719D98FC16 for ; Thu, 15 Nov 2012 22:03:03 +0000 (UTC) Received: by mail-gg0-f182.google.com with SMTP id l1so444573ggn.13 for ; Thu, 15 Nov 2012 14:02:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=d+pBdq9xAiFnWchRiDMBy3cDtQ4FJW7JnwMfoEWNdpQ=; b=MnaA1qSu5KAHJaiN759ip2ozQk7d4QVhF7Pe7XkfwrxoPuPKaHnZc0imIyM1H7nfZK 01ny0rk8R2Dyi1lVAn46s9onEkWPRqBR3d4fnfTVzbuZ+ZOgICCdMmF1VNdyznd1S9sp nYKl7whgR6OaolWvQtqZgER709wNdIeGY3yW+UbV5x4yCQMfMmKq390wC/bte3SVjbua 0Oo39Z2zmOCsv61qT5VuhH/q7yo1oDLJR6WuJ2AheDEwO5j3bTQfAQ4M1ngkUXoNxDDm Gx494XD4Ho8EQ0m9mc76d5MpQLsIrC5pLw2p1DNYhQtw1bQwREqBqL7Nzx+NbjsilG6a YOeg== Received: by 10.101.151.4 with SMTP id d4mr699885ano.21.1353016977263; Thu, 15 Nov 2012 14:02:57 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.147.83.18 with HTTP; Thu, 15 Nov 2012 14:02:37 -0800 (PST) In-Reply-To: References: <50A53391.4080909@rice.edu> <50A54CCD.8070409@rice.edu> From: Juli Mallett Date: Thu, 15 Nov 2012 14:02:37 -0800 X-Google-Sender-Auth: oeigH5X0M1fL_NpcJlfOKncudTU Message-ID: Subject: Re: ZERO_REGION_SIZE To: Warner Losh X-Gm-Message-State: ALoCoQnxKeAtNMvA6edFhIZUef2giaLgZW2ckJ2UFpn+KkerHJbdSObwZj/wlvUCCPHpBDacYL4e Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Jayachandran C." , "freebsd-mips@FreeBSD.org" , Alan Cox X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:03:04 -0000 On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh wrote: > > On Nov 15, 2012, at 1:13 PM, Alan Cox wrote: > > P.S. I would encourage someone with hardware to look into implementing a > > non-iterative ffs*() using (d)clz. The MIPS pmap would benefit from > > this. Basically, most pmap_enter() calls are doing an ffs*(). > > ffs finds the first bit set. clz counts the number of leading zeros and > thus finds the last bit set. Would a non-iterative fls* be helpful? > Right. And no widespread ctz/ffs MIPS instructions as far as I know. We could use pop/dpop on processors that support them to do non-iterative ffs*, with a few additional instructions, though. From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 22:11:07 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 829302DB; Thu, 15 Nov 2012 22:11:07 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 790EB8FC08; Thu, 15 Nov 2012 22:11:06 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so2810376vba.13 for ; Thu, 15 Nov 2012 14:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iF7sP3X/OHLY1NAqRiToWicVAZPsZ1oks5jIAt5G9Nk=; b=MsLRIyTlnrcHet+YjpEsTiAYi6o57b0y80F2FgAAliv+7ZaT3X4QzA2YuaAmOZSLqb twAkj4P50+H0kf+C/E6MuZ+4kWbR26EWp+TL5EuxoVMNLj7mRfIkZ9KsKYLo9CHKBjgd 4nC87MbILmKsF5DFp2GBzTFWspqIvXuM6d73RfBQwuL1xjVy23h+4LPOeNYRwcDG2CJ9 CGteMkEIK25bNOiPdsLgESAsw5lToj1wbM2KYsCaA3LGD9ftFC95hujM+6hxGN+XCzl9 qYpm8FTrVVbVWL8HjWq2BdRCoHD0qIEZHYb0DS9F1wP3CZsQPOsavJsWA3sxpuB1EP7K VsGQ== MIME-Version: 1.0 Received: by 10.220.40.16 with SMTP id i16mr3503033vce.31.1353017465472; Thu, 15 Nov 2012 14:11:05 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.59.5.38 with HTTP; Thu, 15 Nov 2012 14:11:05 -0800 (PST) In-Reply-To: References: <50A53391.4080909@rice.edu> <50A54CCD.8070409@rice.edu> Date: Thu, 15 Nov 2012 17:11:05 -0500 X-Google-Sender-Auth: bRZ3vreJ3TGJlJxGnZB9kgEWcyM Message-ID: Subject: Re: ZERO_REGION_SIZE From: Patrick Kelsey To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Cc: "Jayachandran C." , "freebsd-mips@FreeBSD.org" , Alan Cox X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:11:07 -0000 On Thu, Nov 15, 2012 at 5:02 PM, Juli Mallett wrote: > On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh wrote: > >> >> On Nov 15, 2012, at 1:13 PM, Alan Cox wrote: >> > P.S. I would encourage someone with hardware to look into implementing a >> > non-iterative ffs*() using (d)clz. The MIPS pmap would benefit from >> > this. Basically, most pmap_enter() calls are doing an ffs*(). >> >> ffs finds the first bit set. clz counts the number of leading zeros and >> thus finds the last bit set. Would a non-iterative fls* be helpful? >> > > Right. And no widespread ctz/ffs MIPS instructions as far as I know. We > could use pop/dpop on processors that support them to do non-iterative > ffs*, with a few additional instructions, though. I was thinking something like this might work: value to ffs is in r1, MSB is the index of the MSB (so, 31 or 63): if (0 == r1) return(your_choice); r2 = r1 - 1; r2 = r1 ^ r2; return (MSB - clz(r2)); -Patrick From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 22:25:06 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15DB73EE for ; Thu, 15 Nov 2012 22:25:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id BB6FD8FC12 for ; Thu, 15 Nov 2012 22:25:05 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2782711oag.13 for ; Thu, 15 Nov 2012 14:25:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=0Ogq9S+QQCrdCi6ElEAYSAELFjVjyubSx3N9YOZoq/I=; b=e6kuUEtYKCHDqU5VeBIX+1cR9yt89ZM3c0L0RhvF2MQyLDFqtG3pr1QLdiloQLeodQ cChn7Mi23MXGOFQna8Uuhq8nT8kj2nE5coJg+SLQzSDNuwp97H2SP39TVUzxPBmNzfxJ xFrs8e/JGjzYytxcaRfXX7UC1deHlXskvxeDqSSq9ib0u4I2yAFC1hLK/Hvb/yyzjygz 7CNd7Zt564jXbYI4zn031qc/5i1REGE6n3+92jG4O6A15TmoGus4e+1IKGtw3V71uJu+ r82cc14AzU0/AmyfrB9IJD0+0voCXMCAmQf5OYC6y9R+3qzg/DTeNqdD9zK96MYILGt5 l9rw== Received: by 10.60.27.39 with SMTP id q7mr2197676oeg.109.1353018304750; Thu, 15 Nov 2012 14:25:04 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id yn8sm17083729obb.12.2012.11.15.14.25.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 14:25:03 -0800 (PST) Sender: Warner Losh Subject: Re: ZERO_REGION_SIZE Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 15 Nov 2012 15:25:01 -0700 Content-Transfer-Encoding: 7bit Message-Id: <953A0D95-54E1-4023-A1F5-A4A7DE1C6175@bsdimp.com> References: <50A53391.4080909@rice.edu> <50A54CCD.8070409@rice.edu> To: Patrick Kelsey X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmiPrQ1aVJS8a+zw/Yl5+pNpxS36IAszFwWA3mD8nb6kN9dY1RPs55SBMumr4UHOk1B5Q0H Cc: "Jayachandran C." , "freebsd-mips@FreeBSD.org" , Alan Cox X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:25:06 -0000 On Nov 15, 2012, at 3:11 PM, Patrick Kelsey wrote: > On Thu, Nov 15, 2012 at 5:02 PM, Juli Mallett wrote: >> On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh wrote: >> >>> >>> On Nov 15, 2012, at 1:13 PM, Alan Cox wrote: >>>> P.S. I would encourage someone with hardware to look into implementing a >>>> non-iterative ffs*() using (d)clz. The MIPS pmap would benefit from >>>> this. Basically, most pmap_enter() calls are doing an ffs*(). >>> >>> ffs finds the first bit set. clz counts the number of leading zeros and >>> thus finds the last bit set. Would a non-iterative fls* be helpful? >>> >> >> Right. And no widespread ctz/ffs MIPS instructions as far as I know. We >> could use pop/dpop on processors that support them to do non-iterative >> ffs*, with a few additional instructions, though. > > I was thinking something like this might work: > > value to ffs is in r1, MSB is the index of the MSB (so, 31 or 63): > > if (0 == r1) return(your_choice); > r2 = r1 - 1; > r2 = r1 ^ r2; > return (MSB - clz(r2)); Turns out NetBSD has one that does exactly this... Warner From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 22:41:18 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D00D7B7E; Thu, 15 Nov 2012 22:41:18 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 23DEA8FC12; Thu, 15 Nov 2012 22:41:18 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so2944229vcb.13 for ; Thu, 15 Nov 2012 14:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sAG8Yk+qBstAKKBr6Kg1gwtI0iGyUP0c5Gfti08na5M=; b=B2r7E1MKt1/yuV5bkTLk4grecZNYtsG9s5mrGcqtEHhm11v2PpkjGy3q4US++QNlAj wcsZxYneFENmnY0wdFO4jnLbdeJnOusO8joHHnOFhdF5UbDj1+K6qDhyr9UbbplkLJio Zc4jRAiHH9pqvMYztp0jXMgG8nrwH1H8LAUGN/QD38L3T0SYb6URQoWk5+bdfrcwL5B/ KxFmqYwN2Q3MmcVmIdwQpBn8SyRRSEw34bOgSURp2wJOQQfJsmxw2p7vr53Q3qtFNHfR 9pk+u96zYhb5m+JypiG+TXFTQ+Z7nYbyDNkcEMwEX5GRwgrQZs/NHPBZ27uenThX75Cg PNZw== MIME-Version: 1.0 Received: by 10.52.75.70 with SMTP id a6mr3200707vdw.5.1353019276624; Thu, 15 Nov 2012 14:41:16 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.59.5.38 with HTTP; Thu, 15 Nov 2012 14:41:16 -0800 (PST) In-Reply-To: <953A0D95-54E1-4023-A1F5-A4A7DE1C6175@bsdimp.com> References: <50A53391.4080909@rice.edu> <50A54CCD.8070409@rice.edu> <953A0D95-54E1-4023-A1F5-A4A7DE1C6175@bsdimp.com> Date: Thu, 15 Nov 2012 17:41:16 -0500 X-Google-Sender-Auth: ilJ7oCPdO7uTe1iwm8Acd8Dn-do Message-ID: Subject: Re: ZERO_REGION_SIZE From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: "Jayachandran C." , "freebsd-mips@FreeBSD.org" , Alan Cox X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:41:19 -0000 On Thu, Nov 15, 2012 at 5:25 PM, Warner Losh wrote: > > On Nov 15, 2012, at 3:11 PM, Patrick Kelsey wrote: > >> On Thu, Nov 15, 2012 at 5:02 PM, Juli Mallett wrote: >>> On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh wrote: >>> >>>> >>>> On Nov 15, 2012, at 1:13 PM, Alan Cox wrote: >>>>> P.S. I would encourage someone with hardware to look into implementing a >>>>> non-iterative ffs*() using (d)clz. The MIPS pmap would benefit from >>>>> this. Basically, most pmap_enter() calls are doing an ffs*(). >>>> >>>> ffs finds the first bit set. clz counts the number of leading zeros and >>>> thus finds the last bit set. Would a non-iterative fls* be helpful? >>>> >>> >>> Right. And no widespread ctz/ffs MIPS instructions as far as I know. We >>> could use pop/dpop on processors that support them to do non-iterative >>> ffs*, with a few additional instructions, though. >> >> I was thinking something like this might work: >> >> value to ffs is in r1, MSB is the index of the MSB (so, 31 or 63): >> >> if (0 == r1) return(your_choice); >> r2 = r1 - 1; >> r2 = r1 ^ r2; >> return (MSB - clz(r2)); > > > Turns out NetBSD has one that does exactly this... > And now that I've gotten away from silly pencil and paper and back to the glare of the internet, I see gcc has had __builtin_ffs for some time... From owner-freebsd-mips@FreeBSD.ORG Thu Nov 15 23:09:51 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1A136F8; Thu, 15 Nov 2012 23:09:51 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9CC8FC18; Thu, 15 Nov 2012 23:09:51 +0000 (UTC) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id 636D3401DC; Thu, 15 Nov 2012 17:09:50 -0600 (CST) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id 62629401D9; Thu, 15 Nov 2012 17:09:50 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from mh3.mail.rice.edu ([127.0.0.1]) by mh3.mail.rice.edu (mh3.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id mVjvNfA5WAja; Thu, 15 Nov 2012 17:09:50 -0600 (CST) Received: from [10.212.194.234] (unknown [10.212.194.234]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id 47B39401D6; Thu, 15 Nov 2012 17:09:50 -0600 (CST) Message-ID: <50A57649.9020504@rice.edu> Date: Thu, 15 Nov 2012 17:10:01 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Warner Losh Subject: Re: ZERO_REGION_SIZE References: <50A53391.4080909@rice.edu> <50A54CCD.8070409@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." , mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:09:51 -0000 On 11/15/2012 3:07 PM, Warner Losh wrote: > On Nov 15, 2012, at 1:13 PM, Alan Cox wrote: >> P.S. I would encourage someone with hardware to look into implementing a >> non-iterative ffs*() using (d)clz. The MIPS pmap would benefit from >> this. Basically, most pmap_enter() calls are doing an ffs*(). > ffs finds the first bit set. clz counts the number of leading zeros and thus finds the last bit set. Would a non-iterative fls* be helpful? The code could probably use fls* in place of ffs*. In any case, there's a standard trick for using (d)clz to implement a non-iterative ffs*. Alan From owner-freebsd-mips@FreeBSD.ORG Fri Nov 16 01:36:25 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E112BDD8 for ; Fri, 16 Nov 2012 01:36:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id B488B8FC15 for ; Fri, 16 Nov 2012 01:36:25 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so989126dad.13 for ; Thu, 15 Nov 2012 17:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=y9Hj9+KFNH1QjUxnZs0JzrUyGUnbv+pr3UC3uhTUR7U=; b=kL9MV578a07b7hy9F7zZ14YYMj5xBO86EbpluepIPv7LGtSsIqihofcb8JaYyZdiCX qX27OMQElSzlQCyZNKOc5+mpI0qGa6FqsPBEcMVqSkIOoTxAAl4J2t9npx1lWb4/y/km wDkZWe5LtQQrxYkTPQxHhiNAESyBaJQBnDDVdms0+fJQGhhuBqMrabYTgh7beMyM7/bN NFhv93WMrPDrV5qN0KcXipD4dkFyfgJXbSWkIVl/Fd3g4EpWJeAS/PKqk0olWOX/U6fV 4xo/Uli5+CzrNbrAjlu3Gdoa4Dxwq0rdIGauoKsKjyJj5wLethMMVbRMlFQ4q3NFxWPt MiAg== MIME-Version: 1.0 Received: by 10.66.72.136 with SMTP id d8mr8536630pav.4.1353029782659; Thu, 15 Nov 2012 17:36:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 17:36:22 -0800 (PST) Date: Thu, 15 Nov 2012 17:36:22 -0800 X-Google-Sender-Auth: oexk5ttmrw4byzLjkJmeqsRJbOg Message-ID: Subject: heads up - changing uart -> uart_ar71xx From: Adrian Chadd To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:36:25 -0000 Hi all, I've started digging into AR933x support and I've discovered that the UART is not an NS8250 style thing. So I'm going to shuffle the ar71xx uart code around to require both 'uart' and 'uart_ar71xx'. I'll update the config files appropriately. Thanks! Adrian From owner-freebsd-mips@FreeBSD.ORG Fri Nov 16 17:37:58 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7EBDCF6; Fri, 16 Nov 2012 17:37:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.ChatUSA.com (pdx.rh.CN85.ip6.chatusa.com [IPv6:2607:fa80:104::6]) by mx1.freebsd.org (Postfix) with ESMTP id 6CDE38FC12; Fri, 16 Nov 2012 17:37:58 +0000 (UTC) Received: from pdx.rh.CN85.ChatUSA.com (localhost [127.0.0.1]) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3) with ESMTP id qAGHZbuH070252; Fri, 16 Nov 2012 09:35:38 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.ChatUSA.com) Received: (from freebsd@localhost) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3/Submit) id qAGHZb0j070251; Fri, 16 Nov 2012 09:35:37 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com> Subject: Re: heads up - changing uart -> uart_ar71xx In-Reply-To: To: Adrian Chadd Date: Fri, 16 Nov 2012 09:35:37 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 17:37:58 -0000 This should be cleaned up better than that, what -kind- of uart is it? There should be things called uart_8250 (should be able to drive everything from 8250 to 16950) uart_8530 (this is probalby the second most common uart in the world) uart_6850 (we would probably never see one of these) etc... Please do not lock this to a specific Mips chip if at all possible > Hi all, > > I've started digging into AR933x support and I've discovered that the > UART is not an NS8250 style thing. > > So I'm going to shuffle the ar71xx uart code around to require both > 'uart' and 'uart_ar71xx'. > > I'll update the config files appropriately. > > Thanks! > > > > Adrian > _______________________________________________ > 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" > -- Rod Grimes freebsd@freebsd.org From owner-freebsd-mips@FreeBSD.ORG Fri Nov 16 18:01:08 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2EA8207 for ; Fri, 16 Nov 2012 18:01:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 86A5D8FC15 for ; Fri, 16 Nov 2012 18:01:08 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3857795oag.13 for ; Fri, 16 Nov 2012 10:01:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=HzoctM4uIITCMCv2u6zTlHb8dzNEIFzf+uVjh/negqs=; b=ngocecXwTNfK9FG/JTmx63ouBPTbFKkhyEfaSKuzjMqHPtp8yEbV2ZPacVAaVVgKQS CtEjr011QnGYDarAVehHaGnfaW4gU1AAdTHBVxhUI/vHtTh1sm3nZN0tzcbLbVtD8FeA JuW4CpoLX22/GGj8RZRlr7HBpw5MgDIkuxvjM5Zl58hGf9WAm1LXd5igkFmVH8aILx2M isyHA4u9mx94krt/7cKkoIDcjgKPCHx0rx+LShZ0liPSLVI4Q/v5MSY9pujI+ll/5iFk 5RYMNyyPxKVswErhy4z8uPW5Rr8aXbTk8Ld3FjchvUhW8bARbdp4Qwm6AdS9BqUmfU2m 4X8w== Received: by 10.60.24.7 with SMTP id q7mr4400850oef.108.1353088867627; Fri, 16 Nov 2012 10:01:07 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id fo6sm2101401obc.20.2012.11.16.10.01.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 10:01:05 -0800 (PST) Sender: Warner Losh Subject: Re: heads up - changing uart -> uart_ar71xx Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com> Date: Fri, 16 Nov 2012 11:01:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> References: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmd7G3U5LNJ/Qy38ONIwsv6R57noQMcM1+U202LE/wsTqdobeouXvtP4AeMOBa9dT1NTfBD Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:01:08 -0000 On Nov 16, 2012, at 10:35 AM, Rodney W. Grimes wrote: > This should be cleaned up better than that, what -kind- of uart is it? > There should be things called > uart_8250 (should be able to drive everything from 8250 to = 16950) > uart_8530 (this is probalby the second most common uart in the = world) > uart_6850 (we would probably never see one of these) > etc... >=20 > Please do not lock this to a specific Mips chip if at all possible uart already services a dozen of other UARTs. It isn't tied to MIPS at = all. All Adrian seems to be doing is making what was automatic = configuration a little more manual. Warner >> Hi all, >>=20 >> I've started digging into AR933x support and I've discovered that the >> UART is not an NS8250 style thing. >>=20 >> So I'm going to shuffle the ar71xx uart code around to require both >> 'uart' and 'uart_ar71xx'. >>=20 >> I'll update the config files appropriately. >>=20 >> Thanks! >>=20 >>=20 >>=20 >> Adrian >> _______________________________________________ >> 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" >>=20 >=20 > --=20 > Rod Grimes = freebsd@freebsd.org > _______________________________________________ > 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" From owner-freebsd-mips@FreeBSD.ORG Fri Nov 16 18:03:24 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9674924A for ; Fri, 16 Nov 2012 18:03:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 64F788FC12 for ; Fri, 16 Nov 2012 18:03:24 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so1332825dad.13 for ; Fri, 16 Nov 2012 10:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/q6ZeIrAOvPjldZruI7cDxBxVaQgdU/AlDN1hdIGdXU=; b=kKA0Ca/ZQtvssJr5nc6Lu+EvlV0UpucbKHony1mHc46qO1JzTpDqtVnR0sVk2GBrrS hNFRdwxjBfCmHTLjeY0kSXJ9qmEaqjVH/q6QzBZv7p/K4bZkq+QQyW9cekEsdvaeCCKW V78W6N/hzlUVc4hH6HsEN/MMsazW+FlhB+eymnL2xl2Bx3E4eCCoCKgYpbMPCbKGSwG8 jRCU/cew2OpbVYh9Esn+Lz6KKTS2+CWj/ZR+ieyqYda1mAddPPsNNZryI4PWvYTV/ylp 5XTV+uoICDF1Ug5E50xXFSgn68Dsc2VzFXiF7IbAndHvxWwyrBVCGIQcb1CcMltwTj+B kBEw== MIME-Version: 1.0 Received: by 10.68.251.197 with SMTP id zm5mr17282629pbc.30.1353088998038; Fri, 16 Nov 2012 10:03:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Fri, 16 Nov 2012 10:03:17 -0800 (PST) In-Reply-To: <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> References: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com> <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> Date: Fri, 16 Nov 2012 10:03:17 -0800 X-Google-Sender-Auth: KOP7DY8s6xxG_jYOL1L2X7W44z8 Message-ID: Subject: Re: heads up - changing uart -> uart_ar71xx From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: "Rodney W. Grimes" , freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:03:24 -0000 On 16 November 2012 10:01, Warner Losh wrote: > > On Nov 16, 2012, at 10:35 AM, Rodney W. Grimes wrote: > >> This should be cleaned up better than that, what -kind- of uart is it? >> There should be things called >> uart_8250 (should be able to drive everything from 8250 to 16950) >> uart_8530 (this is probalby the second most common uart in the world) >> uart_6850 (we would probably never see one of these) >> etc... >> >> Please do not lock this to a specific Mips chip if at all possible > > uart already services a dozen of other UARTs. It isn't tied to MIPS at all. All Adrian seems to be doing is making what was automatic configuration a little more manual. Well, strictly speaking yes. But what I'll do later is make a 'uart_core' and then allow my MIPS platforms to only register the uart(s) they need. Right now it includes all of the uarts in sys/dev/uart/. They're not separate devices. Adrian From owner-freebsd-mips@FreeBSD.ORG Fri Nov 16 18:04:11 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07A4A278 for ; Fri, 16 Nov 2012 18:04:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 788918FC0C for ; Fri, 16 Nov 2012 18:04:10 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so3830162obc.13 for ; Fri, 16 Nov 2012 10:04:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=VopoBS/3tivz5MJb5vI/R3RZSMvBQYdZ5pdcciqdORM=; b=SeIcCVQ7dig50w/UTwK/1ZKtwB0lutQyGdPy5hCYLFJAg2bt43EitJRnYa7Da5wAqQ zJKekNU9Me6hWHglGTNrTMkHJP2W2wK0i6r+OdCHhFGn5Z5Vks6Mw/Z1yHfvvWMvHnfy Tu33Y17zQWskS5Let4l2lfZ9Wx4wkoaqdsf7ujfLWyK64+G0zW0c6ic1HgJxOqBa2JWD mqbcX2UDx5J0AgQQLvzge1ssyIUeNIeVlZr9W4n8pmx6NJASKbW3OMWinxk96jIo8s5M KKQ8Fv94AoaUdi36age0/8TPloZUNpG6nQgjY251ZvbPIO4kP8TfWPResxCi7S4Gq3Vn wpXQ== Received: by 10.60.19.132 with SMTP id f4mr4466280oee.75.1353089043902; Fri, 16 Nov 2012 10:04:03 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id m8sm1660103oeb.3.2012.11.16.10.04.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 10:04:02 -0800 (PST) Sender: Warner Losh Subject: Re: heads up - changing uart -> uart_ar71xx Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 16 Nov 2012 11:03:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C61D434-FD1A-4DA2-BD5B-C7EBD6685A60@bsdimp.com> References: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com> <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmTnjTBexyC7viuscN7tDpCFfPgQLY2WcaeyRKRar9Bqr5dAbJ8DozhAxVdwY/3ggztb/Pb Cc: "Rodney W. Grimes" , freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:04:11 -0000 On Nov 16, 2012, at 11:03 AM, Adrian Chadd wrote: > On 16 November 2012 10:01, Warner Losh wrote: >>=20 >> On Nov 16, 2012, at 10:35 AM, Rodney W. Grimes wrote: >>=20 >>> This should be cleaned up better than that, what -kind- of uart is = it? >>> There should be things called >>> uart_8250 (should be able to drive everything from 8250 to = 16950) >>> uart_8530 (this is probalby the second most common uart in the = world) >>> uart_6850 (we would probably never see one of these) >>> etc... >>>=20 >>> Please do not lock this to a specific Mips chip if at all possible >>=20 >> uart already services a dozen of other UARTs. It isn't tied to MIPS = at all. All Adrian seems to be doing is making what was automatic = configuration a little more manual. >=20 > Well, strictly speaking yes. But what I'll do later is make a > 'uart_core' and then allow my MIPS platforms to only register the > uart(s) they need. >=20 > Right now it includes all of the uarts in sys/dev/uart/. They're not > separate devices. This must be a mips-specific thing, since on arm you only get what you = ask for. Warner From owner-freebsd-mips@FreeBSD.ORG Fri Nov 16 18:05:05 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1A0D2A8 for ; Fri, 16 Nov 2012 18:05:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE9488FC08 for ; Fri, 16 Nov 2012 18:05:05 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2244947pbc.13 for ; Fri, 16 Nov 2012 10:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=R57jPenRkw+GSB5Dzy/FG1KWs5Yj96nKuECxIa9Xt2E=; b=rrmirDUbCtz5uaeyrJYOw4rXRbMUlM/dAhFzXrS4pYUne0/Fm96Vqwn9qemC87zfCP mxBiTRhUpuJZkiHlOOvnGGBx3o+Odjv2zVrN+6pknrF0+Zt4dkwR6Dk7hiBBRpzSq2ze V9BDA8CJlxyyBtRVe2qzmEcqA0vy1gD+roa9OvtUbuwATzUP6vsmLqsj/c3Zz0EpnNds fCjcFtMcPPegbE6zsvfqJHdrXWAZok0aYcsmLstwofWfh+t8oQKtJOSYvi4eINbOE7UO FfXzkY9ifdVi2Dza2G5h4QA4qa1Sf4i9J0iyi6wiefQPLUuIyqlXr5pY5OqFO8tuAdzY 6fPw== MIME-Version: 1.0 Received: by 10.68.137.198 with SMTP id qk6mr17370417pbb.60.1353089104950; Fri, 16 Nov 2012 10:05:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Fri, 16 Nov 2012 10:05:04 -0800 (PST) In-Reply-To: <8C61D434-FD1A-4DA2-BD5B-C7EBD6685A60@bsdimp.com> References: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com> <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> <8C61D434-FD1A-4DA2-BD5B-C7EBD6685A60@bsdimp.com> Date: Fri, 16 Nov 2012 10:05:04 -0800 X-Google-Sender-Auth: vmXwOScOVJvP8a0R3qKOiquzZY4 Message-ID: Subject: Re: heads up - changing uart -> uart_ar71xx From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: "Rodney W. Grimes" , freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:05:05 -0000 Are you absolutely sure? The code in sys/dev/uart/ seems to pull them all in by default? Adrian From owner-freebsd-mips@FreeBSD.ORG Fri Nov 16 18:07:06 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20E8F2F8 for ; Fri, 16 Nov 2012 18:07:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id C4D568FC08 for ; Fri, 16 Nov 2012 18:07:05 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3866120oag.13 for ; Fri, 16 Nov 2012 10:07:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=pMI8BrHf7tb7VNc3CGIPkcO70sqPlOgLNZEiUMGZ5tQ=; b=M6s9dHWesGNraVBARHxy/Q5nC5S4cgG1Eq9qhvJHDfjKa7VsgTDzdd1+X9WySq9PWc 4EN6PycTsZiw/iEnWB84/A2AIEU7GnpyWPAN2S8GMJ8EMZj2aQp3wOQLlhuWd/tNs8iq VxGjOHQcFU3gx1YP2OuTt04MvsGheMK1qjNKfM+RsD1DXAPgWeqA7RPZGdU/dZau8a9n hb7fLebe3TP75/2XYvWGFmF35+hLEExvUJrOWEac1mabELXZ+9FQd2wUoNGGpLhOsyfL HN+uueDoPOlCxWErM3xB0dsRHIsVhyUTun9S4m5ip/KRPcHEZEl0L1bnYFd+imy/n6GE yhbw== Received: by 10.60.6.227 with SMTP id e3mr4617175oea.22.1353089225080; Fri, 16 Nov 2012 10:07:05 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id el2sm2131063obc.9.2012.11.16.10.07.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 10:07:03 -0800 (PST) Sender: Warner Losh Subject: Re: heads up - changing uart -> uart_ar71xx Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 16 Nov 2012 11:07:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CA7EEC5-6DDC-4738-B8F7-9BBB8A3CE68D@bsdimp.com> References: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com> <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> <8C61D434-FD1A-4DA2-BD5B-C7EBD6685A60@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkmfO8ghpFCBh7O3/loMszlHUkmavn7JAeM4i467228tKqFnoAndpBolz/LsjeAifC50mkZ Cc: "Rodney W. Grimes" , freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:07:06 -0000 On Nov 16, 2012, at 11:05 AM, Adrian Chadd wrote: > Are you absolutely sure? The code in sys/dev/uart/ seems to pull them > all in by default? I haven't checked recently, but it definitely used to be that way. It's = one reason we made uart_class_8250 a weak reference at one point. Warner From owner-freebsd-mips@FreeBSD.ORG Sat Nov 17 08:29:18 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 442DDEA8; Sat, 17 Nov 2012 08:29:18 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.ChatUSA.com (pdx.rh.CN85.ip6.chatusa.com [IPv6:2607:fa80:104::6]) by mx1.freebsd.org (Postfix) with ESMTP id 055868FC12; Sat, 17 Nov 2012 08:29:17 +0000 (UTC) Received: from pdx.rh.CN85.ChatUSA.com (localhost [127.0.0.1]) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3) with ESMTP id qAH8SQAP085131; Sat, 17 Nov 2012 00:28:26 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.ChatUSA.com) Received: (from freebsd@localhost) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3/Submit) id qAH8SP3g085130; Sat, 17 Nov 2012 00:28:25 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201211170828.qAH8SP3g085130@pdx.rh.CN85.ChatUSA.com> Subject: Re: heads up - changing uart -> uart_ar71xx In-Reply-To: <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> To: Warner Losh Date: Sat, 17 Nov 2012 00:28:25 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 08:29:18 -0000 Im having some confusion factor here .. perhaps its just caused by the wording that is being used. Why is there gona be something called ``uart_ar71xx''? As far as I know there is a uart in the ar71xx, yes, but it isnt a uart specific to the ar71xx family at all. > On Nov 16, 2012, at 10:35 AM, Rodney W. Grimes wrote: > > > This should be cleaned up better than that, what -kind- of uart is it? > > There should be things called > > uart_8250 (should be able to drive everything from 8250 to 16950) > > uart_8530 (this is probalby the second most common uart in the world) > > uart_6850 (we would probably never see one of these) > > etc... > > > > Please do not lock this to a specific Mips chip if at all possible > > uart already services a dozen of other UARTs. It isn't tied to MIPS at all. Thats what I thought. > All Adrian seems to be doing is making what was automatic configuration a > little more manual. I question the choice of labels to trigger that then.... > Warner > > >> Hi all, > >> > >> I've started digging into AR933x support and I've discovered that the > >> UART is not an NS8250 style thing. > >> > >> So I'm going to shuffle the ar71xx uart code around to require both ^^^^^^^^^^^^^^^^^ What code is specific only to the ar71xx and has anything to do with a uart? > >> 'uart' and 'uart_ar71xx'. > >> > >> I'll update the config files appropriately. > >> > >> Thanks! > >> > >> > >> > >> Adrian > >> _______________________________________________ > >> 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" > >> > > > > -- > > Rod Grimes freebsd@freebsd.org > > _______________________________________________ > > 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" > > > -- Rod Grimes freebsd@freebsd.org From owner-freebsd-mips@FreeBSD.ORG Sat Nov 17 09:18:59 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4771C2E2 for ; Sat, 17 Nov 2012 09:18:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF2DB8FC08 for ; Sat, 17 Nov 2012 09:18:58 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4481400oag.13 for ; Sat, 17 Nov 2012 01:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LTbySxBbcYlgtCItNhgCvh88tMCXn1deKN2b7fIsO3k=; b=W+JXF+5rtEwEJwU1PIy/qCcs9Y38pjVTthSVOJx20EPEJgZ5uuZR8y+5x3q+I6vy1z 2bR+AJRi5E+/1OHUyrmozU3N7Vy1EcMS6iSIDYQV/ii9g3+Za9LzUZKWdS1cT0+Ak3J+ O3QrygU7JaXOmjcjvelqNTG6tEDq5TmM4cvdJzz+8Np2jcCTpprHh3wk8D4t0KDFgwP9 K/TM9H002rJUOVhebnHQ8lq332oslZtwbNXh5wouFLlV2uP+UkIyONN+YWVGPFYfwhGY Xgdi3p6tcwHQIejIWjhvfC/6it5jn3pvKsrrwzit2YZVP4cpF3AQhVFKgOGYgrfNGPTk kxow== MIME-Version: 1.0 Received: by 10.60.14.200 with SMTP id r8mr6179022oec.45.1353143938217; Sat, 17 Nov 2012 01:18:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.76.27.65 with HTTP; Sat, 17 Nov 2012 01:18:57 -0800 (PST) In-Reply-To: <201211170828.qAH8SP3g085130@pdx.rh.CN85.ChatUSA.com> References: <6FC455B0-EBF6-4160-A491-A818003262A6@bsdimp.com> <201211170828.qAH8SP3g085130@pdx.rh.CN85.ChatUSA.com> Date: Sat, 17 Nov 2012 01:18:57 -0800 X-Google-Sender-Auth: ynxwrahIAfpJSW8aa4gzeBpv4gU Message-ID: Subject: Re: heads up - changing uart -> uart_ar71xx From: Adrian Chadd To: "Rodney W. Grimes" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 09:18:59 -0000 The glue code that sets up the ar71xx uart itself - there's some bus glue in mips/atheros/. adrian On 17 November 2012 00:28, Rodney W. Grimes wrote: > Im having some confusion factor here .. perhaps its just caused by the wording > that is being used. > > Why is there gona be something called ``uart_ar71xx''? As far as I know > there is a uart in the ar71xx, yes, but it isnt a uart specific to the ar71xx > family at all. >> On Nov 16, 2012, at 10:35 AM, Rodney W. Grimes wrote: >> >> > This should be cleaned up better than that, what -kind- of uart is it? >> > There should be things called >> > uart_8250 (should be able to drive everything from 8250 to 16950) >> > uart_8530 (this is probalby the second most common uart in the world) >> > uart_6850 (we would probably never see one of these) >> > etc... >> > >> > Please do not lock this to a specific Mips chip if at all possible >> >> uart already services a dozen of other UARTs. It isn't tied to MIPS at all. > Thats what I thought. > >> All Adrian seems to be doing is making what was automatic configuration a >> little more manual. > > I question the choice of labels to trigger that then.... > >> Warner >> >> >> Hi all, >> >> >> >> I've started digging into AR933x support and I've discovered that the >> >> UART is not an NS8250 style thing. >> >> >> >> So I'm going to shuffle the ar71xx uart code around to require both > ^^^^^^^^^^^^^^^^^ > > What code is specific only to the ar71xx and has anything to do with a uart? > >> >> 'uart' and 'uart_ar71xx'. >> >> >> >> I'll update the config files appropriately. >> >> >> >> Thanks! >> >> >> >> >> >> >> >> Adrian >> >> _______________________________________________ >> >> 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" >> >> >> > >> > -- >> > Rod Grimes freebsd@freebsd.org >> > _______________________________________________ >> > 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" >> >> >> > > -- > Rod Grimes freebsd@freebsd.org