From owner-freebsd-mips@FreeBSD.ORG  Sun Nov 11 16:32:30 2012
Return-Path: <owner-freebsd-mips@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <current@freebsd.org>,
 <mips@freebsd.org>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <stable@freebsd.org>,
 <mips@freebsd.org>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <stable@freebsd.org>,
 <mips@freebsd.org>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <current@freebsd.org>,
 <mips@freebsd.org>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@FreeBSD.org>; 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 <freebsd-mips@FreeBSD.org>; 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 <freebsd-mips@FreeBSD.org>; 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 <bugmaster@FreeBSD.org>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <alc@rice.edu>
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" <freebsd-hackers@freebsd.org>
Subject: Re: Memory reserves or lack thereof
References: <A6DE036C6A90C949A25CE89E844237FB2086970A@SACEXCMBX01-PRD.hq.netapp.com>
 <20121110132019.GP73505@kib.kiev.ua>
 <CAJUyCcOKHH3TO6qaK9V7UY2HW+p6T74DUUdmbSi4eeGyofrTdQ@mail.gmail.com>
 <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 <kostikbel@gmail.com>, alc@freebsd.org,
 mips@freebsd.org, "Sears, Steven" <Steven.Sears@netapp.com>, pho@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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 <kostikbel@gmail.com>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 <sys/param.h>
>>  #include <sys/lock.h>
>> +#include <sys/malloc.h>
>>  #include <sys/mutex.h>
>>  #include <sys/systm.h>
>>  #include <vm/vm.h>
>> @@ -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: <owner-freebsd-mips@FreeBSD.ORG>
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 <multiple recipients>; 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: <A6DE036C6A90C949A25CE89E844237FB2086970A@SACEXCMBX01-PRD.hq.netapp.com>
 <20121110132019.GP73505@kib.kiev.ua>
 <CAJUyCcOKHH3TO6qaK9V7UY2HW+p6T74DUUdmbSi4eeGyofrTdQ@mail.gmail.com>
 <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: <CAJ-VmonAAXXm90wbcVi=TLv-XEDkzAY7aNc=WWXh5KHDiCvaQQ@mail.gmail.com>
Subject: Re: Memory reserves or lack thereof
From: Adrian Chadd <adrian@freebsd.org>
To: Alan Cox <alc@rice.edu>
Content-Type: text/plain; charset=ISO-8859-1
Cc: mips@freebsd.org, "Sears, Steven" <Steven.Sears@netapp.com>,
 alc@freebsd.org, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>,
 pho@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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 <alc@rice.edu> 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 <kostikbel@gmail.com>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 <sys/param.h>
>>>  #include <sys/lock.h>
>>> +#include <sys/malloc.h>
>>>  #include <sys/mutex.h>
>>>  #include <sys/systm.h>
>>>  #include <vm/vm.h>
>>> @@ -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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; 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: <CAK3PU_AKFeyXqJzb3rS3fo-e7JGgGiyn=ezt=tAiqK-gn-1-rw@mail.gmail.com>
Subject: Trying FreeBSD on AR71XX
From: Mukunda Haveri <mukunda@pointred.co>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
 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 <gonzo@bluezbox.com>
In-Reply-To: <CAK3PU_AKFeyXqJzb3rS3fo-e7JGgGiyn=ezt=tAiqK-gn-1-rw@mail.gmail.com>
Date: Thu, 15 Nov 2012 01:29:52 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <6EE692C3-199D-4310-8C7D-45995EB8BE6A@bluezbox.com>
References: <CAK3PU_AKFeyXqJzb3rS3fo-e7JGgGiyn=ezt=tAiqK-gn-1-rw@mail.gmail.com>
To: Mukunda Haveri <mukunda@pointred.co>
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 <mukunda@pointred.co>
 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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 09:30:21 -0000


On 2012-11-15, at 12:38 AM, Mukunda Haveri <mukunda@pointred.co> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <alc@rice.edu>
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." <jchandra@freebsd.org>
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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=<something non-trivial>

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: <owner-freebsd-mips@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
Subject: Re: ZERO_REGION_SIZE
From: Adrian Chadd <adrian@freebsd.org>
To: Alan Cox <alc@rice.edu>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Jayachandran C." <jchandra@freebsd.org>, mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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 <alc@rice.edu> 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=<something non-trivial>
>
> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <alc@rice.edu>
User-Agent: Mozilla/5.0 (X11; FreeBSD i386;
 rv:16.0) Gecko/20121111 Thunderbird/16.0.2
MIME-Version: 1.0
To: Adrian Chadd <adrian@freebsd.org>
Subject: Re: ZERO_REGION_SIZE
References: <50A53391.4080909@rice.edu>
 <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
In-Reply-To: <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "Jayachandran C." <jchandra@freebsd.org>, mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <mips@freebsd.org>; 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 <mips@freebsd.org>; Thu, 15 Nov 2012 21:07:34 +0000 (UTC)
Received: by mail-ob0-f182.google.com with SMTP id 16so2680599obc.13
 for <mips@freebsd.org>; 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 <wlosh@bsdimp.com>
Subject: Re: ZERO_REGION_SIZE
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <50A54CCD.8070409@rice.edu>
Date: Thu, 15 Nov 2012 14:07:28 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
References: <50A53391.4080909@rice.edu>
 <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
 <50A54CCD.8070409@rice.edu>
To: Alan Cox <alc@rice.edu>
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQl7U0Sw0xoT9zVVzzJrs7WRACS7Kwj3mAa6WqnquAREnzlA9JaUrsm1wxtIiS0u8mUb/smK
Cc: "Jayachandran C." <jchandra@freebsd.org>, mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <mips@freebsd.org>; 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 <mips@freebsd.org>; Thu, 15 Nov 2012 22:03:03 +0000 (UTC)
Received: by mail-gg0-f182.google.com with SMTP id l1so444573ggn.13
 for <mips@freebsd.org>; 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: <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
References: <50A53391.4080909@rice.edu>
 <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
 <50A54CCD.8070409@rice.edu> <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
From: Juli Mallett <jmallett@FreeBSD.org>
Date: Thu, 15 Nov 2012 14:02:37 -0800
X-Google-Sender-Auth: oeigH5X0M1fL_NpcJlfOKncudTU
Message-ID: <CACVs6=9ZiVeWcJUoeNU_Mybn5WgZ2edUkx4ERPEXD+PODp8gKw@mail.gmail.com>
Subject: Re: ZERO_REGION_SIZE
To: Warner Losh <imp@bsdimp.com>
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." <jchandra@freebsd.org>,
 "freebsd-mips@FreeBSD.org" <mips@freebsd.org>, Alan Cox <alc@rice.edu>
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 22:03:04 -0000

On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <multiple recipients>; 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: <CACVs6=9ZiVeWcJUoeNU_Mybn5WgZ2edUkx4ERPEXD+PODp8gKw@mail.gmail.com>
References: <50A53391.4080909@rice.edu>
 <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
 <50A54CCD.8070409@rice.edu>
 <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
 <CACVs6=9ZiVeWcJUoeNU_Mybn5WgZ2edUkx4ERPEXD+PODp8gKw@mail.gmail.com>
Date: Thu, 15 Nov 2012 17:11:05 -0500
X-Google-Sender-Auth: bRZ3vreJ3TGJlJxGnZB9kgEWcyM
Message-ID: <CAD44qMVVq2nassx7fFai9s=zsiZVPBSFdef87UbMZ4j3PNGkMg@mail.gmail.com>
Subject: Re: ZERO_REGION_SIZE
From: Patrick Kelsey <kelsey@ieee.org>
To: Juli Mallett <jmallett@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Jayachandran C." <jchandra@freebsd.org>,
 "freebsd-mips@FreeBSD.org" <mips@freebsd.org>, Alan Cox <alc@rice.edu>
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 22:11:07 -0000

On Thu, Nov 15, 2012 at 5:02 PM, Juli Mallett <jmallett@freebsd.org> wrote:
> On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <mips@freebsd.org>; 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 <mips@freebsd.org>; Thu, 15 Nov 2012 22:25:05 +0000 (UTC)
Received: by mail-oa0-f54.google.com with SMTP id n9so2782711oag.13
 for <mips@freebsd.org>; 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 <wlosh@bsdimp.com>
Subject: Re: ZERO_REGION_SIZE
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <CAD44qMVVq2nassx7fFai9s=zsiZVPBSFdef87UbMZ4j3PNGkMg@mail.gmail.com>
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>
 <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
 <50A54CCD.8070409@rice.edu> <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
 <CACVs6=9ZiVeWcJUoeNU_Mybn5WgZ2edUkx4ERPEXD+PODp8gKw@mail.gmail.com>
 <CAD44qMVVq2nassx7fFai9s=zsiZVPBSFdef87UbMZ4j3PNGkMg@mail.gmail.com>
To: Patrick Kelsey <kelsey@ieee.org>
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQmiPrQ1aVJS8a+zw/Yl5+pNpxS36IAszFwWA3mD8nb6kN9dY1RPs55SBMumr4UHOk1B5Q0H
Cc: "Jayachandran C." <jchandra@freebsd.org>,
 "freebsd-mips@FreeBSD.org" <mips@freebsd.org>, Alan Cox <alc@rice.edu>
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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 <jmallett@freebsd.org> wrote:
>> On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <multiple recipients>; 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>
 <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
 <50A54CCD.8070409@rice.edu>
 <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
 <CACVs6=9ZiVeWcJUoeNU_Mybn5WgZ2edUkx4ERPEXD+PODp8gKw@mail.gmail.com>
 <CAD44qMVVq2nassx7fFai9s=zsiZVPBSFdef87UbMZ4j3PNGkMg@mail.gmail.com>
 <953A0D95-54E1-4023-A1F5-A4A7DE1C6175@bsdimp.com>
Date: Thu, 15 Nov 2012 17:41:16 -0500
X-Google-Sender-Auth: ilJ7oCPdO7uTe1iwm8Acd8Dn-do
Message-ID: <CAD44qMUGAGvGpY_jRWG71VChkOUDn-_dgcopt-uNx6FAmdfUHA@mail.gmail.com>
Subject: Re: ZERO_REGION_SIZE
From: Patrick Kelsey <kelsey@ieee.org>
To: Warner Losh <imp@bsdimp.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Jayachandran C." <jchandra@freebsd.org>,
 "freebsd-mips@FreeBSD.org" <mips@freebsd.org>, Alan Cox <alc@rice.edu>
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 22:41:19 -0000

On Thu, Nov 15, 2012 at 5:25 PM, Warner Losh <imp@bsdimp.com> wrote:
>
> On Nov 15, 2012, at 3:11 PM, Patrick Kelsey wrote:
>
>> On Thu, Nov 15, 2012 at 5:02 PM, Juli Mallett <jmallett@freebsd.org> wrote:
>>> On Thu, Nov 15, 2012 at 1:07 PM, Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <alc@rice.edu>
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 <imp@bsdimp.com>
Subject: Re: ZERO_REGION_SIZE
References: <50A53391.4080909@rice.edu>
 <CAJ-Vmon-v3K7012ti_L6ao3wQHfQ99Jau1kJ+GhumbPjAuSDww@mail.gmail.com>
 <50A54CCD.8070409@rice.edu> <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
In-Reply-To: <DF2CB7FC-C1ED-4F4C-A39A-60B5E7FC566D@bsdimp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Jayachandran C." <jchandra@freebsd.org>, mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; Fri, 16 Nov 2012 01:36:25 +0000 (UTC)
Received: by mail-da0-f54.google.com with SMTP id z9so989126dad.13
 for <freebsd-mips@freebsd.org>; 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: <CAJ-Vmo=b_UzRVgydeVGHKKyphSXqbDbjoGyzxv=Q0y4SP4bqJQ@mail.gmail.com>
Subject: heads up - changing uart -> uart_ar71xx
From: Adrian Chadd <adrian@freebsd.org>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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" <freebsd@pdx.rh.CN85.ChatUSA.com>
Message-Id: <201211161735.qAGHZb0j070251@pdx.rh.CN85.ChatUSA.com>
Subject: Re: heads up - changing uart -> uart_ar71xx
In-Reply-To: <CAJ-Vmo=b_UzRVgydeVGHKKyphSXqbDbjoGyzxv=Q0y4SP4bqJQ@mail.gmail.com>
To: Adrian Chadd <adrian@freebsd.org>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; Fri, 16 Nov 2012 18:01:08 +0000 (UTC)
Received: by mail-oa0-f54.google.com with SMTP id n9so3857795oag.13
 for <freebsd-mips@freebsd.org>; 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 <wlosh@bsdimp.com>
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 <imp@bsdimp.com>
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" <freebsd@pdx.rh.CN85.ChatUSA.com>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; Fri, 16 Nov 2012 18:03:24 +0000 (UTC)
Received: by mail-da0-f54.google.com with SMTP id z9so1332825dad.13
 for <freebsd-mips@freebsd.org>; 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: <CAJ-Vmo=onaX8-or5TskF=-uHcp+UR5Ne0fSSrd8fs8mNu4dHmA@mail.gmail.com>
Subject: Re: heads up - changing uart -> uart_ar71xx
From: Adrian Chadd <adrian@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com>,
 freebsd-mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Nov 2012 18:03:24 -0000

On 16 November 2012 10:01, Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; Fri, 16 Nov 2012 18:04:10 +0000 (UTC)
Received: by mail-ob0-f182.google.com with SMTP id 16so3830162obc.13
 for <freebsd-mips@freebsd.org>; 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 <wlosh@bsdimp.com>
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 <imp@bsdimp.com>
In-Reply-To: <CAJ-Vmo=onaX8-or5TskF=-uHcp+UR5Ne0fSSrd8fs8mNu4dHmA@mail.gmail.com>
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>
 <CAJ-Vmo=onaX8-or5TskF=-uHcp+UR5Ne0fSSrd8fs8mNu4dHmA@mail.gmail.com>
To: Adrian Chadd <adrian@freebsd.org>
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQmTnjTBexyC7viuscN7tDpCFfPgQLY2WcaeyRKRar9Bqr5dAbJ8DozhAxVdwY/3ggztb/Pb
Cc: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com>,
 freebsd-mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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 <imp@bsdimp.com> 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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; Fri, 16 Nov 2012 18:05:05 +0000 (UTC)
Received: by mail-pb0-f54.google.com with SMTP id wz12so2244947pbc.13
 for <freebsd-mips@freebsd.org>; 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>
 <CAJ-Vmo=onaX8-or5TskF=-uHcp+UR5Ne0fSSrd8fs8mNu4dHmA@mail.gmail.com>
 <8C61D434-FD1A-4DA2-BD5B-C7EBD6685A60@bsdimp.com>
Date: Fri, 16 Nov 2012 10:05:04 -0800
X-Google-Sender-Auth: vmXwOScOVJvP8a0R3qKOiquzZY4
Message-ID: <CAJ-Vmo=Kb0Mgu9q2a-KFJAyLU_H95LKU3QXvvRRycApOYV82Fw@mail.gmail.com>
Subject: Re: heads up - changing uart -> uart_ar71xx
From: Adrian Chadd <adrian@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com>,
 freebsd-mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; Fri, 16 Nov 2012 18:07:05 +0000 (UTC)
Received: by mail-oa0-f54.google.com with SMTP id n9so3866120oag.13
 for <freebsd-mips@freebsd.org>; 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 <wlosh@bsdimp.com>
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 <imp@bsdimp.com>
In-Reply-To: <CAJ-Vmo=Kb0Mgu9q2a-KFJAyLU_H95LKU3QXvvRRycApOYV82Fw@mail.gmail.com>
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>
 <CAJ-Vmo=onaX8-or5TskF=-uHcp+UR5Ne0fSSrd8fs8mNu4dHmA@mail.gmail.com>
 <8C61D434-FD1A-4DA2-BD5B-C7EBD6685A60@bsdimp.com>
 <CAJ-Vmo=Kb0Mgu9q2a-KFJAyLU_H95LKU3QXvvRRycApOYV82Fw@mail.gmail.com>
To: Adrian Chadd <adrian@freebsd.org>
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQkmfO8ghpFCBh7O3/loMszlHUkmavn7JAeM4i467228tKqFnoAndpBolz/LsjeAifC50mkZ
Cc: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com>,
 freebsd-mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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" <freebsd@pdx.rh.CN85.ChatUSA.com>
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 <imp@bsdimp.com>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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: <owner-freebsd-mips@FreeBSD.ORG>
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 <freebsd-mips@freebsd.org>; 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 <freebsd-mips@freebsd.org>; Sat, 17 Nov 2012 09:18:58 +0000 (UTC)
Received: by mail-oa0-f54.google.com with SMTP id n9so4481400oag.13
 for <freebsd-mips@freebsd.org>; 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: <CAJ-Vmo=4wyFPSROu1neMAdsY=bQaw_EDfFrvj7g+Txs1QcrY3w@mail.gmail.com>
Subject: Re: heads up - changing uart -> uart_ar71xx
From: Adrian Chadd <adrian@freebsd.org>
To: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com>
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 <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=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
<freebsd@pdx.rh.cn85.chatusa.com> 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