From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 08:51:51 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 02F825E4
for <freebsd-current@freebsd.org>; Mon, 3 Feb 2014 08:51:51 +0000 (UTC)
Received: from mx.waitman.net (mx.waitman.net [136.0.16.173])
by mx1.freebsd.org (Postfix) with ESMTP id E26611CF2
for <freebsd-current@freebsd.org>; Mon, 3 Feb 2014 08:51:50 +0000 (UTC)
Received: by mx.waitman.net (Postfix, from userid 2)
id BDD2B436AA; Sun, 2 Feb 2014 16:58:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waitman.net;
s=default; t=1391389134;
bh=K86OuaxM1cMG+GTyxpSCmGDtVRksVHq6slKhz9VCjII=;
h=Date:Subject:From:To:Reply-To;
b=QMf0z27NgiciTXzANIeEcds1hdFVmpdmXrBYjO5EOvvD15x456f6aLxT2oY8M1PD9
nHfJlipkznQ2qUq6OHOaRoI/wk905yglPHOrTguv7MB9TB6wFaAS4T9CnnL06earUT
K+hFXcEdFko/HyoHSFb2o88kugAFKqsyOkNtOmQg=
Received: from 67.170.221.223 by mx.waitman.net with HTTP;
Sun, 2 Feb 2014 16:58:54 -0800
Message-ID: <5266435921866b305d2879c1a11a7057.squirrel@mx.waitman.net>
Date: Sun, 2 Feb 2014 16:58:54 -0800
Subject: question about pkgng
From: "Waitman Gobble" <waitman@waitman.net>
To: freebsd-current@freebsd.org
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 03 Feb 2014 13:06:30 +0000
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: waitman@waitman.net
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 08:51:51 -0000
Hi,
I updated my laptop to:
# uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Sun Feb 2
21:45:49 PST 2014 root@akira.waitman.net:/usr/obj/usr/src/sys/AKIRA
amd64
Then updated ports to:
# svn info
Path: .
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 342366
Node Kind: directory
Schedule: normal
Last Changed Author: eadler
Last Changed Rev: 342366
Last Changed Date: 2014-02-02 12:48:28 -0800 (Sun, 02 Feb 2014)
Then I ran 'pkg update' and 'pkg upgrade'
But when I went to install a new port I received errors about boost, I
used pkgng to update boost.
# pkg install boost-all
Updating repository catalogue
The following 5 packages will be installed:
Upgrading icu: 4.8.1.1_1 -> 50.1.2
Installing boost-jam: 1.52.0_1
Installing boost-docs: 1.52.0
Upgrading boost-libs: 1.48.0_1 -> 1.52.0_2
Installing boost-all: 1.52.0
The installation will require 190 MB more space
23 MB to be downloaded
Proceed with installing packages [y/N]: y
...
1) Why didn't pkg upgrade bring boost from 1.48 to 1.52 ?
2) are other packages/ports suspect on this system?
Things look different, but everything is great.
Thank you,
--
Waitman Gobble
San Jose California USA
+1.510-830-7975
From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 13:56:43 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 720CEC4C;
Mon, 3 Feb 2014 13:56:43 +0000 (UTC)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8])
(using TLSv1 with cipher RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id DBA5D1ABD;
Mon, 3 Feb 2014 13:56:42 +0000 (UTC)
Received: from dator167.onk.lu.se (dator167.onk.lu.se [130.235.5.190])
by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis)
id 0M5qIb-1VLPPd1GyP-00xto3; Mon, 03 Feb 2014 14:56:40 +0100
Message-ID: <52EFA015.5070601@FreeBSD.org>
Date: Mon, 03 Feb 2014 14:56:37 +0100
From: Christian Brueffer <brueffer@FreeBSD.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: current@freebsd.org
Subject: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
X-Enigmail-Version: 1.6
OpenPGP: id=3A67DC36; url=http://people.freebsd.org/~brueffer/brueffer.key.asc
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc"
X-Provags-ID: V02:K0:kTF/AVqwW5DPS8hGHs1O/nsqqD5ks04omVkBJwF1SUp
eWjBWx9CpgI9MI6V09Hwzo6kybE98lTmScTIZXjrO+AEYrpqyn
uYPD0q6cCT6+htPBa/f8ETzP0q7VF24cuI0qxhjBPkeoXxX6Xp
Niwta1/shPURiwJZ1SPFuL0MYVJPhGl0WwWAbYnuGuUvw9RZX7
8Zsc/DEcSsZZSUZUWVXZqA0QOjWQIBTBScu/O0abX9hLfGMcmY
tMm2j5fAKUY2cH8dlDUXOEPDtX/9AbcO8GhNSf4F0VLkNQfdPw
h49db+amZ9Upi62KwMWUvmzCiYE+uT6rApnREUbM47nctDIb95
KQISZU0JIfOmnogLDsZ3eKt7ohMfA9LxfPu1lpnog
Cc: stable@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 13:56:43 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,
for some time now we have had two drivers for NVIDIA NForce/MCP network
chips, namely nve(4) and nfe(4).
The former came first and is based on a binary blob. The latter was
later ported from OpenBSD and is blob-free.
nfe(4) supports all chips nve(4) supports, in addition to all the newer
hardware. In essence, nfe(4) has been the de-facto standard driver for
a long time. nve(4) has been commented out in GENERIC since 2007.
For this reason I propose deprecating nve(4) in 10-STABLE and removing
it from HEAD.
Does anyone see a reason not to do this?
Cheers,
Christian (wearing my best asbestos suit)
--UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJ8BAEBCgBmBQJS76AXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QzhCQjQ5MDgzNDUwNjkyOUM5Mjg2NDE3
OEM4MzY5ODQ3RTE2NDg3AAoJEHjINphH4WSHY/4P/ipUMMZmrJvjWc+FSo+IONT/
S9T8mIZQqSgcyYT8/Ff/zSS/JIfHwob1sZ8gzubbj0m66zDSZ9QdMVx5xmy37B1L
/5gEbXNR3RMRXs3VDinDA2aEoc7lkgLnyHB3rbcETsk9LCorWV5PKAH73aQuNiIJ
LVbr6UDxlzF/YuLrN92X4ujlKAN+iZHLof4Z4hS9PV6kiZfNDrKX58wmKUBmfCZw
cw9H5aH6bHVUaZuiTPdVIwHon6EAzGY7MffgY/wsT+TU/Mex44jvK2jU5D394Rf7
UjkZfrs2U2ppak4z4IDo7QiypS9wajqv2DM1UJjOoMGh360hnR8m1zPnIdaji4DU
Xox93sS60La2bpqOjUtA5rshRrngEASodCpHKB2uaZ0btalrbHNR+8CptXwilSUA
kgPVCwDWH+XtGkwjs35A5f8CRBsfw4817vxz0vHGRBbpSNN8rNGlNXQVT3DwWVR4
7Ry3LPKYTJs2SA3BeZ2cBI/Gcdfi0dFTOgiOVZxeerpuCLas0JbOuy7cebgF80xr
qEulCTePxxFekMxHVstXUmSL6LoHMwYoQspxbAPbxPeWOrghanshPHeoe2o92PjI
hKl493TsBQFIsacUdCVafJSNsocKxlrpwbVQ6bF83Dhz5JH6lKyZ2FQHDp3T525y
qarxKSWPJ2avdAHtrRlt
=PuZ6
-----END PGP SIGNATURE-----
--UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc--
From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 14:24:06 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 91E88598;
Mon, 3 Feb 2014 14:24:06 +0000 (UTC)
Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 530691D17;
Mon, 3 Feb 2014 14:24:06 +0000 (UTC)
Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2])
(authenticated bits=0)
by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s13ENmhq020319
(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
Mon, 3 Feb 2014 08:23:49 -0600 (CST)
(envelope-from tundra@tundraware.com)
Message-ID: <52EFA674.8000106@tundraware.com>
Date: Mon, 03 Feb 2014 08:23:48 -0600
From: Tim Daneliuk <tundra@tundraware.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Christian Brueffer <brueffer@FreeBSD.org>, current@freebsd.org
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
References: <52EFA015.5070601@FreeBSD.org>
In-Reply-To: <52EFA015.5070601@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3
(ozzie.tundraware.com [75.145.138.73]); Mon, 03 Feb 2014 08:23:49 -0600 (CST)
X-TundraWare-MailScanner-Information: Please contact the ISP for more
information
X-TundraWare-MailScanner-ID: s13ENmhq020319
X-TundraWare-MailScanner: Found to be clean
X-TundraWare-MailScanner-From: tundra@tundraware.com
X-Spam-Status: No
X-Mailman-Approved-At: Mon, 03 Feb 2014 14:42:55 +0000
Cc: stable@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 14:24:06 -0000
On 02/03/2014 07:56 AM, Christian Brueffer wrote:
> Hi,
>
> for some time now we have had two drivers for NVIDIA NForce/MCP network
> chips, namely nve(4) and nfe(4).
>
> The former came first and is based on a binary blob. The latter was
> later ported from OpenBSD and is blob-free.
>
> nfe(4) supports all chips nve(4) supports, in addition to all the newer
> hardware. In essence, nfe(4) has been the de-facto standard driver for
> a long time. nve(4) has been commented out in GENERIC since 2007.
>
> For this reason I propose deprecating nve(4) in 10-STABLE and removing
> it from HEAD.
>
> Does anyone see a reason not to do this?
>
> Cheers,
>
> Christian (wearing my best asbestos suit)
>
If you're going to be so very polite about it, how do you
expect us to have a 2000 email chain fight examining
every possible implication of your proposal ... :)
--
----------------------------------------------------------------------------
Tim Daneliuk tundra@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 16:25:57 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 3B10A312
for <freebsd-current@freebsd.org>; Mon, 3 Feb 2014 16:25:57 +0000 (UTC)
Received: from nm9-vm1.bullet.mail.ne1.yahoo.com
(nm9-vm1.bullet.mail.ne1.yahoo.com [98.138.90.47])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id DF9C318CD
for <freebsd-current@freebsd.org>; Mon, 3 Feb 2014 16:25:56 +0000 (UTC)
Received: from [98.138.100.111] by nm9.bullet.mail.ne1.yahoo.com with NNFMP;
03 Feb 2014 16:25:50 -0000
Received: from [98.138.226.61] by tm100.bullet.mail.ne1.yahoo.com with NNFMP;
03 Feb 2014 16:25:50 -0000
Received: from [127.0.0.1] by smtp212.mail.ne1.yahoo.com with NNFMP;
03 Feb 2014 16:25:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
t=1391444750; bh=PlMyBk0bMQEE6IFeQ29ekd7I95SfseJ0mj4R1pzcmNg=;
h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding;
b=sLSO5DeOEk4e+gIRZ4/WfanhbvGiyXXmdCp9aOha+KnuksyCQEO2xfqTWjCRbLZWfaZTf61b5PWijNsgAldTh6IS6phcISIPTIfGKtilKXsti7zgXD8oKzuBcHA7cfYaGZ4K56G/5sFVfDGZSC96bGQlnx0o/581ySwrwxwcQGM=
X-Yahoo-Newman-Id: 256606.84284.bm@smtp212.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: jNYjIgkVM1m19kS17BijhQEIJBYXdHEZx4onYHl19gYDmEg
KbadGruyv9531v9FdxZPf6D_8DJ6nffQhCwcUuSBjeytr4eLWs2FB.w1ZPhR
DEfj5GqVm8fsgJ4OtoGmz7QSiriRmtS9586Wolfr3ua8Q0r5.WG.dTqg1PQc
rwzv6XzTZ2Oj_tCCRhHTvgz8txAlvDOCjmj9CJAY7J7nUK2HIRP9wtoZeF1O
EDsRJfQyaU4H4izeO39yfvA6RieYykAJ4oR1I6r9fPy.yirKDanmiXU9FzcH
cKbEd4zTr5DUTVfMdtVIy9jya37pi9POyY2ai_cdEZkVU8sJZNdUGPobDi.S
s4ar1yhibOtMsv.PpXGkNU4VMJvSNH38ncgNDxFOldiQm3dHDm1r2cq2oDcN
JtJPwTxhGWpRyv4gwj.0WCNyFLzXuDIeJR1m6yTcJXBm9sitIWCIGghhLu6J
lGD8H97c.ihv3HM29bhKtfBIZ3KBP7QXf15JEwS4Du_pwIfTdR0roL6xTXCJ
wzVdY2gcymViH6BbfGLVJaQ4.s2FjzbZbRBWE6j.JEZrcBVTTvnweBW3HFEn
0ai2xP40-
X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4-
X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with plain
[63.250.193.228])
by smtp212.mail.ne1.yahoo.com with SMTP; 03 Feb 2014 08:25:50 -0800 PST
Subject: installworld recreating unwanted dirs
From: Sean Bruno <sean_bruno@yahoo.com>
To: freebsd-current@freebsd.org
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 03 Feb 2014 08:25:48 -0800
Message-ID: <1391444748.1473.3.camel@powernoodle.corp.yahoo.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: sbruno@freebsd.org
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 16:25:57 -0000
I don't understand what I'm doing wrong here. I've added a lot of
"WITHOUT" directives to my src.conf, but installworld seems to be
ignoring them and recreating directories that "make delete-old && make
delete-old-libs" removes. Have I missed something obvious here?
src.conf:
WITHOUT_AMD=y
WITHOUT_APM=y
WITHOUT_CALENDAR=y
WITHOUT_CAPSICUM=y
WITHOUT_CASPER=y
WITHOUT_CDDL=y
WITHOUT_EXAMPLES=y
WITHOUT_FLOPPY=y
WITHOUT_FREEBSD_UPDATE=y
WITHOUT_GAMES=y
WITHOUT_GPIB=y
WITHOUT_GPIO=y
WITHOUT_HTML=y
WITHOUT_IPFILTER=y
WITHOUT_IPFW=y
WITHOUT_IPX=y
WITHOUT_KERBEROS=y
WITHOUT_LIB32=y
WITHOUT_LPR=y
WITHOUT_NDIS=y
WITHOUT_NETGRAPH=y
WITHOUT_NIS=y
WITHOUT_PC_SYSINSTALL=y
WITHOUT_PMC=y
WITHOUT_PPP=y
WITHOUT_RCMDS=y
WITHOUT_RCS=y
WITHOUT_RESCUE=y
WITHOUT_SHAREDOCS=y
WITHOUT_SYSINSTALL=y
WITHOUT_USB=y
WITHOUT_WIRELESS=y
# make -s installworld
--------------------------------------------------------------
>>> Making hierarchy
--------------------------------------------------------------
./etc/bluetooth missing (created)
./etc/ppp missing (created)
./games missing (created)
./lib/dtrace missing (created)
./lib32/dtrace missing (created)
./libexec/lpr missing (created)
./libexec/lpr/ru missing (created)
./share/calendar missing (created)
./share/calendar/de_AT.ISO_8859-15 missing (created)
./share/calendar/de_DE.ISO8859-1 missing (created)
./share/calendar/fr_FR.ISO8859-1 missing (created)
./share/calendar/hr_HR.ISO8859-2 missing (created)
./share/calendar/hu_HU.ISO8859-2 missing (created)
./share/calendar/pt_BR.ISO8859-1 missing (created)
./share/calendar/pt_BR.UTF-8 missing (created)
./share/calendar/ru_RU.KOI8-R missing (created)
./share/calendar/ru_RU.UTF-8 missing (created)
./share/calendar/uk_UA.KOI8-U missing (created)
./share/doc/atm missing (created)
./share/doc/smm/07.lpd missing (created)
./share/examples/hostapd missing (created)
./share/examples/ipfilter missing (created)
./share/examples/pc-sysinstall missing (created)
./share/games missing (created)
./share/games/fortune missing (created)
./share/pc-sysinstall missing (created)
./share/pc-sysinstall/backend missing (created)
./share/pc-sysinstall/backend-partmanager missing (created)
./share/pc-sysinstall/backend-query missing (created)
./share/pc-sysinstall/conf missing (created)
./share/pc-sysinstall/conf/license missing (created)
./share/pc-sysinstall/doc missing (created)
./dev/ieee488 missing (created)
./gpib missing (created)
./kadm5 missing (created)
./krb5 missing (created)
./netgraph/bluetooth missing (created)
./netgraph/bluetooth/include missing (created)
./netnatm/api missing (created)
./netnatm/msg missing (created)
./netnatm/saal missing (created)
./netnatm/sig missing (created)
From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 16:32:30 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 730EB48C;
Mon, 3 Feb 2014 16:32:30 +0000 (UTC)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu
[128.95.76.21])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 4F272196A;
Mon, 3 Feb 2014 16:32:30 +0000 (UTC)
Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu
[127.0.0.1])
by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id s13GWJwA013452
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Mon, 3 Feb 2014 08:32:19 -0800 (PST)
(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id s13GWJsi013451;
Mon, 3 Feb 2014 08:32:19 -0800 (PST) (envelope-from sgk)
Date: Mon, 3 Feb 2014 08:32:19 -0800
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: John Baldwin <jhb@freebsd.org>
Subject: Re: Instant panic CAM or USB subsystem
Message-ID: <20140203163219.GA13386@troutmask.apl.washington.edu>
References: <20140125172106.GA67590@troutmask.apl.washington.edu>
<201401281232.21958.jhb@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201401281232.21958.jhb@freebsd.org>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: Alexander Motin <mav@freebsd.org>, freebsd-current@freebsd.org,
scsi@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 16:32:30 -0000
On Tue, Jan 28, 2014 at 12:32:21PM -0500, John Baldwin wrote:
> On Saturday, January 25, 2014 12:21:06 pm Steve Kargl wrote:
> > If I plug my Samsung Intensity II cellphone into a usb port,
> > I get an instant panic. This is 100% reproducible. I have
> > the core and kernel for further debugging. Dmesg.boot follows
> > my sig.
> >
> > % kgdb /boot/kernel/kernel /vmcore.0
> >
> > Unread portion of the kernel message buffer:
> > cd1 at umass-sim1 bus 1 scbus4 target 0 lun 0
> > cd1: <SAMSUNG CD-ROM 1.00> Removable CD-ROM SCSI-2 device
> > cd1: Serial Number 000000000002
> > cd1: 1.000MB/s transfers
> > cd1: cd present [3840000 x 512 byte records]
> > cd1: quirks=0x10<10_BYTE_ONLY>
> > panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301
> > cpuid = 0
> > KDB: enter: panic
>
> scsi@ might work better for this. It looks like when cdasync() calls
> cam_periph_alloc() it doesn't have its associated xpt_path locked. All the
> other async xpt callbacks I looked at don't lock the xpt path either. It
> seems they expect it to be locked by the caller when they are invoked. It
> seems xpt_async_process_dev() doesn't always lock xpt_lock, but sometimes
> locks the device instead:
>
> /*
> * If async for specific device is to be delivered to
> * the wildcard client, take the specific device lock.
> * XXX: We may need a way for client to specify it.
> */
> if ((device->lun_id == CAM_LUN_WILDCARD &&
> path->device->lun_id != CAM_LUN_WILDCARD) ||
> (device->target->target_id == CAM_TARGET_WILDCARD &&
> path->target->target_id != CAM_TARGET_WILDCARD) ||
> (device->target->bus->path_id == CAM_BUS_WILDCARD &&
> path->target->bus->path_id != CAM_BUS_WILDCARD)) {
> mtx_unlock(&device->device_mtx);
> xpt_path_lock(path);
> relock = 1;
> } else
> relock = 0;
>
> (*(device->target->bus->xport->async))(async_code,
> device->target->bus, device->target, device, async_arg);
> xpt_async_bcast(&device->asyncs, async_code, path, async_arg);
>
> if (relock) {
> xpt_path_unlock(path);
> mtx_lock(&device->device_mtx);
> }
>
> Maybe try going up to this frame (16) in your dump and do
> 'p *device->target'? However, someone with more CAM knowledge needs to look
> at this to see what is actually broken.
>
I finally have time to look at this again. Here's kgdb for frame 16
as you suggested and then frame 17.
Script started on Mon Feb 3 08:16:32 2014
% kgdb /dsk1/obj/usr/src/sys/MOBILE/kernel.debug vmcore.0
Unread portion of the kernel message buffer:
panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301
cpuid = 1
KDB: enter: panic
#16 0xc047d6a5 in xpt_async_process_dev (device=<value optimized out>,
arg=0xc70aa800) at /usr/src/sys/cam/cam_xpt.c:4208
#17 0xc047b346 in xpt_async_process (periph=0x0, ccb=0xc70aa800)
at /usr/src/sys/cam/cam_xpt.c:4173
#18 0xc047bd15 in xpt_done_process (ccb_h=0xc70aa800)
at /usr/src/sys/cam/cam_xpt.c:5249
#19 0xc047ef14 in xpt_done_td (arg=<value optimized out>)
at /usr/src/sys/cam/cam_xpt.c:5276
#20 0xc0723daf in fork_exit (callout=0xc047edb0 <xpt_done_td>)
at /usr/src/sys/kern/kern_fork.c:977
#21 0xc09fb3e4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:278
Current language: auto; currently minimal
(kgdb) frame 16
#16 0xc047d6a5 in xpt_async_process_dev (device=<value optimized out>,
arg=0xc70aa800) at /usr/src/sys/cam/cam_xpt.c:4208
4208 cur_entry->callback(cur_entry->callback_arg,
(kgdb) p *device
Cannot access memory at address 0x0
(kgdb) up 1
#17 0xc047b346 in xpt_async_process (periph=0x0, ccb=0xc70aa800)
at /usr/src/sys/cam/cam_xpt.c:4173
4173 xpt_async_process_dev(xpt_periph->path->device, ccb);
(kgdb) p *xpt_periph->path->device->target
$2 = {ed_entries = {tqh_first = 0xc6f4b800, tqh_last = 0xc6f4b80c}, links = {
tqe_next = 0x0, tqe_prev = 0xc6eaaa00}, bus = 0xc6eaaa00,
target_id = 4294967295, refcount = 2, generation = 1, last_reset = {
tv_sec = 0, tv_usec = 0}, rpl_size = 0, luns = 0x0, luns_mtx = {
lock_object = {lo_name = 0xc0a3f9bc "CAM LUNs lock", lo_flags = 16973824,
lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}}
(kgdb) p *xpt_periph->path->device->target->bus
$3 = {et_entries = {tqh_first = 0xc6eaa980, tqh_last = 0xc6eaa988}, links = {
tqe_next = 0x0, tqe_prev = 0xc7690008}, path_id = 4294967295,
sim = 0xc6eaaa80, last_reset = {tv_sec = 0, tv_usec = 0}, flags = 0,
refcount = 3, generation = 3, parent_dev = 0x0, xport = 0xc0b2f568,
eb_mtx = {lock_object = {lo_name = 0xc0a3f85a "CAM bus lock",
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}}
(kgdb) quit
% exit
exit
Script done on Mon Feb 3 08:20:44 2014
--
Steve
From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 16:41:06 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 717A967D
for <freebsd-current@freebsd.org>; Mon, 3 Feb 2014 16:41:06 +0000 (UTC)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com
[IPv6:2607:f8b0:400c:c03::231])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 296E51A2C
for <freebsd-current@freebsd.org>; Mon, 3 Feb 2014 16:41:06 +0000 (UTC)
Received: by mail-vc0-f177.google.com with SMTP id if11so4861639vcb.36
for <freebsd-current@freebsd.org>; Mon, 03 Feb 2014 08:41:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=tlPtztg/rBFOJrL254/HAHPr5vikFpnUGxN1pLRCVnY=;
b=XIjKZcHS3MSPc1fnj5wJk4a9Q1pUSwYAEn/biZaylSCagj9JDbDMtaM2Kv2RUaNB+Q
DX8ScNK8/CNctkTT4xESbE5nhlwGkcNuVUsmOcjtnRMCEIDOJTABHwjwAYjkT3gALhNW
hx13/9utk51U02jEKqHqLJESe74TXwC+xc4Gc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=tlPtztg/rBFOJrL254/HAHPr5vikFpnUGxN1pLRCVnY=;
b=GMvffgP0mXay1RJ7X6lgEPPkNKj8p+IBxhUQSfmkHgus9+T2+I3U1piBofG/L//kMc
bBJM8ieRPiEShjimjDnx7QXd9VWyUGir7JkiwwDjew4ULC45EA1fbGsBBFVvQa85pGWy
5Z2QaogYhCuA9EwByiMn4rxehqeLgOMF/qzCLRi0oXjhY8OaksZymNvXF6Xi/0nchxml
VYqOCh3Yfa52MSYVvxRH7ImbVnSH0RpT3ht1a5ThN6UetTFbjyfGWXvSUg3d+WlrGd6Y
f+nh1xheUEv5C8aUXs6B/VZEz7XJ2gONfuBHnARNvo95sbIL/8zkD9NDDPPYbVeXH2GR
oX7Q==
X-Gm-Message-State: ALoCoQlHxqey49vWcSi5MeIkNthEvgitdhtx9Cz3+qvqmdZjF5PrcbpwAqPIl5cTkdGnlwads8gf
MIME-Version: 1.0
X-Received: by 10.221.26.10 with SMTP id rk10mr29568564vcb.0.1391445665264;
Mon, 03 Feb 2014 08:41:05 -0800 (PST)
Received: by 10.220.30.69 with HTTP; Mon, 3 Feb 2014 08:41:05 -0800 (PST)
In-Reply-To: <1391444748.1473.3.camel@powernoodle.corp.yahoo.com>
References: <1391444748.1473.3.camel@powernoodle.corp.yahoo.com>
Date: Mon, 3 Feb 2014 08:41:05 -0800
Message-ID: <CAGE5yCoH7PY38CNNs91XfsJ56vBFbiBR_84+vm-j4Wf-nYo2_A@mail.gmail.com>
Subject: Re: installworld recreating unwanted dirs
From: Peter Wemm <peter@wemm.org>
To: Sean Bruno <sbruno@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: FreeBSD Current <freebsd-current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 16:41:06 -0000
On Mon, Feb 3, 2014 at 8:25 AM, Sean Bruno <sean_bruno@yahoo.com> wrote:
> I don't understand what I'm doing wrong here. I've added a lot of
> "WITHOUT" directives to my src.conf, but installworld seems to be
> ignoring them and recreating directories that "make delete-old && make
> delete-old-libs" removes. Have I missed something obvious here?
The mtree based directory creation is (for the most part) unaware of
with/without flags. There was some mtree partitioning for things like
bind and those were only created if bind was enabled. But for the
most part, delete-old will prune things that aren't used.
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
Yes, I know, gmail sucks now. If you see this then I forgot. Habits
are hard to break.
From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 16:53:40 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id AAB82CC5;
Mon, 3 Feb 2014 16:53:40 +0000 (UTC)
Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id E141A1B66;
Mon, 3 Feb 2014 16:53:39 +0000 (UTC)
Received: from lor.one-eyed-alien.net (localhost [127.0.0.1])
by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s13GrXn4063444;
Mon, 3 Feb 2014 10:53:33 -0600 (CST)
(envelope-from brooks@lor.one-eyed-alien.net)
Received: (from brooks@localhost)
by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s13GrXsY063443;
Mon, 3 Feb 2014 10:53:33 -0600 (CST) (envelope-from brooks)
Date: Mon, 3 Feb 2014 10:53:33 -0600
From: Brooks Davis <brooks@freebsd.org>
To: sbruno@freebsd.org
Subject: Re: installworld recreating unwanted dirs
Message-ID: <20140203165333.GB52975@lor.one-eyed-alien.net>
References: <1391444748.1473.3.camel@powernoodle.corp.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M"
Content-Disposition: inline
In-Reply-To: <1391444748.1473.3.camel@powernoodle.corp.yahoo.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: freebsd-current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 16:53:40 -0000
--DKU6Jbt7q3WqK7+M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 03, 2014 at 08:25:48AM -0800, Sean Bruno wrote:
> I don't understand what I'm doing wrong here. I've added a lot of
> "WITHOUT" directives to my src.conf, but installworld seems to be
> ignoring them and recreating directories that "make delete-old && make
> delete-old-libs" removes. Have I missed something obvious here?
Directories are created by mtree using the files in etc/mtree and the proce=
ss
is all or nothing. Currently only groff and sendmail have their own mtree
files to allow their directories not be created. With the current file
format I don't think it would be a good idea to split the mtree files to
support not creating these directories. Once we switch to the new
format where each directory is specified on a single line it might be
practical to break up the mtree files accordingly, but that feels hard
to maintain for a pretty limited benefit.
-- Brooks
> src.conf:
> WITHOUT_AMD=3Dy
> WITHOUT_APM=3Dy
> WITHOUT_CALENDAR=3Dy
> WITHOUT_CAPSICUM=3Dy
> WITHOUT_CASPER=3Dy
> WITHOUT_CDDL=3Dy
> WITHOUT_EXAMPLES=3Dy
> WITHOUT_FLOPPY=3Dy
> WITHOUT_FREEBSD_UPDATE=3Dy
> WITHOUT_GAMES=3Dy
> WITHOUT_GPIB=3Dy
> WITHOUT_GPIO=3Dy
> WITHOUT_HTML=3Dy
> WITHOUT_IPFILTER=3Dy
> WITHOUT_IPFW=3Dy
> WITHOUT_IPX=3Dy
> WITHOUT_KERBEROS=3Dy
> WITHOUT_LIB32=3Dy
> WITHOUT_LPR=3Dy
> WITHOUT_NDIS=3Dy
> WITHOUT_NETGRAPH=3Dy
> WITHOUT_NIS=3Dy
> WITHOUT_PC_SYSINSTALL=3Dy
> WITHOUT_PMC=3Dy
> WITHOUT_PPP=3Dy
> WITHOUT_RCMDS=3Dy
> WITHOUT_RCS=3Dy
> WITHOUT_RESCUE=3Dy
> WITHOUT_SHAREDOCS=3Dy
> WITHOUT_SYSINSTALL=3Dy
> WITHOUT_USB=3Dy
> WITHOUT_WIRELESS=3Dy
>=20
>=20
> # make -s installworld
> --------------------------------------------------------------
> >>> Making hierarchy
> --------------------------------------------------------------
> ./etc/bluetooth missing (created)
> ./etc/ppp missing (created)
> ./games missing (created)
> ./lib/dtrace missing (created)
> ./lib32/dtrace missing (created)
> ./libexec/lpr missing (created)
> ./libexec/lpr/ru missing (created)
> ./share/calendar missing (created)
> ./share/calendar/de_AT.ISO_8859-15 missing (created)
> ./share/calendar/de_DE.ISO8859-1 missing (created)
> ./share/calendar/fr_FR.ISO8859-1 missing (created)
> ./share/calendar/hr_HR.ISO8859-2 missing (created)
> ./share/calendar/hu_HU.ISO8859-2 missing (created)
> ./share/calendar/pt_BR.ISO8859-1 missing (created)
> ./share/calendar/pt_BR.UTF-8 missing (created)
> ./share/calendar/ru_RU.KOI8-R missing (created)
> ./share/calendar/ru_RU.UTF-8 missing (created)
> ./share/calendar/uk_UA.KOI8-U missing (created)
> ./share/doc/atm missing (created)
> ./share/doc/smm/07.lpd missing (created)
> ./share/examples/hostapd missing (created)
> ./share/examples/ipfilter missing (created)
> ./share/examples/pc-sysinstall missing (created)
> ./share/games missing (created)
> ./share/games/fortune missing (created)
> ./share/pc-sysinstall missing (created)
> ./share/pc-sysinstall/backend missing (created)
> ./share/pc-sysinstall/backend-partmanager missing (created)
> ./share/pc-sysinstall/backend-query missing (created)
> ./share/pc-sysinstall/conf missing (created)
> ./share/pc-sysinstall/conf/license missing (created)
> ./share/pc-sysinstall/doc missing (created)
> ./dev/ieee488 missing (created)
> ./gpib missing (created)
> ./kadm5 missing (created)
> ./krb5 missing (created)
> ./netgraph/bluetooth missing (created)
> ./netgraph/bluetooth/include missing (created)
> ./netnatm/api missing (created)
> ./netnatm/msg missing (created)
> ./netnatm/saal missing (created)
> ./netnatm/sig missing (created)
--DKU6Jbt7q3WqK7+M
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iD8DBQFS78mMXY6L6fI4GtQRAmEfAJ4iYbaoPEdVe3of20omr+3tOBiGZwCg3xZW
DL4RoOM3ijf+pIhoTsp6IBo=
=r5Kj
-----END PGP SIGNATURE-----
--DKU6Jbt7q3WqK7+M--
From owner-freebsd-current@FreeBSD.ORG Mon Feb 3 20:52:58 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 637D6BE;
Mon, 3 Feb 2014 20:52:58 +0000 (UTC)
Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [78.47.69.234])
by mx1.freebsd.org (Postfix) with ESMTP id 1C9C61316;
Mon, 3 Feb 2014 20:52:57 +0000 (UTC)
Received: from [IPv6:2001:470:d701::818c:79e3:fcc8:6825] (unknown
[IPv6:2001:470:d701:0:818c:79e3:fcc8:6825])
by mail.jr-hosting.nl (Postfix) with ESMTPSA id DF5373F467;
Mon, 3 Feb 2014 21:52:50 +0100 (CET)
Content-Type: multipart/signed;
boundary="Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817";
protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
From: Remko Lodder <remko@FreeBSD.org>
In-Reply-To: <52EFA674.8000106@tundraware.com>
Date: Mon, 3 Feb 2014 21:52:49 +0100
Message-Id: <A4494871-6A8A-4D59-8D36-115890B301B3@FreeBSD.org>
References: <52EFA015.5070601@FreeBSD.org> <52EFA674.8000106@tundraware.com>
To: Tim Daneliuk <tundra@tundraware.com>
X-Mailer: Apple Mail (2.1827)
Cc: stable@freebsd.org, current@freebsd.org,
Christian Brueffer <brueffer@FreeBSD.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 20:52:58 -0000
--Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 03 Feb 2014, at 15:23, Tim Daneliuk <tundra@tundraware.com> wrote:
> On 02/03/2014 07:56 AM, Christian Brueffer wrote:
>> Hi,
>>=20
>> for some time now we have had two drivers for NVIDIA NForce/MCP =
network
>> chips, namely nve(4) and nfe(4).
>>=20
>> The former came first and is based on a binary blob. The latter was
>> later ported from OpenBSD and is blob-free.
>>=20
>> nfe(4) supports all chips nve(4) supports, in addition to all the =
newer
>> hardware. In essence, nfe(4) has been the de-facto standard driver =
for
>> a long time. nve(4) has been commented out in GENERIC since 2007.
>>=20
>> For this reason I propose deprecating nve(4) in 10-STABLE and =
removing
>> it from HEAD.
>>=20
>> Does anyone see a reason not to do this?
>>=20
>> Cheers,
>>=20
>> Christian (wearing my best asbestos suit)
>>=20
>=20
>=20
> If you're going to be so very polite about it, how do you
> expect us to have a 2000 email chain fight examining
> every possible implication of your proposal ... :)
in other words, just do it [tm].
>=20
>=20
> --=20
> =
--------------------------------------------------------------------------=
--
> Tim Daneliuk tundra@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
>=20
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to =
"freebsd-current-unsubscribe@freebsd.org"
--=20
/"\ Best regards, | remko@FreeBSD.org
\ / Remko Lodder | remko@EFnet
X http://www.evilcoder.org/ |
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
--Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJS8AGhAAoJEKjD27JZ84ywzP4P/1BzzAZavF+dTVlwlltHf8BW
DrK6Mejp2U5rQxuMeDyAsHrI0u97nOOpmVkc83ujoCFtY5Zdrn5/aqBw/xefFmsd
A/GwjewafBeS7gjLy4U2Sc7espT/wzeLah+ZTD+sTnlR3wdG3aNsWAB022ywVLXl
IO54VFfXg4kHeEC6htaUPpT+NmL4ZOD3OEmtFxVZJHa9Kipmz8Q4wrlKFYogDvSG
wOJ4U+aufM0sbVncKtrqFAmFBntbi2PvB24be2iM/2aigQp+LO82/2k/MnT6J0cy
IAY7sN+9blidhM4fs5xATbOUJv6M1p6qJokYJYpizar7JUJw0k5oMbDKSZExjHlU
RV2+rR0xPvUaSaCmN/ugtEmtzIYOQO7jBlT9b46nagJmBcZnkXy2N3T1YpFETQSP
QbNr5Qeq/r1O4TDZ+PRDeEEQH08PekCtL+HZZC+TVDW3k3FcjFCzVPFv9glP6HUB
IfX3dGtjFWV3skajBhB0tKu0coOJrc2s1uXCAiXP6Xv9q0MmrrVLiAkv19ZZ6jYk
lhnLK4ULbD3ZUGOrI7fF5qrR1jcvFOQnlYI0uwCXWY6aprjZKWwQWhCtVcZAdriW
fayKco64shFMfNdi8r8UfJXVG8mSLFeudeSMVQoXQgx/IPcqyM7vS7sAlxEgsVLN
YNo5hk/+/DKced3BtRjg
=r8VW
-----END PGP SIGNATURE-----
--Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817--
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 05:13:19 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 65A7F9F5;
Tue, 4 Feb 2014 05:13:19 +0000 (UTC)
Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca
[64.7.128.98])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 33C3412AD;
Tue, 4 Feb 2014 05:13:18 +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 s145DCnP058611;
Tue, 4 Feb 2014 00:13:12 -0500 (EST)
(envelope-from tinderbox@freebsd.org)
Received: (from tinderbox@localhost)
by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s145DC4l058592;
Tue, 4 Feb 2014 05:13:12 GMT (envelope-from tinderbox@freebsd.org)
Date: Tue, 4 Feb 2014 05:13:12 GMT
Message-Id: <201402040513.s145DC4l058592@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>,
<arm@freebsd.org>
Subject: [head tinderbox] failure on arm/arm
Precedence: bulk
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 05:13:19 -0000
TB --- 2014-02-04 02:10:23 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-04 02:10:23 - 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 --- 2014-02-04 02:10:23 - starting HEAD tinderbox run for arm/arm
TB --- 2014-02-04 02:10:23 - cleaning the object tree
TB --- 2014-02-04 02:10:23 - /usr/local/bin/svn stat /src
TB --- 2014-02-04 02:10:28 - At svn revision 261451
TB --- 2014-02-04 02:10:29 - building world
TB --- 2014-02-04 02:10:29 - CROSS_BUILD_TESTING=YES
TB --- 2014-02-04 02:10:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-02-04 02:10:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-02-04 02:10:29 - SRCCONF=/dev/null
TB --- 2014-02-04 02:10:29 - TARGET=arm
TB --- 2014-02-04 02:10:29 - TARGET_ARCH=arm
TB --- 2014-02-04 02:10:29 - TZ=UTC
TB --- 2014-02-04 02:10:29 - __MAKE_CONF=/dev/null
TB --- 2014-02-04 02:10:29 - cd /src
TB --- 2014-02-04 02:10:29 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Tue Feb 4 02:10:38 UTC 2014
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue Feb 4 05:13:11 UTC 2014
TB --- 2014-02-04 05:13:11 - generating LINT kernel config
TB --- 2014-02-04 05:13:11 - cd /src/sys/arm/conf
TB --- 2014-02-04 05:13:11 - /usr/bin/make -B LINT
TB --- 2014-02-04 05:13:11 - cd /src/sys/arm/conf
TB --- 2014-02-04 05:13:11 - /usr/sbin/config -m LINT
TB --- 2014-02-04 05:13:11 - building LINT kernel
TB --- 2014-02-04 05:13:11 - CROSS_BUILD_TESTING=YES
TB --- 2014-02-04 05:13:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-02-04 05:13:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-02-04 05:13:11 - SRCCONF=/dev/null
TB --- 2014-02-04 05:13:11 - TARGET=arm
TB --- 2014-02-04 05:13:11 - TARGET_ARCH=arm
TB --- 2014-02-04 05:13:11 - TZ=UTC
TB --- 2014-02-04 05:13:11 - __MAKE_CONF=/dev/null
TB --- 2014-02-04 05:13:11 - cd /src
TB --- 2014-02-04 05:13:11 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb 4 05:13:11 UTC 2014
>>> stage 1: configuring the kernel
--------------------------------------------------------------
cd /src/sys/arm/conf; PATH=/obj/arm.arm/src/tmp/legacy/usr/sbin:/obj/arm.arm/src/tmp/legacy/usr/bin:/obj/arm.arm/src/tmp/legacy/usr/games:/obj/arm.arm/src/tmp/legacy/bin:/obj/arm.arm/src/tmp/usr/sbin:/obj/arm.arm/src/tmp/usr/bin:/obj/arm.arm/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/arm.arm/src/sys/LINT /src/sys/arm/conf/LINT
WARNING: duplicate option `GEOM_PART_BSD' encountered.
WARNING: duplicate option `GEOM_PART_MBR' encountered.
WARNING: duplicate option `DEV_MEM' encountered.
WARNING: duplicate device `mem' encountered.
WARNING: duplicate option `CAM_DEBUG_DELAY' encountered.
standard entry arm/econa/ehci_ebus.c has optional inclusion specifier ehci!
*** Error code 1
Stop.
bmake: stopped in /src
*** Error code 1
Stop in /src.
TB --- 2014-02-04 05:13:12 - WARNING: /usr/bin/make returned exit code 1
TB --- 2014-02-04 05:13:12 - ERROR: failed to build LINT kernel
TB --- 2014-02-04 05:13:12 - 8746.76 user 1635.26 system 10968.73 real
http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 05:37:50 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 8B1373D2
for <freebsd-current@freebsd.org>; Tue, 4 Feb 2014 05:37:50 +0000 (UTC)
Received: from mx.waitman.net (mx.waitman.net [136.0.16.173])
by mx1.freebsd.org (Postfix) with ESMTP id 753171464
for <freebsd-current@freebsd.org>; Tue, 4 Feb 2014 05:37:50 +0000 (UTC)
Received: by mx.waitman.net (Postfix, from userid 2)
id 7A2F9436A6; Mon, 3 Feb 2014 13:44:48 -0800 (PST)
Received: from 67.170.221.223 by mx.waitman.net with HTTP;
Mon, 3 Feb 2014 13:44:48 -0800
Message-ID: <a1ce5ad0e7c218419b17c8c77111c19e.squirrel@mx.waitman.net>
In-Reply-To: <5266435921866b305d2879c1a11a7057.squirrel@mx.waitman.net>
References: <5266435921866b305d2879c1a11a7057.squirrel@mx.waitman.net>
Date: Mon, 3 Feb 2014 13:44:48 -0800
Subject: Re: question about pkgng
From: "Waitman Gobble" <uzimac@da3m0n8t3r.com>
To: waitman@waitman.net
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: freebsd-current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uzimac@da3m0n8t3r.com
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 05:37:50 -0000
On Sun, February 2, 2014 4:58 pm, Waitman Gobble wrote:
> Hi,
>
>
> I updated my laptop to:
>
>
> # uname -a
> FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Sun Feb 2
> 21:45:49 PST 2014 root@akira.waitman.net:/usr/obj/usr/src/sys/AKIRA
> amd64
>
Scratch this question, it turned out to be faster to just wipe out
/usr/local and start fresh, in this case.
Thanks
--
Waitman Gobble
San Jose California USA
+1.510-830-7975
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 07:39:42 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 30C01A29;
Tue, 4 Feb 2014 07:39:42 +0000 (UTC)
Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 65F091C1F;
Tue, 4 Feb 2014 07:39:40 +0000 (UTC)
Received: by mail-ee0-f41.google.com with SMTP id e51so1935040eek.28
for <multiple recipients>; Mon, 03 Feb 2014 23:39:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=63JPcyGQBiTBLad94svl/IPeP2Dhluug8kcL3MhloBI=;
b=lo4du05u/+Ny5joYVWxyACv33yJ2Lxe/6QE7D4a6cE+JzLAlR8ZuWUyyD4jbIdQjRW
gW7ubPNX9sCSdxN5yjcQBAD9xDMuCsan+gWLZ2r9xuact0kKCG0ralz8OZiKuq9MOAey
mizK1o2LHv5FcChcDhCNM9g+dlcmuNuvDd6CAzItcTf9t582MpI8pYPil4T/D1oDZpCE
5P1TGMe3rFqENKDtn2dxMpa1YY8k3dCsj1LtXbEPfSQiUK+v26vo1vAi0sdm7n45WOnM
GbakhJE2bQKqxW34uHmBCLk/JhOLMDchwDlHQW56qH02dWTWZb1ZJeiEjJni0EUEFJn1
ZTaA==
X-Received: by 10.14.29.6 with SMTP id h6mr1034131eea.84.1391499544433;
Mon, 03 Feb 2014 23:39:04 -0800 (PST)
Received: from mavbook.mavhome.dp.ua ([134.249.139.101])
by mx.google.com with ESMTPSA id m9sm71924582eeh.3.2014.02.03.23.39.02
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 03 Feb 2014 23:39:03 -0800 (PST)
Sender: Alexander Motin <mavbsd@gmail.com>
Message-ID: <52F09914.5040202@FreeBSD.org>
Date: Tue, 04 Feb 2014 09:39:00 +0200
From: Alexander Motin <mav@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Steve Kargl <sgk@troutmask.apl.washington.edu>,
John Baldwin <jhb@freebsd.org>
Subject: Re: Instant panic CAM or USB subsystem
References: <20140125172106.GA67590@troutmask.apl.washington.edu>
<201401281232.21958.jhb@freebsd.org>
<20140128195842.GA83173@troutmask.apl.washington.edu>
In-Reply-To: <20140128195842.GA83173@troutmask.apl.washington.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-current@freebsd.org, scsi@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 07:39:42 -0000
On 28.01.2014 21:58, Steve Kargl wrote:
> On Tue, Jan 28, 2014 at 12:32:21PM -0500, John Baldwin wrote:
>> On Saturday, January 25, 2014 12:21:06 pm Steve Kargl wrote:
>>> If I plug my Samsung Intensity II cellphone into a usb port,
>>> I get an instant panic. This is 100% reproducible. I have
>>> the core and kernel for further debugging. Dmesg.boot follows
>>> my sig.
>>>
>>> % kgdb /boot/kernel/kernel /vmcore.0
>>>
>>> Unread portion of the kernel message buffer:
>>> cd1 at umass-sim1 bus 1 scbus4 target 0 lun 0
>>> cd1: <SAMSUNG CD-ROM 1.00> Removable CD-ROM SCSI-2 device
>>> cd1: Serial Number 000000000002
>>> cd1: 1.000MB/s transfers
>>> cd1: cd present [3840000 x 512 byte records]
>>> cd1: quirks=0x10<10_BYTE_ONLY>
>>> panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301
>>> cpuid = 0
>>> KDB: enter: panic
>>
>> scsi@ might work better for this. It looks like when cdasync() calls
>> cam_periph_alloc() it doesn't have its associated xpt_path locked. All the
>> other async xpt callbacks I looked at don't lock the xpt path either. It
>> seems they expect it to be locked by the caller when they are invoked. It
>> seems xpt_async_process_dev() doesn't always lock xpt_lock, but sometimes
>> locks the device instead:
>>
>> /*
>> * If async for specific device is to be delivered to
>> * the wildcard client, take the specific device lock.
>> * XXX: We may need a way for client to specify it.
>> */
>> if ((device->lun_id == CAM_LUN_WILDCARD &&
>> path->device->lun_id != CAM_LUN_WILDCARD) ||
>> (device->target->target_id == CAM_TARGET_WILDCARD &&
>> path->target->target_id != CAM_TARGET_WILDCARD) ||
>> (device->target->bus->path_id == CAM_BUS_WILDCARD &&
>> path->target->bus->path_id != CAM_BUS_WILDCARD)) {
>> mtx_unlock(&device->device_mtx);
>> xpt_path_lock(path);
>> relock = 1;
>> } else
>> relock = 0;
>>
>> (*(device->target->bus->xport->async))(async_code,
>> device->target->bus, device->target, device, async_arg);
>> xpt_async_bcast(&device->asyncs, async_code, path, async_arg);
>>
>> if (relock) {
>> xpt_path_unlock(path);
>> mtx_lock(&device->device_mtx);
>> }
>>
>> Maybe try going up to this frame (16) in your dump and do
>> 'p *device->target'? However, someone with more CAM knowledge needs to look
>> at this to see what is actually broken.
>>
>> It seems a bit odd that it thinks your phone is a CD player.
>
> Thanks for the follow-up. I poked around a bit, but don't
> recall looking at *device->target. Under Windows, 3
> filesystems show up, and the one causing problems is listed
> as CDFS.
I guess problem may be not that phone is reported as CD, but that it is
reported as several CDs on one target. Note that you already see cd1
reported, but another one was still trying to allocate when system panicked.
I think that CAM CD driver incorrectly assumes that your device is CD
changer. I've pulled real 5-disk SCSI CD changer from my depths of my
table and got panic very much like yours just on boot. It seems that
respective changer code was not properly re-locked during recent CAM
locking project.
I am going to analyze this case deeper to fix in properly, while for
your case I can propose such quick quirk:
--- scsi_cd.c (revision 261448)
+++ scsi_cd.c (working copy)
@@ -223,6 +223,10 @@ static struct cd_quirk_entry cd_quirk_table[] =
{
{ T_CDROM, SIP_MEDIA_REMOVABLE, "CHINON", "CD-ROM
CDS-535","*"},
/* quirks */ CD_Q_BCD_TRACKS
+ },
+ {
+ { T_CDROM, SIP_MEDIA_REMOVABLE, "SAMSUNG", "CD-ROM","1.00"},
+ /* quirks */ CD_Q_NO_CHANGER
}
};
--
Alexander Motin
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 07:41:19 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 289B6CAA;
Tue, 4 Feb 2014 07:41:19 +0000 (UTC)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10])
(using TLSv1 with cipher RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id B709E1C99;
Tue, 4 Feb 2014 07:41:17 +0000 (UTC)
Received: from dynamic.1.17.e8edf383af80.685b35818d2c.afb.bredband2.com
(dynamic.1.17.e8edf383af80.685b35818d2c.afb.bredband2.com [31.208.68.40])
by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis)
id 0MCILJ-1W26Be114j-009C9M; Tue, 04 Feb 2014 08:41:15 +0100
Message-ID: <52F09999.9030807@FreeBSD.org>
Date: Tue, 04 Feb 2014 08:41:13 +0100
From: Christian Brueffer <brueffer@FreeBSD.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: current@freebsd.org
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
References: <52EFA015.5070601@FreeBSD.org>
In-Reply-To: <52EFA015.5070601@FreeBSD.org>
X-Enigmail-Version: 1.6
OpenPGP: id=3A67DC36; url=http://people.freebsd.org/~brueffer/brueffer.key.asc
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="fiVRRWfOLp81fpU4PaJraA20cOanR3h3B"
X-Provags-ID: V02:K0:4gDidNcqFreeTRD6m3FM2wHp0Gsyas26NFq7HbSn1MJ
Y61pwP7o5H/QYS7MFEBKD7upH2Bxoe5XY+HvK4clbAHR3AUW6a
qNZOJpBRjuLqELnHPEBHXdpbm5sWiciso97SoX8LPwKuhx4icN
Kgmpnvd8bkEtBz1GNVzUV5jxl6umWlsZzHd57RCvl4hdwygj73
3m8NGZG4a1UvKaCMiNd7lC56sRk0H0Lrw4c9kofLT9UAWk9g0X
XG1FbYy4VWuNGPy4iOdaCIoEWeudy55NAG5qFZqFoI+2TS5Trp
YlisWVm+hTk5fIOiJbS9rhOsMwcErelMWgijz0t09zf8FK/ib2
geQg7U5TuEV/ZBJnm4bncjBeOnlXq114zGJ2F+s1tnAqE9CVS9
jZterEBDAOZGaQm4IDzSYZN4qOnagYIdPEZURR4OE+CRAqYhzh lJV3D
Cc: stable@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 07:41:19 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fiVRRWfOLp81fpU4PaJraA20cOanR3h3B
Content-Type: multipart/mixed;
boundary="------------040205050306080801060107"
This is a multi-part message in MIME format.
--------------040205050306080801060107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 2/3/14 2:56 PM, Christian Brueffer wrote:
> Hi,
>=20
> for some time now we have had two drivers for NVIDIA NForce/MCP network=
> chips, namely nve(4) and nfe(4).
>=20
> The former came first and is based on a binary blob. The latter was
> later ported from OpenBSD and is blob-free.
>=20
> nfe(4) supports all chips nve(4) supports, in addition to all the newer=
> hardware. In essence, nfe(4) has been the de-facto standard driver for=
> a long time. nve(4) has been commented out in GENERIC since 2007.
>=20
> For this reason I propose deprecating nve(4) in 10-STABLE and removing
> it from HEAD.
>=20
For completeness sake, attached is the proposed patch.
It can also be found here:
http://people.freebsd.org/~brueffer/nve.removal.diff
Cheers,
Christian
--------------040205050306080801060107
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
name="nve.removal.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="nve.removal.diff"
Index: ObsoleteFiles.inc
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- ObsoleteFiles.inc (revision 261434)
+++ ObsoleteFiles.inc (working copy)
@@ -38,6 +38,9 @@
# xargs -n1 | sort | uniq -d;
# done
=20
+# 201302xx: nve(4) replaced by nfe(4)
+OLD_FILES+=3Dusr/share/man/man4/nve.4.gz
+OLD_FILES+=3Dusr/share/man/man4/if_nve.4.gz
# 20140128: libelf and libdwarf import
OLD_LIBS+=3Dusr/lib/libelf.so.1
OLD_LIBS+=3Dusr/lib32/libelf.so.1
Index: release/doc/en_US.ISO8859-1/hardware/article.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- release/doc/en_US.ISO8859-1/hardware/article.xml (revision 261434)
+++ release/doc/en_US.ISO8859-1/hardware/article.xml (working copy)
@@ -883,8 +883,6 @@
=20
&hwlist.nge;
=20
- &hwlist.nve;
-
&hwlist.nxge;
=20
&hwlist.oce;
Index: release/doc/en_US.ISO8859-1/relnotes/article.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- release/doc/en_US.ISO8859-1/relnotes/article.xml (revision 261434)
+++ release/doc/en_US.ISO8859-1/relnotes/article.xml (working copy)
@@ -176,6 +176,11 @@
<para revision=3D"258830">Support for Broadcom chipsets
BCM57764, BCM57767, BCM57782, BCM57786 and BCM57787 has
been added to &man.bge.4;.</para>
+
+ <para revision=3D"2xxxxx">The deprecated nve(4) driver has been
+ removed. Users of NVIDIA nForce MCP network adapters are
+ advised to use the &man.nfe.4; driver instead, which has been
+ the default driver for this hardware since &os; 7.0.</para>
</sect4>
</sect3>
=20
Index: release/doc/share/misc/dev.archlist.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- release/doc/share/misc/dev.archlist.txt (revision 261434)
+++ release/doc/share/misc/dev.archlist.txt (working copy)
@@ -97,7 +97,6 @@
ng_bt3c i386,pc98,amd64
ng_ubt i386,pc98,amd64
nsp i386,pc98
-nve i386,amd64
nxge i386,amd64
oce i386,amd64
ohci i386,pc98,ia64,amd64,powerpc
Index: share/man/man4/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- share/man/man4/Makefile (revision 261434)
+++ share/man/man4/Makefile (working copy)
@@ -343,7 +343,6 @@
${_ntb.4} \
null.4 \
${_nvd.4} \
- ${_nve.4} \
${_nvme.4} \
${_nvram.4} \
${_nvram2env.4} \
@@ -670,7 +669,6 @@
MLINKS+=3Dnge.4 if_nge.4
MLINKS+=3D${_ntb.4} ${_if_ntb.4} \
${_ntb.4} ${_ntb_hw.4}
-MLINKS+=3D${_nve.4} ${_if_nve.4}
MLINKS+=3D${_nxge.4} ${_if_nxge.4}
MLINKS+=3Dpatm.4 if_patm.4
MLINKS+=3Dpccbb.4 cbb.4
@@ -768,7 +766,6 @@
_if_bxe.4=3D if_bxe.4
_if_ndis.4=3D if_ndis.4
_if_nfe.4=3D if_nfe.4
-_if_nve.4=3D if_nve.4
_if_nxge.4=3D if_nxge.4
_if_urtw.4=3D if_urtw.4
_if_vmx.4=3D if_vmx.4
@@ -783,7 +780,6 @@
_nfe.4=3D nfe.4
_nfsmb.4=3D nfsmb.4
_nvd.4=3D nvd.4
-_nve.4=3D nve.4
_nvme.4=3D nvme.4
_nvram.4=3D nvram.4
_nxge.4=3D nxge.4
Index: share/man/man4/altq.4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- share/man/man4/altq.4 (revision 261434)
+++ share/man/man4/altq.4 (working copy)
@@ -151,7 +151,6 @@
.Xr nfe 4 ,
.Xr nge 4 ,
.Xr npe 4 ,
-.Xr nve 4 ,
.Xr qlxgb 4 ,
.Xr ral 4 ,
.Xr re 4 ,
Index: share/man/man4/miibus.4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- share/man/man4/miibus.4 (revision 261434)
+++ share/man/man4/miibus.4 (working copy)
@@ -87,8 +87,6 @@
NVIDIA nForce MCP Networking Adapter
.It Xr nge 4
National Semiconductor DP83820/DP83821 Gigabit Ethernet
-.It Xr nve 4
-NVIDIA nForce MCP Networking Adapter
.It Xr pcn 4
AMD Am79C97x PCI 10/100
.It Xr re 4
@@ -159,7 +157,6 @@
.Xr netintro 4 ,
.Xr nfe 4 ,
.Xr nge 4 ,
-.Xr nve 4 ,
.Xr pcn 4 ,
.Xr re 4 ,
.Xr rgephy 4 ,
Index: share/man/man4/nve.4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- share/man/man4/nve.4 (revision 261434)
+++ share/man/man4/nve.4 (working copy)
@@ -1,141 +0,0 @@
-.\" Copyright (c) 2003 Quinton Dolan
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright=
-.\" notice, this list of conditions and the following disclaimer in t=
he
-.\" documentation and/or other materials provided with the distributi=
on.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' A=
ND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, TH=
E
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR P=
URPOSE
-.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIA=
BLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQU=
ENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GO=
ODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION=
)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, =
STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN AN=
Y WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY =
OF
-.\" SUCH DAMAGE.
-.\"
-.\" $Id: nvnet.4,v 1.1 2003/10/09 16:48:01 q Exp $
-.\"
-.\" $FreeBSD$
-.\"
-.Dd January 16, 2011
-.Dt NVE 4
-.Os
-.Sh NAME
-.Nm nve
-.Nd "NVIDIA nForce MCP Networking Adapter device driver"
-.Sh SYNOPSIS
-To compile this driver into the kernel,
-place the following lines in your
-kernel configuration file:
-.Bd -ragged -offset indent
-.Cd "device miibus"
-.Cd "device nve"
-.Ed
-.Pp
-Alternatively, to load the driver as a
-module at boot time, place the following line in
-.Xr loader.conf 5 :
-.Bd -literal -offset indent
-if_nve_load=3D"YES"
-.Ed
-.Sh DESCRIPTION
-The
-.Nm
-driver provides support for the NVIDIA nForce MCP and nForce2 MCP2
-networking adapter that is embedded in the southbridge of most
-nForce and nForce2 motherboards.
-.Pp
-This driver is a reimplementation of the NVIDIA supported Linux
-.Nm nvnet
-driver and uses the same closed source API library to access
-the underlying hardware.
-There is currently no programming documentation available for this
-device, and therefore little is known about the internal architecture
-of the MAC engine itself.
-.Pp
-The
-.Nm
-driver supports the following media types:
-.Bl -tag -width ".Cm 10baseT/UTP"
-.It Cm autoselect
-Enable autoselection of the media type and options.
-.It Cm 10baseT/UTP
-Set 10Mbps operation.
-.It Cm 100baseTX
-Set 100Mbps (Fast Ethernet) operation.
-.It Cm 1000baseTX
-Set 1000Mbps (Gigabit Ethernet) operation.
-.El
-.Pp
-The
-.Nm
-driver supports the following media options:
-.Bl -tag -width ".Cm 10baseT/UTP"
-.It Cm full-duplex
-Set full duplex operation.
-.El
-.Pp
-For more information on configuring this device, see
-.Xr ifconfig 8 .
-.Sh HARDWARE
-The
-.Nm
-driver supports the NVIDIA MCP onboard adapters of mainboards with
-the following chipsets:
-.Pp
-.Bl -bullet -compact
-.It
-nForce
-.It
-nForce2
-.It
-nForce3
-.It
-nForce4
-.El
-.Sh DIAGNOSTICS
-.Bl -diag
-.It "nve%d: couldn't map memory"
-A fatal initialization error has occurred.
-.It "nve%d: couldn't map interrupt"
-A fatal initialization error has occurred.
-.It "nve%d: failed to allocate memory"
-There are not enough mbufs available for allocation.
-.It "nve%d: device timeout"
-The device has stopped responding to the network, or there is a problem =
with
-the network connection (cable).
-.El
-.Sh SEE ALSO
-.Xr altq 4 ,
-.Xr arp 4 ,
-.Xr miibus 4 ,
-.Xr netintro 4 ,
-.Xr ng_ether 4 ,
-.Xr rgephy 4 ,
-.Xr ifconfig 8
-.Sh HISTORY
-The
-.Nm
-driver first appeared in
-.Fx 6.0 .
-.Sh AUTHORS
-.An -nosplit
-The
-.Nm
-driver was written by
-.An Quinton Dolan Aq q@onthenet.com.au
-and
-.An "David E. O'Brien" Aq obrien@FreeBSD.org .
-.Sh BUGS
-There are reports that when the card is in auto select mode,
-ifconfig output reports a 10baseT/UTP output while the LEDs and
-bandwidth show that the card is actually in 100baseTX mode.
Index: share/man/man4/vlan.4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- share/man/man4/vlan.4 (revision 261434)
+++ share/man/man4/vlan.4 (working copy)
@@ -176,7 +176,6 @@
.Xr hme 4 ,
.Xr le 4 ,
.Xr nfe 4 ,
-.Xr nve 4 ,
.Xr rl 4 ,
.Xr sf 4 ,
.Xr sis 4 ,
Index: sys/amd64/conf/GENERIC
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/amd64/conf/GENERIC (revision 261434)
+++ sys/amd64/conf/GENERIC (working copy)
@@ -235,7 +235,6 @@
device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet
device nfe # nVidia nForce MCP on-board Ethernet
device nge # NatSemi DP83820 gigabit Ethernet
-#device nve # nVidia nForce MCP on-board Ethernet Networking
device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le')
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139
Index: sys/amd64/conf/NOTES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/amd64/conf/NOTES (revision 261434)
+++ sys/amd64/conf/NOTES (working copy)
@@ -309,7 +309,6 @@
# mlxen: Mellanox ConnectX HCA Ethernet
# mthca: Mellanox HCA InfiniBand
# nfe: nVidia nForce MCP on-board Ethernet Networking (BSD open source)
-# nve: nVidia nForce MCP on-board Ethernet Networking
# sfxge: Solarflare SFC9000 family 10Gb Ethernet adapters
# vmx: VMware VMXNET3 Ethernet (BSD open source)
# wpi: Intel 3945ABG Wireless LAN controller
@@ -327,7 +326,6 @@
device mlxen # Mellanox ConnectX HCA Ethernet
device mthca # Mellanox HCA InfiniBand
device nfe # nVidia nForce MCP on-board Ethernet
-device nve # nVidia nForce MCP on-board Ethernet Networking
device sfxge # Solarflare SFC9000 10Gb Ethernet
device vmx # VMware VMXNET3 Ethernet
device wpi # Intel 3945ABG wireless NICs.
Index: sys/boot/forth/loader.conf
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/boot/forth/loader.conf (revision 261434)
+++ sys/boot/forth/loader.conf (working copy)
@@ -327,7 +327,6 @@
if_my_load=3D"NO" # Myson PCI Fast Ethernet
if_nfe_load=3D"NO" # NVIDIA nForce MCP Networking Adapter
if_nge_load=3D"NO" # National Semiconductor PCI Gigabit Ethernet
-if_nve_load=3D"NO" # NVIDIA nForce MCP Networking Adapter
if_nxge_load=3D"NO" # Neterion Xframe 10Gb Ethernet
if_patm_load=3D"NO" # IDT77252 ATM
if_pcn_load=3D"NO" # AMD PCnet PCI
Index: sys/conf/WITHOUT_SOURCELESS_HOST
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/conf/WITHOUT_SOURCELESS_HOST (revision 261434)
+++ sys/conf/WITHOUT_SOURCELESS_HOST (working copy)
@@ -8,4 +8,3 @@
nodevice hptmv
nodevice hptnr
nodevice hptrr
-nodevice nve
Index: sys/conf/files.amd64
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/conf/files.amd64 (revision 261434)
+++ sys/conf/files.amd64 (working copy)
@@ -47,17 +47,6 @@
no-obj no-implicit-rule before-depend \
clean "ukbdmap.h"
#
-nvenetlib.o optional nve pci \
- dependency "$S/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu" \
- compile-with "uudecode $S/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu ; bz=
ip2 -df nvenetlib.o.bz2" \
- no-implicit-rule
-#
-os+%DIKED-nve.h optional nve pci \
- dependency "$S/contrib/dev/nve/os.h" \
- compile-with "sed -e 's/^.*#include.*phy\.h.*$$//' $S/contrib/dev/nve/o=
s.h > os+%DIKED-nve.h" \
- no-implicit-rule no-obj before-depend \
- clean "os+%DIKED-nve.h"
-#
hpt27xx_lib.o optional hpt27xx \
dependency "$S/dev/hpt27xx/amd64-elf.hpt27xx_lib.o.uu" \
compile-with "uudecode < $S/dev/hpt27xx/amd64-elf.hpt27xx_lib.o.uu" \
@@ -248,7 +237,6 @@
dev/ntb/if_ntb/if_ntb.c optional if_ntb
dev/ntb/ntb_hw/ntb_hw.c optional if_ntb ntb_hw
dev/nvd/nvd.c optional nvd nvme
-dev/nve/if_nve.c optional nve pci
dev/nvme/nvme.c optional nvme
dev/nvme/nvme_ctrlr.c optional nvme
dev/nvme/nvme_ctrlr_cmd.c optional nvme
Index: sys/conf/files.i386
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/conf/files.i386 (revision 261434)
+++ sys/conf/files.i386 (working copy)
@@ -46,17 +46,6 @@
no-obj no-implicit-rule before-depend \
clean "ukbdmap.h"
#
-nvenetlib.o optional nve pci \
- dependency "$S/contrib/dev/nve/i386/nvenetlib.o.bz2.uu" \
- compile-with "uudecode $S/contrib/dev/nve/i386/nvenetlib.o.bz2.uu ; bzi=
p2 -df nvenetlib.o.bz2" \
- no-implicit-rule
-#
-os+%DIKED-nve.h optional nve pci \
- dependency "$S/contrib/dev/nve/os.h" \
- compile-with "sed -e 's/^.*#include.*phy\.h.*$$//' $S/contrib/dev/nve/o=
s.h > os+%DIKED-nve.h" \
- no-implicit-rule no-obj before-depend \
- clean "os+%DIKED-nve.h"
-#
hpt27xx_lib.o optional hpt27xx \
dependency "$S/dev/hpt27xx/i386-elf.hpt27xx_lib.o.uu" \
compile-with "uudecode < $S/dev/hpt27xx/i386-elf.hpt27xx_lib.o.uu" \
@@ -257,7 +246,6 @@
dev/mse/mse_isa.c optional mse isa
dev/nfe/if_nfe.c optional nfe pci
dev/nvd/nvd.c optional nvd nvme
-dev/nve/if_nve.c optional nve pci
dev/nvme/nvme.c optional nvme
dev/nvme/nvme_ctrlr.c optional nvme
dev/nvme/nvme_ctrlr_cmd.c optional nvme
Index: sys/contrib/dev/nve/adapter.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/adapter.h (revision 261434)
+++ sys/contrib/dev/nve/adapter.h (working copy)
@@ -1,583 +0,0 @@
-/***********************************************************************=
****\
-|* =
*|
-|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL=
*|
-|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY=
*|
-|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT =
*|
-|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED =
*|
-|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A=
*|
-|* PARTICULAR PURPOSE. =
*|
-|* =
*|
-\***********************************************************************=
****/=20
-
-/*
- FILE: adapter.h
- DATE: 2/7/00
-
- This file contains the hardware interface to the ethernet adapter.
-*/
-
-#ifndef _ADAPTER_H_
-#define _ADAPTER_H_
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-#define HDA_VERSION_STRING "HDR A: $Revision: #46 $"
-
-#ifdef MODS_NETWORK_BUILD
-#ifndef _DRVAPP_H_
-#include "drvapp.h"
-#endif
-#endif
-
-//////////////////////////////////////////////////////////////////
-// For the set and get configuration calls.
-typedef struct _ADAPTER_CONFIG
-{
- NV_UINT32 ulFlags;
-} ADAPTER_CONFIG, *PADAPTER_CONFIG;
-//////////////////////////////////////////////////////////////////
-
-typedef struct _ADAPTER_WRITE_OFFLOAD
-{
- NV_UINT32 usBitmask;
- NV_UINT32 ulMss;
-
-} ADAPTER_WRITE_OFFLOAD;
-
-//////////////////////////////////////////////////////////////////
-// For the ADAPTER_Write1 call.
-/* This scatter gather list should be same as defined in ndis.h by MS.
- For ULONG_PTR MS header file says that it will be of same size as
- pointer. It has been defined to take care of casting between differen=
et
- sizes.
-*/
-typedef struct _NVSCATTER_GATHER_ELEMENT {
- NV_UINT32 PhysLow;
- NV_UINT32 PhysHigh;
- NV_UINT32 Length;
- NV_VOID *Reserved;
-} NVSCATTER_GATHER_ELEMENT, *PNVSCATTER_GATHER_ELEMENT;
-
-#ifndef linux
-#pragma warning(disable:4200)
-#endif
-typedef struct _NVSCATTER_GATHER_LIST {
- NV_UINT32 NumberOfElements;
- NV_VOID *Reserved;
- NVSCATTER_GATHER_ELEMENT Elements[0]; // Made 0 sized element to r=
emove MODS compilation error
- // Elements[0] and Elements[=
] have the same effect.=20
- // sizeof(NVSCATTER_GATHER_L=
IST) is the same (value of 8) in both cases
- // And both lead to Warning =
4200 in MSVC
-} NVSCATTER_GATHER_LIST, *PNVSCATTER_GATHER_LIST;
-#ifndef linux
-#pragma warning(default:4200)
-#endif
-
-typedef struct _ADAPTER_WRITE_DATA1
-{
- NV_UINT32 ulTotalLength;
- PNV_VOID pvID;
- NV_UINT8 uc8021pPriority;
- ADAPTER_WRITE_OFFLOAD *psOffload;
- PNVSCATTER_GATHER_LIST pNVSGL;
-} ADAPTER_WRITE_DATA1, *PADAPTER_WRITE_DATA1;
-
-
-//////////////////////////////////////////////////////////////////
-// For the ADAPTER_Write call.
-typedef struct _ADAPTER_WRITE_ELEMENT
-{
- PNV_VOID pPhysical;
- NV_UINT32 ulLength;
-} ADAPTER_WRITE_ELEMENT, *PADAPTER_WRITE_ELEMENT;
-
-
-#define ADAPTER_WRITE_OFFLOAD_BP_SEGOFFLOAD 0
-#define ADAPTER_WRITE_OFFLOAD_BP_IPV4CHECKSUM 1
-#define ADAPTER_WRITE_OFFLOAD_BP_IPV6CHECKSUM 2
-#define ADAPTER_WRITE_OFFLOAD_BP_TCPCHECKSUM 3
-#define ADAPTER_WRITE_OFFLOAD_BP_UDPCHECKSUM 4
-#define ADAPTER_WRITE_OFFLOAD_BP_IPCHECKSUM 5
-
-
-// pvID is a value that will be passed back into OSAPI.pfnPacketWasSent
-// when the transmission completes. if pvID is NULL, the ADAPTER code
-// assumes the caller does not want the pfnPacketWasSent callback.
-typedef struct _ADAPTER_WRITE_DATA
-{
- NV_UINT32 ulNumberOfElements;
- NV_UINT32 ulTotalLength;
- PNV_VOID pvID;
- NV_UINT8 uc8021pPriority;
- ADAPTER_WRITE_OFFLOAD *psOffload;
-#ifdef linux
- ADAPTER_WRITE_ELEMENT sElement[32];
-#else
- ADAPTER_WRITE_ELEMENT sElement[100];
-#endif
-} ADAPTER_WRITE_DATA, *PADAPTER_WRITE_DATA;
-//////////////////////////////////////////////////////////////////
-
-
-
-//////////////////////////////////////////////////////////////////
-// For the ADAPTER_Read call.
-typedef struct _ADAPTER_READ_ELEMENT
-{
- PNV_VOID pPhysical;
- NV_UINT32 ulLength;
-} ADAPTER_READ_ELEMENT, *PADAPTER_READ_ELEMENT;
-
-typedef struct _ADAPTER_READ_OFFLOAD
-{
- NV_UINT8 ucChecksumStatus;
-
-} ADAPTER_READ_OFFLOAD;
-
-typedef struct _ADAPTER_READ_DATA
-{
- NV_UINT32 ulNumberOfElements;
- NV_UINT32 ulTotalLength;
- PNV_VOID pvID;
- NV_UINT32 ulFilterMatch;
- ADAPTER_READ_OFFLOAD sOffload;
- ADAPTER_READ_ELEMENT sElement[10];
-} ADAPTER_READ_DATA, *PADAPTER_READ_DATA;
-
-
-#define RDFLAG_CHK_NOCHECKSUM 0
-#define RDFLAG_CHK_IPPASSTCPFAIL 1
-#define RDFLAG_CHK_IPPASSUDPFAIL 2
-#define RDFLAG_CHK_IPFAIL 3
-#define RDFLAG_CHK_IPPASSNOTCPUDP 4
-#define RDFLAG_CHK_IPPASSTCPPASS 5
-#define RDFLAG_CHK_IPPASSUDPPASS 6
-#define RDFLAG_CHK_RESERVED 7
-
-
-// The ulFilterMatch flag can be a logical OR of the following
-#define ADREADFL_UNICAST_MATCH 0x00000001
-#define ADREADFL_MULTICAST_MATCH 0x00000002
-#define ADREADFL_BROADCAST_MATCH 0x00000004
-//////////////////////////////////////////////////////////////////
-
-
-
-//////////////////////////////////////////////////////////////////
-// For the ADAPTER_GetPowerCapabilities call.
-typedef struct _ADAPTER_POWERCAPS
-{
- NV_UINT32 ulPowerFlags;
- NV_UINT32 ulMagicPacketWakeUpFlags;
- NV_UINT32 ulPatternWakeUpFlags;
- NV_UINT32 ulLinkChangeWakeUpFlags;
- NV_SINT32 iMaxWakeUpPatterns;
-} ADAPTER_POWERCAPS, *PADAPTER_POWERCAPS;
-
-// For the ADAPTER_GetPowerState and ADAPTER_SetPowerState call.
-typedef struct _ADAPTER_POWERSTATE
-{
- NV_UINT32 ulPowerFlags;
- NV_UINT32 ulMagicPacketWakeUpFlags;
- NV_UINT32 ulPatternWakeUpFlags;
- NV_UINT32 ulLinkChangeWakeUpFlags;
-} ADAPTER_POWERSTATE, *PADAPTER_POWERSTATE;
-
-// Each of the flag fields in the POWERCAPS structure above can have
-// any of the following bitflags set giving the capabilites of the
-// adapter. In the case of the wake up fields, these flags mean that
-// wake up can happen from the specified power state.
-
-// For the POWERSTATE structure, the ulPowerFlags field should just
-// have one of these bits set to go to that particular power state.
-// The WakeUp fields can have one or more of these bits set to indicate
-// what states should be woken up from.
-#define POWER_STATE_D0 0x00000001
-#define POWER_STATE_D1 0x00000002
-#define POWER_STATE_D2 0x00000004
-#define POWER_STATE_D3 0x00000008
-
-#define POWER_STATE_ALL (POWER_STATE_D0 | \
- POWER_STATE_D1 | \
- POWER_STATE_D2 | \
- POWER_STATE_D3)
-//////////////////////////////////////////////////////////////////
-
-
-
-//////////////////////////////////////////////////////////////////
-// The ADAPTER_GetPacketFilterCaps call returns a NV_UINT32 that can
-// have the following capability bits set.
-#define ACCEPT_UNICAST_PACKETS 0x00000001
-#define ACCEPT_MULTICAST_PACKETS 0x00000002
-#define ACCEPT_BROADCAST_PACKETS 0x00000004
-#define ACCEPT_ALL_PACKETS 0x00000008
-
-#define ETH_LENGTH_OF_ADDRESS 6
-
-// The ADAPTER_SetPacketFilter call uses this structure to know what
-// packet filter to set. The ulPacketFilter field can contain some
-// union of the bit flags above. The acMulticastMask array holds a
-// 48 bit MAC address mask with a 0 in every bit position that should
-// be ignored on compare and a 1 in every bit position that should
-// be taken into account when comparing to see if the destination
-// address of a packet should be accepted for multicast.
-typedef struct _PACKET_FILTER
-{
- NV_UINT32 ulFilterFlags;
- NV_UINT8 acMulticastAddress[ETH_LENGTH_OF_ADDRESS];
- NV_UINT8 acMulticastMask[ETH_LENGTH_OF_ADDRESS];
-} PACKET_FILTER, *PPACKET_FILTER;
-//////////////////////////////////////////////////////////////////
-
-
-//////////////////////////////////////////////////////////////////
-// A WAKE_UP_PATTERN is a 128-byte pattern that the adapter can
-// look for in incoming packets to decide when to wake up. Higher-
-// level protocols can use this to, for example, wake up the
-// adapter whenever it sees an IP packet that is addressed to it.
-// A pattern consists of 128 bits of byte masks that indicate
-// which bytes in the packet are relevant to the pattern, plus
-// values for each byte.
-#define WAKE_UP_PATTERN_SIZE 128
-
-typedef struct _WAKE_UP_PATTERN
-{
- NV_UINT32 aulByteMask[WAKE_UP_PATTERN_SIZE/32];
- NV_UINT8 acData[WAKE_UP_PATTERN_SIZE];
-} WAKE_UP_PATTERN, *PWAKE_UP_PATTERN;
-
-
-
-//
-//
-// Adapter offload
-//
-typedef struct _ADAPTER_OFFLOAD {
-
- NV_UINT32 Type;
- NV_UINT32 Value0;
-
-} ADAPTER_OFFLOAD, *PADAPTER_OFFLOAD;
-
-#define ADAPTER_OFFLOAD_VLAN 0x00000001
-#define ADAPTER_OFFLOAD_IEEE802_1P 0x00000002
-#define ADAPTER_OFFLOAD_IEEE802_1PQ_PAD 0x00000004
-
-//////////////////////////////////////////////////////////////////
-
-// CMNDATA_OS_ADAPTER
-// Structure common to OS and Adapter layers
-// Used for moving data from the OS layer to the adapter layer through =
SetCommonData=20
-// function call from OS layer to Adapter layer
-//=20
-
-typedef struct _CMNDATA_OS_ADAPTER
-{
-#ifndef linux
- ASF_SEC0_BASE sRegSec0Base;
-#endif
- NV_UINT32 bFPGA;=20
- NV_UINT32 ulFPGAEepromSize;
- NV_UINT32 bChecksumOffloadEnable;
- NV_UINT32 ulChecksumOffloadBM;
- NV_UINT32 ulChecksumOffloadOS;
- NV_UINT32 ulMediaIF;
- NV_UINT32 bOemCustomEventRead;
-
- // Debug only right now
- //!!! Beware mods is relying on the fields blow.
- NV_UINT32 ulWatermarkTFBW;
- NV_UINT32 ulBackoffRseed;
- NV_UINT32 ulBackoffSlotTime;
- NV_UINT32 ulModeRegTxReadCompleteEnable;
- NV_UINT32 ulFatalErrorRegister;
-
-} CMNDATA_OS_ADAPTER;
-
-
-//////////////////////////////////////////////////////////////////
-// The functional typedefs for the ADAPTER Api
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_CLOSE) (PNV_VOID pvContext=
, NV_UINT8 ucIsPowerDown);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_INIT) (PNV_VOID pvContext,=
NV_UINT16 usForcedSpeed, NV_UINT8 ucForceDpx, NV_UINT8 ucForceMode, NV_U=
INT8 ucAsyncMode, NV_UINT32 *puiLinkState);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_DEINIT) (PNV_VOID pvContex=
t, NV_UINT8 ucIsPowerDown);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_START) (PNV_VOID pvContext=
);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_STOP) (PNV_VOID pvContext=
, NV_UINT8 ucIsPowerDown);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_QUERY_WRITE_SLOTS) (PNV_VOI=
D pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_WRITE) (PNV_VOID pvContext,=
ADAPTER_WRITE_DATA *pADWriteData);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_WRITE1) (PNV_VOID pvContext=
, ADAPTER_WRITE_DATA1 *pADWriteData1);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_QUERY_INTERRUPT) (PNV_VOID =
pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_HANDLE_INTERRUPT) (PNV_VOID=
pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_DISABLE_INTERRUPTS) (PNV_VO=
ID pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_ENABLE_INTERRUPTS) (PNV_VOI=
D pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_CLEAR_INTERRUPTS) (PNV_VOID=
pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_CLEAR_TX_DESC) (PNV_VOID pv=
Context);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_LINK_SPEED) (PNV_VOID p=
vContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_LINK_MODE) (PNV_VOID pv=
Context);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_LINK_STATE) (PNV_VOID p=
vContext, NV_UINT32 *pulLinkState);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_IS_LINK_INITIALIZING) (PNV_=
VOID pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_RESET_PHY_INIT_STATE) (PNV_=
VOID pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_TRANSMIT_QUEUE_SIZE) (P=
NV_VOID pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_RECEIVE_QUEUE_SIZE) (PN=
V_VOID pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_STATISTICS) (PNV_VOID p=
vContext, PADAPTER_STATS pADStats);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_POWER_CAPS) (PNV_VOID p=
vContext, PADAPTER_POWERCAPS pADPowerCaps);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_POWER_STATE) (PNV_VOID =
pvContext, PADAPTER_POWERSTATE pADPowerState);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_POWER_STATE) (PNV_VOID =
pvContext, PADAPTER_POWERSTATE pADPowerState);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_LOW_SPEED_FOR_PM) (PNV_=
VOID pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_PACKET_FILTER_CAPS) (PN=
V_VOID pvContext);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_PACKET_FILTER) (PNV_VOI=
D pvContext, PPACKET_FILTER pPacketFilter);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_WAKE_UP_PATTERN) (PNV_V=
OID pvContext, NV_SINT32 iPattern, PWAKE_UP_PATTERN pPattern);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_ENABLE_WAKE_UP_PATTERN) (PN=
V_VOID pvContext, NV_SINT32 iPattern, NV_SINT32 iEnable);
-typedef NV_API_CALL NV_SINT32 (* PFN_SET_NODE_ADDRESS) (PNV_VOID pvConte=
xt, NV_UINT8 *pNodeAddress);
-typedef NV_API_CALL NV_SINT32 (* PFN_GET_NODE_ADDRESS) (PNV_VOID pvConte=
xt, NV_UINT8 *pNodeAddress);
-typedef NV_API_CALL NV_SINT32 (* PFN_GET_ADAPTER_INFO) (PNV_VOID pvConte=
xt, PNV_VOID pVoidPtr, NV_SINT32 iType, NV_SINT32 *piLength);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_READ_PHY) (PNV_VOID pvCont=
ext, NV_UINT32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 *pulValue);
-typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_WRITE_PHY) (PNV_VOID pvCont=
ext, NV_UINT32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 ulValue);
-typedef NV_API_CALL NV_VOID(* PFN_ADAPTER_SET_SPPED_DUPLEX) (PNV_VOID pv=
Context);
-typedef NV_API_CALL NV_SINT32 (*PFN_REGISTER_OFFLOAD) (PNV_VOID pvContex=
t, PADAPTER_OFFLOAD pOffload);
-typedef NV_API_CALL NV_SINT32 (*PFN_DEREGISTER_OFFLOAD) (PNV_VOID pvCont=
ext, PADAPTER_OFFLOAD pOffload);
-typedef NV_API_CALL NV_SINT32 (*PFN_RX_BUFF_READY) (PNV_VOID pvContext, =
PMEMORY_BLOCK pMemBlock, PNV_VOID pvID);
-
-#ifndef linux
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETUPREGISTERS) (PNV_VOID pvContext,=
NV_SINT32 bInitTime);
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_GETSEC0BASEADDRESS) (PNV_VOID pvCont=
ext, ASF_SEC0_BASE **ppsSec0Base);
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETSOURCEIPADDRESS) (PNV_VOID pvCont=
ext, NV_UINT8 *pucSrcIPAddress);
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_GETDESTIPADDRESS) (PNV_VOID pvContex=
t, NV_UINT8 *pucDestIPAddress);
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETDESTIPADDRESS) (PNV_VOID pvContex=
t, NV_UINT8 *pucDestIPAddress);
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_WRITEEEPROMANDSETUPREGISTERS) (PNV_V=
OID pvContext, NV_BOOLEAN bCompare, PNV_VOID pucValue, PNV_VOID pszSec0Ba=
seMember,=20
- NV_UINT16 usCount, NV_UINT32 ulAdd=
ressOffset);
-
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_ISASFREADY) (PNV_VOID pvContext, ASF=
_ASFREADY *psASFReady);
-
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETDESTMACADDRESS) (PNV_VOID pvConte=
xt, NV_UINT8 *pucDestMACAddress);
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_GETSOURCEMACADDRESS) (PNV_VOID pvCon=
text, NV_UINT8 *pucSrcMACAddress);
-
-typedef NV_SINT32 (*PFN_ADAPTER_ASF_CHECK_FOR_EEPROM_PRESENCE) (PNV_VOI=
D pvContext);
-#endif
-
-typedef NV_API_CALL NV_VOID (*PFN_ADAPTER_SET_COMMONDATA) (PNV_VOID pvCo=
ntext, CMNDATA_OS_ADAPTER *psOSAdpater);
-typedef NV_API_CALL NV_VOID (*PFN_ADAPTER_SET_CHECKSUMOFFLOAD) (PNV_VOID=
pvContext, NV_UINT32 bSet);
-
-
-=20
-typedef struct _ADAPTER_API
-{
- // The adapter context
- PNV_VOID pADCX;
-
- // The adapter interface
- PFN_ADAPTER_CLOSE pfnClose;
- PFN_ADAPTER_INIT pfnInit;
- PFN_ADAPTER_DEINIT pfnDeinit;
- PFN_ADAPTER_START pfnStart;
- PFN_ADAPTER_STOP pfnStop;
- PFN_ADAPTER_QUERY_WRITE_SLOTS pfnQueryWriteSlots;
- PFN_ADAPTER_WRITE pfnWrite;
- PFN_ADAPTER_WRITE1 pfnWrite1;
- PFN_ADAPTER_QUERY_INTERRUPT pfnQueryInterrupt;
- PFN_ADAPTER_HANDLE_INTERRUPT pfnHandleInterrupt;
- PFN_ADAPTER_DISABLE_INTERRUPTS pfnDisableInterrupts;
- PFN_ADAPTER_ENABLE_INTERRUPTS pfnEnableInterrupts;
- PFN_ADAPTER_CLEAR_INTERRUPTS pfnClearInterrupts;
- PFN_ADAPTER_CLEAR_TX_DESC pfnClearTxDesc;
- PFN_ADAPTER_GET_LINK_SPEED pfnGetLinkSpeed;
- PFN_ADAPTER_GET_LINK_MODE pfnGetLinkMode;
- PFN_ADAPTER_GET_LINK_STATE pfnGetLinkState;
- PFN_ADAPTER_IS_LINK_INITIALIZING pfnIsLinkInitializing;
- PFN_ADAPTER_RESET_PHY_INIT_STATE pfnResetPhyInitState;
- PFN_ADAPTER_GET_TRANSMIT_QUEUE_SIZE pfnGetTransmitQueueSize;
- PFN_ADAPTER_GET_RECEIVE_QUEUE_SIZE pfnGetReceiveQueueSize;
- PFN_ADAPTER_GET_STATISTICS pfnGetStatistics;
- PFN_ADAPTER_GET_POWER_CAPS pfnGetPowerCaps;
- PFN_ADAPTER_GET_POWER_STATE pfnGetPowerState;
- PFN_ADAPTER_SET_POWER_STATE pfnSetPowerState;
- PFN_ADAPTER_SET_LOW_SPEED_FOR_PM pfnSetLowSpeedForPM;
- PFN_ADAPTER_GET_PACKET_FILTER_CAPS pfnGetPacketFilterCaps;
- PFN_ADAPTER_SET_PACKET_FILTER pfnSetPacketFilter;
- PFN_ADAPTER_SET_WAKE_UP_PATTERN pfnSetWakeUpPattern;
- PFN_ADAPTER_ENABLE_WAKE_UP_PATTERN pfnEnableWakeUpPattern;
- PFN_SET_NODE_ADDRESS pfnSetNodeAddress;
- PFN_GET_NODE_ADDRESS pfnGetNodeAddress;
- PFN_GET_ADAPTER_INFO pfnGetAdapterInfo;
- PFN_ADAPTER_SET_SPPED_DUPLEX pfnSetSpeedDuplex;
- PFN_ADAPTER_READ_PHY pfnReadPhy;
- PFN_ADAPTER_WRITE_PHY pfnWritePhy;
- PFN_REGISTER_OFFLOAD pfnRegisterOffload;
- PFN_DEREGISTER_OFFLOAD pfnDeRegisterOffload;
- PFN_RX_BUFF_READY pfnRxBuffReady;
-#ifndef linux
- PFN_ADAPTER_ASF_SETUPREGISTERS pfnASFSetupRegisters;
- PFN_ADAPTER_ASF_GETSEC0BASEADDRESS pfnASFGetSec0BaseAddress;
- PFN_ADAPTER_ASF_SETSOURCEIPADDRESS pfnASFSetSourceIPAddress;
- PFN_ADAPTER_ASF_GETDESTIPADDRESS pfnASFGetDestIPAddress;
- PFN_ADAPTER_ASF_SETDESTIPADDRESS pfnASFSetDestIPAddress;
- PFN_ADAPTER_ASF_WRITEEEPROMANDSETUPREGISTERS pfnASFWriteEEPROMAndSet=
upRegisters;
- PFN_ADAPTER_ASF_SETDESTMACADDRESS pfnASFSetDestMACAddress;
- PFN_ADAPTER_ASF_GETSOURCEMACADDRESS pfnASFGetSourceMACAddress;
- PFN_ADAPTER_ASF_ISASFREADY pfnASFIsASFReady;
- PFN_ADAPTER_ASF_CHECK_FOR_EEPROM_PRESENCE pfnASFCheckForEepromPresen=
ce;
-#endif
- PFN_ADAPTER_SET_COMMONDATA pfnSetCommonData;
-
- PFN_ADAPTER_SET_CHECKSUMOFFLOAD pfnSetChecksumOffload;
-
-} ADAPTER_API, *PADAPTER_API;
-//////////////////////////////////////////////////////////////////
-
-#define MAX_PACKET_TO_ACCUMULATE 16
-
-typedef struct _ADAPTER_OPEN_PARAMS
-{
- PNV_VOID pOSApi; //pointer to OSAPI structure passed from higher lay=
er
- PNV_VOID pvHardwareBaseAddress; //memory mapped address passed from =
higher layer
- NV_UINT32 ulPollInterval; //poll interval in micro seconds. Used in =
polling mode
- NV_UINT32 MaxDpcLoop; //Maximum number of times we loop to in functi=
on ADAPTER_HandleInterrupt
- NV_UINT32 MaxRxPkt; //Maximum number of packet we process each time =
in function UpdateReceiveDescRingData
- NV_UINT32 MaxTxPkt; //Maximum number of packet we process each time =
in function UpdateTransmitDescRingData
- NV_UINT32 MaxRxPktToAccumulate; //maximum number of rx packet we acc=
umulate in UpdateReceiveDescRingData before
- //indicating packets to OS.
- NV_UINT32 SentPacketStatusSuccess; //Status returned from adapter la=
yer to higher layer when packet was sent successfully
- NV_UINT32 SentPacketStatusFailure; ////Status returned from adapter =
layer to higher layer when packet send was unsuccessful
- NV_UINT32 SetForcedModeEveryNthRxPacket; //NOT USED: For experiment =
with descriptor based interrupt
- NV_UINT32 SetForcedModeEveryNthTxPacket; //NOT USED: For experiment =
with descriptor based interrupt
- NV_UINT32 RxForcedInterrupt; //NOT USED: For experiment with descrip=
tor based interrupt
- NV_UINT32 TxForcedInterrupt; //NOT USED: For experiment with descrip=
tor based interrupt
- NV_UINT32 DeviceId; //Of MAC
- NV_UINT32 DeviceType;
- NV_UINT32 PollIntervalInusForThroughputMode; //Of MAC
- NV_UINT32 bASFEnabled;
- NV_UINT32 ulDescriptorVersion;
- NV_UINT32 ulMaxPacketSize;
-
-
-#define MEDIA_IF_AUTO 0
-#define MEDIA_IF_RGMII 1
-#define MEDIA_IF_MII 2
- NV_UINT32 ulMediaIF;
-
- NV_UINT32 PhyPowerIsolationTimeoutInms;
- NV_UINT32 PhyResetTimeoutInms;
- NV_UINT32 PhyAutonegotiateTimeoutInms;
- NV_UINT32 PhyLinkupTimeoutInms;
- NV_UINT32 PhyRdWrTimeoutInus;
- NV_UINT32 PhyPowerdownOnClose;
-
- // Added for Bug 100715
- NV_UINT32 bDisableMIIInterruptAndReadPhyStatus;
-
-}ADAPTER_OPEN_PARAMS, *PADAPTER_OPEN_PARAMS;
-
-//////////////////////////////////////////////////////////////////
-// This is the one function in the adapter interface that is publicly
-// available. The rest of the interface is returned in the pAdapterApi.
-// The first argument needs to be cast to a OSAPI structure pointer.
-// The second argument should be cast to a ADPATER_API structure pointer=
=2E
-NV_API_CALL NV_SINT32 ADAPTER_Open (PADAPTER_OPEN_PARAMS pAdapterOpenPar=
ams, PNV_VOID *pvpAdapterApi, NV_UINT32 *pulPhyAddr);
-
-//////////////////////////////////////////////////////////////////
-
-
-
-//////////////////////////////////////////////////////////////////
-// Here are the error codes the adapter function calls return.
-#define ADAPTERERR_NONE 0x0000
-#define ADAPTERERR_COULD_NOT_ALLOC_CONTEXT 0x0001
-#define ADAPTERERR_COULD_NOT_CREATE_CONTEXT 0x0002
-#define ADAPTERERR_COULD_NOT_OPEN_PHY 0x0003
-#define ADAPTERERR_TRANSMIT_QUEUE_FULL 0x0004
-#define ADAPTERERR_COULD_NOT_INIT_PHY 0x0005
-#define ADAPTERERR_PHYS_SIZE_SMALL 0x0006
-#define ADAPTERERR_ERROR 0x0007 // Generic e=
rror
-//////////////////////////////////////////////////////////////////
-
-// This block moved from myadap.h
-// nFlag for Stop/Start ReceiverAndOrTransmitter can be an OR of
-// the following two flags
-#define AFFECT_RECEIVER 0x01
-#define AFFECT_TRANSMITTER 0x02
-
-#define REDUCE_LENGTH_BY 48
-
-#define EXTRA_WRITE_SLOT_TO_REDUCE_PER_SEND 4
-#define MAX_TX_DESCS 256=20
-#define MAX_TX_DESCS_VER2 (256 * 4)
-
-typedef struct _TX_INFO_ADAP
-{
- NV_UINT32 NoOfDesc;=20
- PNV_VOID pvVar2;=20
-}TX_INFO_ADAP, *PTX_INFO_ADAP;
-
-#define WORKAROUND_FOR_MCP3_TX_STALL
-
-#ifdef WORKAROUND_FOR_MCP3_TX_STALL
-NV_SINT32 ADAPTER_WorkaroundTXHang(PNV_VOID pvContext);
-#endif
-
-//#define TRACK_INIT_TIME
-
-#ifdef TRACK_INIT_TIME
-//This routine is defined in entry.c adapter doesn't link int64.lib
-//We defined here so that its easy to use it in phy as well as mswin
-
-#define MAX_PRINT_INDEX 32
-extern NV_VOID PrintTime(NV_UINT32 ulIndex);
-#define PRINT_INIT_TIME(_a) PrintTime((_a))
-#else
-#define PRINT_INIT_TIME(_a)
-#endif
-
-// Segmentation offload info
-#define DEVCAPS_SEGOL_BP_ENABLE 0 =20
-#define DEVCAPS_SEGOL_BP_IPOPTIONS 1
-#define DEVCAPS_SEGOL_BP_TCPOPTIONS 2
-#define DEVCAPS_SEGOL_BP_SEGSIZE_LO 8
-#define DEVCAPS_SEGOL_BP_SEGSIZE_HI 31
-
-
-// Checksum offload info
-// Byte 0 : V4 TX
-#define DEVCAPS_V4_TX_BP_IPOPTIONS 0
-#define DEVCAPS_V4_TX_BP_TCPOPTIONS 1
-#define DEVCAPS_V4_TX_BP_TCPCHECKSUM 2
-#define DEVCAPS_V4_TX_BP_UDPCHECKSUM 3
-#define DEVCAPS_V4_TX_BP_IPCHECKSUM 4
-
-// Byte 0 : V4 RX
-#define DEVCAPS_V4_RX_BP_IPOPTIONS 8
-#define DEVCAPS_V4_RX_BP_TCPOPTIONS 9
-#define DEVCAPS_V4_RX_BP_TCPCHECKSUM 10
-#define DEVCAPS_V4_RX_BP_UDPCHECKSUM 11
-#define DEVCAPS_V4_RX_BP_IPCHECKSUM 12
-
-// Byte 1 : V6 TX
-#define DEVCAPS_V6_TX_BP_IPOPTIONS 16
-#define DEVCAPS_V6_TX_BP_TCPOPTIONS 17
-#define DEVCAPS_V6_TX_BP_TCPCHECKSUM 18
-#define DEVCAPS_V6_TX_BP_UDPCHECKSUM 19
-
-// Byte 2 : V6 RX
-#define DEVCAPS_V6_RX_BP_IPOPTIONS 24
-#define DEVCAPS_V6_RX_BP_TCPOPTIONS 25
-#define DEVCAPS_V6_RX_BP_TCPCHECKSUM 26
-#define DEVCAPS_V6_RX_BP_UDPCHECKSUM 27
-
-
-#define DESCR_VER_1 1 // MCP1, MCP2 and CK8 descriptor ver=
sion
-#define DESCR_VER_2 2 // The decsriptor structure for CK8G=
-
-// Get device and vendor IDs from 32 bit DeviceVendorID=20
-#define GET_DEVICEID(x) (((x) >> 16) & 0xFFFF)
-#define GET_VENDORID(x) ((x) & 0xFFFF)
-
-#ifdef __cplusplus
-} // extern "C"
-#endif
-
-#endif // _ADAPTER_H_
Index: sys/contrib/dev/nve/amd64/nvenetlib.README
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/amd64/nvenetlib.README (revision 261434)
+++ sys/contrib/dev/nve/amd64/nvenetlib.README (working copy)
@@ -1,52 +0,0 @@
-$FreeBSD$
-
-The installation and use of this software is subject to the following li=
cense terms and conditions:
-
-License For Customer Use of NVIDIA Software=20
-
-IMPORTANT NOTICE -- READ CAREFULLY: This License For Customer Use of NVI=
DIA Software ("LICENSE") is the agreement which governs use of the softwa=
re of NVIDIA Corporation and its subsidiaries ("NVIDIA") enclosed herewit=
h, including computer software and associated printed materials ("SOFTWAR=
E"). By downloading, installing, copying, or otherwise using the SOFTWARE=
, you agree to be bound by the terms of this LICENSE. If you do not agree=
to the terms of this LICENSE, do not download, install or use the SOFTWA=
RE.
-
-RECITALS
-Use of NVIDIA's products requires three elements: the SOFTWARE, the hard=
ware on a computer motherboard, and a personal computer. The SOFTWARE is =
protected by copyright laws and international copyright treaties, as well=
as other intellectual property laws and treaties. The SOFTWARE is not so=
ld, and instead is only licensed for use, strictly in accordance with thi=
s document. The hardware is protected by various patents, and is sold, bu=
t this agreement does not cover that sale, since it may not necessarily b=
e sold as a package with the SOFTWARE. This agreement sets forth the term=
s and conditions of the SOFTWARE LICENSE only.
-
-1. DEFINITIONS
-
-1.1 Customer. Customer means the entity or individual that installs or u=
ses the SOFTWARE.
-
-2. GRANT OF LICENSE
-
-2.1 Rights and Limitations of Grant. NVIDIA hereby grants Customer the f=
ollowing non-exclusive, non-transferable right to use the SOFTWARE, with =
the following limitations:
-
-2.1.1 Rights. Customer may install and use one copy of the SOFTWARE on a=
single computer, and except for making one back-up copy of the Software,=
may not otherwise copy the SOFTWARE. This LICENSE of SOFTWARE may not be=
shared or used concurrently on different computers.
-
-2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Se=
ction 2.1.1, SOFTWARE designed exclusively for use on the Linux operating=
system may be copied and redistributed, provided that the binary files t=
hereof are not modified in any way (except for uncompressing/compressing =
files). SOFTWARE designed exclusively for use on the Linux Operating sys=
tem but which has been authorized by NVIDIA for use on the FreeBSD Operat=
ing System may also be copied and redistributed, provided that the binary=
files thereof are not modified in any way (except for unzipping of compr=
essed files). =20
-
-2.1.3 Limitations.
-
-No Reverse Engineering. Customer may not reverse engineer, decompile, or=
disassemble the SOFTWARE, nor attempt in any other manner to obtain the =
source code.=20
-
-No Separation of Components. The SOFTWARE is licensed as a single produc=
t. Its component parts may not be separated for use on more than one comp=
uter, nor otherwise used separately from the other parts.=20
-
-No Rental. Customer may not rent or lease the SOFTWARE to someone else.
-
-3. TERMINATION
-
-This LICENSE will automatically terminate if Customer fails to comply wi=
th any of the terms and conditions hereof. In such event, Customer must d=
estroy all copies of the SOFTWARE and all of its component parts.
-
-4. COPYRIGHT
-
-All title and copyrights in and to the SOFTWARE (including but not limit=
ed to all images, photographs, animations, video, audio, music, text, and=
other information incorporated into the SOFTWARE), the accompanying prin=
ted materials, and any copies of the SOFTWARE, are owned by NVIDIA, or it=
s suppliers. The SOFTWARE is protected by copyright laws and internationa=
l treaty provisions. Accordingly, Customer is required to treat the SOFTW=
ARE like any other copyrighted material, except as otherwise allowed purs=
uant to this LICENSE and that it may make one copy of the SOFTWARE solely=
for backup or archive purposes.
-
-5. APPLICABLE LAW
-
-This agreement shall be deemed to have been made in, and shall be constr=
ued pursuant to, the laws of the State of California.
-
-6. DISCLAIMER OF WARRANTIES AND LIMITATION ON LIABILITY
-
-6.1 No Warranties. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, TH=
E SOFTWARE IS PROVIDED "AS IS" AND NVIDIA AND ITS SUPPLIERS DISCLAIM ALL =
WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMP=
LIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
-
-6.2 No Liability for Consequential Damages. TO THE MAXIMUM EXTENT PERMIT=
TED BY APPLICABLE LAW, IN NO EVENT SHALL NVIDIA OR ITS SUPPLIERS BE LIABL=
E FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOE=
VER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS,=
BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNI=
ARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVE=
N IF NVIDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-7. MISCELLANEOUS=20
-
-The United Nations Convention on Contracts for the International Sale of=
Goods is specifically disclaimed. If any provision of this LICENSE is in=
consistent with, or cannot be fully enforced under, the law, such provisi=
on will be construed as limited to the extent necessary to be consistent =
with and fully enforceable under the law. This agreement is the final, co=
mplete and exclusive agreement between the parties relating to the subjec=
t matter hereof, and supersedes all prior or contemporaneous understandin=
gs and agreements relating to such subject matter, whether oral or writte=
n. Customer agrees that it will not ship, transfer or export the SOFTWARE=
into any country, or use the SOFTWARE in any manner, prohibited by the U=
nited States Bureau of Export Administration or any export laws, restrict=
ions or regulations. This LICENSE may only be modified in writing signed =
by an authorized officer of NVIDIA.
Index: sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu (revision 261434)
+++ sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu (working copy)
@@ -1,321 +0,0 @@
-$FreeBSD$
-begin-base64 644 nvenetlib.o.bz2
-QlpoOTFBWSZTWQrVCikAPRD////////////////////////////+////////////////4ETd=
fd7c
-d6MHt93wvffPbe6vXdzLa8cIHsyiSQRFGCttADntZTtnJu6fPePr3w68929yzVt2NRdTNU96=
tIc9
-d7mvXu2213j0vXnq3HbnQJKmZ3KPS6TKa087zr2sraLkE17nW83SZ3ukdDeUTaa7d1PXu7es=
iu3t
-rr3e7y3noZvY67HZ3Hud21TG9t6edvW7eh1K9vMNbd3mu5d7HN3Hdz3uQ611jbt73g7tyd7c=
gaEQ
-QAQaGQ0AAAAnoATTCGhoEwGkMyJtTJ6npMU2ak2NTRPNEyankymT0aFPNBlPUbQmp40KY09B=
No0M
-iaZGFP1TMk21TGgxQaEEABA0mmJkMgCm0E0yZomp7TSp+JT9Mg00GhkTKeNTU9T9TMqZ6m0D=
VPDV
-PNSbCnqeU81NR6NTxT0g2p6m1NlPKPUzFHqep6nonppPE1DJ6g2p6mgAASmhBBCaU9MmgahP=
U8Q1
-PVPaaap6T0yepoaNTepsqfqnlPQIeUAPSGnijTynpNpGmQ0aG1BiNDRpo0D1GgA0DQBtQNDQ=
AAAA
-BoNASaSRETRNqaaNTDVT9TepphSfplTzTSNqnqem9RR6I8mKemp6MptJg0gflQbUPU9Taank=
yn6p
-p5MkbU0GRtI0G1MnpNPKNAHqPSaMgAbUHqPUNGg9RoABoKUoY0mGgJgTTRtAR6mGggZMQNPJ=
oBqa
-ehMABojanojACekeoYAAEwCaZNGAmI0xMmAABMaBMTJhNAxMjEEiRCaAjI0BMmIAAE0p+mk8=
IyYQ
-Mk9Gk2QJiaabKm09TE2kyJqbyp+mSeo2jKngmp+g1T9NDVD9FHhqQ09pMT0UPFPU9R6mjTZT=
9FB+
-pMnqaAaMj8cNbHfXhnpOTkXgGkNK/vhD8A/12Hw1Z6nyejknO8gemgdwUx5tJVOqFXS2IuRI=
CB6W
-sa6sR8ALU9KIYMyp5Ca8cQpOFnh8CtGJc/wVzSMxn3TM0LxO89EKoGxDYRmOvPmgpAP2YAVj=
EA4u
-PXilv5UmS1TIqSZBMyn7EDy2OQPDKW5C0NZEbmGb5UpptetVnXRovTPCk2ywvNs88ND5l61y=
wvpz
-zej5sqtRR1K1XVM40DJ6+/0EdCbjr113W36yvIYxvhWbHVO1xo3k1K2tUqOwI8xnVKkZFSlr=
B6fU
-jV7JMQ8KwxrQKGtCNmmsNQbQ3CYmx222hIEMDWty9EC1DuYGPoklZOej6d46KrIiCiBUBmYK=
IAWu
-q6JwKfa7Kjga5xj7x+JRkYcstIVvfMsSWa2krlGJ0bStroMu0Gn889b6GfNZwDbUfuwIvG1a=
x1ny
-fm6R5lLW8B6pE2pmHP19zS9Y66C+c+AkhmlXWYeHosFCpmV9FtrXpxplJGgM7nHYN182U3rL=
NWtm
-wbB7hivbpUcpq9LLRy2Pv17s8rZ7S1RrqtE+pf6bLrcFebTnmWNIyzL1+zx53ZuDFJgbHU8/=
lgYD
-+CZPU8GakwtSmHVjwruqr8uylfoHC6zV5ytVGzAjq3KnKy6Szn9dMq1beTU6jmNGjHy87VW8=
iKtq
-G7Gly0+dVSabj3d2wVDPz9BDKIBa8W3iyMpBm+O+Ea6SNdwFajpUX18Px+vxedF+Wq1v2pv8=
7x91
-U52NODaavMzVC3O7GVjxhSNzjt/FqQHyqaksQrb7eP071HUjKtrgP9567Pp7trAbcYGLHhlI=
5SFH
-GuXm6ncTZ+f6X8/i9qskGfcpY6SgxHpyVaNn48tyuPVzHMrfs50xOcyz1tpGXaa6VtX+R0pn=
5+26
-llMx0ZHdTQzUFtctNULM1N2NHaXEashVTu1nbKspq+4pluretZlLYVFZCqJa4trT4rCamGE0=
euLh
-m5WadffpqLol7Uds6qL4niRj52eHmWnRjfDRTOCMeZouaY52OqmA+qc7ZZRkU0Wwap54Khei=
N9+R
-yENfDz64YJIH1KToX/Pd73R778r5nidzvJt1m9VewvC8JOj3np7XcSHhmh3N/iJYqpPa4dQM=
KBZJ
-v00UbXwstkIoV5iHKfCpGYjixdngx49eHZ/g3yr7gUncWy2Tz87mVyN/VKaYXeIoMIj3gkLw=
fca2
-LnN5rAbL3mkID0GkgR4m47Hi43W7Dl8Xk8TX2PmXEvx+5/bPNJowCEW2JIbEoQgQeCwBCoGC=
QGhP
-J7C/YVIgbEhI1/C/YmjSBNY5Zq33B9jtpTsDQ8QqkDaEkXGAgypajS4mu29mzy/4y0kHX4uL=
yZTv
-M7PnwjWsvnqR9Nh93KgNnMiB9M0pf7R2IazCyCQsPp/k9TOeZ9vh7nxHbt2aJc2ClFLUKMj1=
zDia
-E9Ku0Ch34w/A43Gpu0oiyU4ZHJpPq3b3MFoBeD4PDY2myPpWeW+lXwBlnyPQ9Ljum3J2iYiL=
F5RF
-IMRaRuxxojCYcSIQF+lB26wwdrIQYDFz7j6ux7mjijU0Nhjw0r7/4Ifv9nf6t2nLz2+Vsvaa=
2oyp
-E/V0e6mTp3fCuUZi8IbuDREeTOvDsf0VnJq3H55gsoelZ1htaCZ7LxOLY6gYyIUQ2m26Igzu=
rjlp
-pOBwbDTphRDKOkLkvS+1+X1vN7d1WTgwk2H1nWzmWFmoHKhIFBGKFJhnNyfRuLMiERuDlPvK=
n9Sa
-BB+17ISbZaIoVE8D0nIH+Kn+P+Ptv/6xs89tM1ICqMVEIvpiD33F80QjuGl/S0tSw1jEH6a+=
k5lN
-c1uYBHOtwt9stxLojQ8rUYoDtoAX2YzKVa+hIiuXWa/cQGQe7ZeBoPtS0tZpqJJFXSDpQ4AI=
3a69
-9xIx+T09ATawPJypyaEVScAcelb5+g1879ODevuaNuGxY6pBo2NJAN/tc439fQ7rzdG5FX6m=
+EPy
-p/0HuWiKsOVFA1bzDNIkr51lpqR3aP0RPYFs0uLHYP5HT6xRGDuLGVRX7jvn0rItFEIdek05=
ZmYr
-orhnFoODYPUGAhgDBXFzHrwP7L393jGHDmoy+p+DMdRmkgkUExKrFQMrpmHh2knI6OuUwcs6=
e5i3
-twxOK7VaoDFKRaK3DdzntW2B/QfYW/91t1S1N8Bm7ITbpyVG/JHIQ3FZ61N9Rr9v1uglLavb=
A7HG
-rEibkIOg7Nn3u3DNCY4eVIqv+L4WFUBlLET5AH1B0+kzFevdx81yvQIds8IhSMhu5kKEerA5=
kjmw
-2m/I2UOoLMqBJJQtYEykJFI45AmBfXDuXHKVWtPmOLhFnNB1XSknfV6mTtDXyKWBCpoeVAtP=
Og7h
-emo+zv5STSON44m6+4dMfX9ESCI93R4/Q9rI50H2PQ9dj1N7uKZTjL0WnHQgPOf661q7Xnue=
d6mP
-7cHcqc8/wm+tNW9r1IftexRYl9m27dnlnrdvDH4n53N/Xiq8inNPTvN9uHCnZ9J2QgyFBPzD=
ExPH
-LObAhU9hqwWi0F0yRM2ujvbZFsJcAH+dRByXXvGZILGagUKJIG7AEywCV46sIEDHUxoBBZJB=
RYBB
-I4UoASHEYQ4fB93gTcScLeHCyASxhIFfq0lQwyYTITMsClAeK+m6PmP1pbViWo5JcTbEpmiS=
iYVI
-gdNM6tGpnCgzZICtrEz3GFRVKu2OpWHvealykPStq1axao8VvV6Es96VKzBa14eo9JvSiiHe=
1073
-o73FWz1uzXTGCYCUwQJjoMoyTiawMkUwZD4rjBgg6proUhrVOibcmwZbqIzZkmyaQ0wnyOcs=
htty
-5wQhp4MpsWFWDyM2ciWbWfKpSa2HP6t0fXJeOxmccyPQvEE2HW+GCIKgwS0ilLTdmrYdDmd7=
XhqQ
-U1w54BSjghgIBxTDNyw9ZybZDdCQWQ4JCOFGsZCKffRMK5wiulJpE0RCFJIwRCpwulqsHioB=
QgHB
-B8Yh0YCY56DFMN8hYzUMYXvDvbKpmVdhDCZEJjUgHWmbwS45QTCkdtIUlaiIvFleGqFc3U0W=
lNth
-0ZJovIk20XyqU3pJRGBN2EOCLG5cFEpFR2GuhlR8q2kmEUQQJIRURZ6TMcLsutmCYVREIyaK=
jCYn
-StArCs4uw73im2pIGzCpDWWE0vGhR5d7g6tM1cTBXhNXRKaMmTk2jwutOCQm/E2QmorCHqO0=
Xszi
-avmniHvsYwYiXrk5CsoELKIYhGyslAzJYjrYeAbQfowYTsqxIssJxRYPg/eQ4xQ6KERO5T6V=
hycb
-DtS13xcr2mimCCqmtsw5eYuDZWbbmQUNqaMNkeDjStA1FpcsQWDajC1a3h1SXmRwgRgSDlLu=
KlmG
-HxJ4aCsWpKELB6WYYrDVweyCHKG+a21NsMpdTSG+FhZhWau+cFmmWWzfNk0M3peExhtjhQ4C=
GXcw
-Nt5QZqmsCo/dsmGXVuG+ZhhEzTNEJ1EmkMZC9B62+pmyUIFVJy2WSN49DY22YS5blKMikUKq=
+8tG
-cNqc1sqHFDh3J1cOCCXHzOBgQF0NnleGZtCHTUQ+AxSGdi0QHTVeqGoUiGBslSRz9V3Ylirl=
U1XE
-4zQsRV4FSGZIYiX0TWBskx1awkcusEM8dGC4iVvShncYYLHkpAJuIUN7TeRS8toGtb4rCWIf=
X+m0
-eo4UIeFo9z/x19MZqYDIDGSH1TKyQFIMJOVhCT2X2HD7O4l+TtAkCHw0GhDMDNo1HAhzS4Nm=
kgEm
-LKy9OVoEDTBpmQkhiQIf938Pk7zDiw3GH4bJOuJJ10hPFYsJ8BCTodp77hybSEA82ni6bJzJ=
MarA
-VVhOi9hMSHBUh+tYH25qqQ4oUZ2d/0npejxf4mVIvNIDswaD1hiLTbENoVtgENBjtQxsRYXb=
WiOr
-cuNdlxmQqaOycjtYsffl+Fzx5U01x235bR4NmizXkaOKg6JhhIhek0Z+XAAfFYAbp2Giwk0w=
bGIP
-9GVm28W9T7ZgZuS4wshNGi0XGgWGmBVsBKlnUaqCpiNy0CEfnGkkSYC6NySH2QCBDEkJ2yRQ=
qQkL
-5yiwgYkmlqmCk0WJOEgLTQFDEI7JovYv5JCp0+gbu1uEeRpPHn9vKmdVxeRhCNBx1D3hg5Fp=
fRIa
-kAk0OulGcEn0SBiiTtmecQO9ZCHZYCgFDHb/2yX5se1jSjBQFhttoFrWHFzuJsOoopZwnisW=
yZvO
-22yAGyAYhRANMhi23936Ew2Z+J+k8TITgk+bJz1V8rwfI2t0TZVfhMmyFcX1tNRh7ZTayGfP=
Ho0y
-E6Dx8WrISFFYSHTeo4h5lwQUJMQA3YQh55hCpICkCLDGHjM6KGK4gVKlVK1VUVD6HurDFRZF=
FCKK
-ioKs6DKncNRUZDzyTkYEPGTSqybjJ3KY+qjJP6LCYikgcGEKr914frvPBqbCpFRUHsNHY22q=
ammE
-4CjJUh0mTt0IddD2iQx75ANkA8nmsOLAlfi9O9AjIBOoAgdSghAEhkCBkZDqDNd7SdvCPvoP=
a4yu
-j9n3dz+Fzuu5Peu3iJQlUbuO953/D/WX5z3/X7Fz1jH6CQlH9hI5PDmauSxKWy6p5ldxk+zs=
6778
-SalUhxZWZkg1jiLDdXdrlP4iXca7i9J87mptlq73P/UgwPP5EI650Dr4BEpiiJRggZggRpCK=
CigG
-fidmnjGxfVT1cfL/p6z46TaOHCzDH9gawVQtLkAUCPT4r7XXyfUswTxqU8NzeKi1qLxDFD51=
3B2f
-E415Y7fF3XpZjt+THvg7EfBKCGCDGDbgULLSVUP++AqaGnbZ37YiPAMFRBQA+pB8+Hs9p7OR=
wObz
-X/4/w/m5vN5+YzPgdH3JCFg6tDrp4QAs2Ze7Zb7GR5uvA93E6F/wx9gn3DkH427UP7/uoPh0=
+mAh
-iVUjckjjFUxddg/z5Pf/kbr3MRQutVfh2IO/nYH790xRnISLwnL6l6LF7iderlSrt0Dt5fiU=
2e4W
-T8H4qvkNyWUylxbxY0a2traXqLWbA084CIXhkQAnTBAFGlGPYA8c+hseP4tYeNXAmt3HPF+I=
9Ned
-T2FAFNDLBRh/rV6M/KquxHzZQni6tKQ4dVrrrdYYfNg8qhQCGSwcd0ezIgmqkVvqQrg2qoHb=
rMOU
-hl0kiCC/lQDAyR+12FDUiBBVqQEeqEn+lzkWN98/cUnEzHLy/m/jze88rP3e0f/V+zlVHNta=
WR96
-0p4XAme+oPL3eB3CmWVtMstN8z2N18u94Xh6vxJ6kIgn8dllZRtoVLG2QoiJI++AsCsBRGAi=
QYkF
-iMiHvxAmTILMzIADrwYyTBEpYQ7lFd14XAzfp6TkSGLzPCf20e+e2atpb5V3bNelkOVcP4dh=
8rxg
-MjwEJk1c7ax/F7K1nXld+Kzh0un9GN+PObzSaNlw6dOm44pJJ556VKeeeenTqXP9N9+j9KwO=
ycA+
-jy3j4Wq6D5iZLoAAL2vTQgRCgaQkdzzOaElzWTceOQAvstJLo/UYcyQlNqHXiSB5kz8ivqDR=
9miV
-gMaZmbYNNaspxzgx7ph7hpJUspGkBv2C3AzsH31jv6JEYxhpDvqI5mV1zy3NQ6bBAlyjZxkv=
Cnko
-Ysdqrr6ZHNaMsyIAAIQKYgIQ8UQEAAgOEJQXBZkALoCBB0F1Z5jYX5xt0ex57koW9nerLdUe=
CUji
-EL4wNGGPXBCFdApWKq5B+ORiIwWSZBolLFCxQjrhkBhJB7bMTmyioJAE8KhxFQYXLWydSGQ0=
K7jF
-6xk8DxXqSglx21zlP45WyG79/o/qnvC8/2eZ6O4nhJfFSrjXzWBps4aJWCvK0i+rg7pYN8GA=
0O3H
-rVu300YGnIrsofBKs7VQw3n4Kb+vN4B8wWSMvU1oih8d2WRlSwXMxgOFTFUKHKykBMHRJ1U7=
sIpy
-vKwGNN4LhKUEoRRh2CR11aO515zACYWJm1gc5TrLHYTsyS3n0lRnQ+FzmVHN+bO0ZucACNJI=
lOuE
-LLj1qv4cNV4XYQONl01T2krVkMO4lUUOpjVnrN205GRYya8slWSxiC6T8PrFvWbLlGh0IEhn=
Ycsj
-mGFQMYPY/JMMSHthkKJESIiJEVFFg/L+euEYkNIWMnJaAoB+jEP0BSGTb6fWtbG53NpD7bpG=
tAGh
-NhpoTMYKPk2sVFEe7tzMmfVItO76sPpCyB9AfU025ucOczoy31ORozsEa9lmwcDIdkS/cjgO=
kgTI
-EZM99H9wZiGikrBFRUQVVU9qdDvve57Tr56CpnLuktMpS20QDuzv0iUDTLyXalhnTMHaRqHo=
4XaT
-/aZLmYAyoz2fBqCA0NCMIkdHWymNm0oKIEaJcumlZiQ08kLzm09TweL5Vp8P3fuz0lBmr1Be=
E4Op
-TvrCquWFC+DHSmTHYNquMxgpI0BZaVwg+YJJ0ohBoiTKcKmglnoP1zeSQ7JJIyTbmj57uK9g=
E90K
-MGENQrnGsA5W+/9dzd25wL6+ZJYm7i4bQwwBiXD/86tu8K0Su/zGXB7MhBAb9wMT23Bjwrpx=
KqrF
-No/Dl5sxK+wYIBXGQ/GJDK0hzsAPhPF6sUJKLi9rsQpVeJXF2gxyecYjq94o99SIr9mnl3bb=
d0QD
-7MgGFhxeBVT9jNDcFgQfgboi5jH/gtw5S2sr4a0LSCv9hojDmVIJCvmMU07IoDNyiNkmUDIP=
ZGoK
-onY1Nk+ikSwwfWgSrsB8BDlrGz0VzaPpACg3ed2m+pdCyM6QvgHSjuw+voUDWV07Ua/47XH7=
mS5X
-qe7urrqqmxfvpuBqtlmNBnq6glpSixcPKJ/LjW1u6klpU3tnBcp4lTDq0Vqlaii/XEkN4LWO=
dRMa
-qGtkrUKDPztqaZaoH8GWge86cVmpgAsav0uqX16JfzQu7sjMfAFoD7FAfSD3YgKZIA1P/n3w=
AxgB
-QNDjtR24oL78PDUAsnNrYGDcxK+ioH8OQY55DMyXsvecDP4FnMNv0oAbM7BrEA17McNf8/df=
U6f7
-/T76++Sc/z2tFNMyEyBv8odfOx9gzp1AMAYNBYyj0WRiVfoIANh/oZnPG0Xw6sKX6g8i6wqU=
8sas
-TGdm2oTaQ0thgD56QwJxtszvGR1/k7bsQ2+26A1g9/dSho5QxJd2woXLyl2xPdGvpg3bCo30=
12tS
-DgMWttFRILkrFgnZS400VK43bEUhbalRH/ZnAZJNBymYl2whokvU1WV0uuyy+jLN7r/t2zsW=
xAAy
-tROfw7/H9L353b/p+i9dgp+uQh75kKI4RlKiZQRQiTGtNUoU0VQBQkbKxCW66Xz5L3j2LrSW=
y9nK
-7QXJCV1MLCiQiemEsLYxpKHdxszd83Leo7A3FtT4v4M/u8Wu8rQuhWVqdr2HG95tqQe3lh72=
TE8J
-6HplFoJlB5I1+PCXVZVTZMb/5Aoh+3fMqALzgYQNPaoKy3uwOc0dbA3uYAFtgLJ4N2L3QjB7=
PiNW
-huAiAOmVcVyyhkXk1jhdkV9kzbj7T2sGkL+W8pbwZURQuD1kwoQ0zhgaoe+0bfoNEIlQdUdq=
ECQq
-58m0Ico4T4+Mn3SpBNrcsue7pkP6tNUa2xI0XnSILmoI1pItTM8w4prSCrMpK5nJ5fE43cUo=
DTiI
-X4hNYF9xu4k5xmHvbEO/8fjedemeMj6LZ6jpux8XD3u5IFoQgZ9nGGmAtJxB6fqKHxjHiCd/=
f6wm
-AoA9t2D5Q9geMDQNMjkvJxsXLuZyZVwqSYwcjdzHbcIpoKE1MyyhIGcgY4F6kIiGwEyqrqJ0=
CexW
-wy0ZhCNAAgRIQ6uHeTdbWvP1frvup97PO0SY8SurriwmAACnDIWona0YYWHpNGU1vnjZubRA=
H+5q
-jOmqHqRwUQPR0PE/DM4G6rfI2vg6CeH4BMPMXY9rFiHF7SGKdDBmHBDCOSYbxH+fWyAjQW8i=
asRu
-PlVB2+qhYdE84klpDFpNBDVv2kuSOdofFGA0ZBRzwVIqsjWtLp7+DAsbYS43cKprcCZwZJt7=
G2J1
-/gfG0QPMZ/TwXUImstrk8WZAmZUGZkwytdqGEsafOYECcwM3nPajQawN5Iz4KmrwAofRXGZI=
Hv1w
-tdWpWnlaNvY5r8Xh92cLswL1Q4OTdoIBMIvLNLQQSDshBB3yDhrW+gRw3TUnAPzBvJuRA42S=
xixB
-xZjdoNki1WanR4PA7McDBY4FxkI096UKiUWbhdpf39hF0XfTFbpr6j0E5NUDN6FAxnq2lqKl=
kaUD
-UBAOfRih8ZvxTCvmaGSls2jV+GzqZVmiqon8hkUHgIXlT7j/X0XJkbBMbFXY/y9lxoqjUzxr=
zrNU
-oRxkzo0S5imjQ7RQc257+AB0xOv3LDDCYCPkQM90t88CUXKcKNvlXx6ZS8v3pRdoNHlK0oqj=
Nh5H
-RluxMjTfHpU/5MLB76zcG2MUILjwEegxXaOSrcsPuduxsM2MasdMEVDYNqYQEhAejwEiHh0a=
DZHb
-Q+oohXahA7ky71UDBCUcdXw5CV55+sht1NFUlR2oO5ZpqcImeeUYJYyxghNmZgaFAZnRy84k=
Hl/j
-5P/zzKBUnauwfyFrMae8wYnODGpbkIbS6aD/W0HNGvgeP2BJeLEZjLDVka8fyA+EF0ulBjuw=
SLun
-6qjvZ1uOiYyIaVe8vCAh7/Lpt4a0E8OxmIVuoZ5QyedgHOARkQCQv0SMbPV2UfvxOpbTAeLI=
81nu
-/dQjh02KzDGgiYeNKbMdqBCv5LmjjMDLHKgZbOfiU31PRNnF153M17E+hrkr09tFZ65M3pep=
y84j
-2qemyyIgqiqrOm+R298cjyPhYDSHZGQIqsOVGsiY8EIb7WjulNGfg6EMcBOEXbiF20u2J6ld=
8zUU
-UPY6ajrd/4u0ERgymdJwwiE8YtDgI+/AoNWsOfgeqQ9gT6BZAIrcu9Cau1drTpPBNfY77qDm=
5bm4
-WM8aAQCs/WGl5k+wcca/GcCQ+QB6KgPNtsI2g9D+bv5q/ca5DklMQESQveEQBgjMiMW3W9nb=
b4bk
-eYKAac9eSUR3uedgb66R7qncMVHEztj9Zc8p4x0zUqrUi6Ws7VbtkQTzjNYuinYgDvyLQt7h=
X/iL
-kvxNeexSavhuS0anU7frBbPMhCkbKkiP2fcwKTW3ZXU6OFcjiTOTV8u+BHMDuvR5FWYEVZFW=
H7rs
-D2fm/e+Z65KexNQbx97jIFD6mMNIHrRNa9RzTedmcJpuJTaLPNgxMDChrRylE1xNUSMGw1Zq=
OG71
-JcYzjs2uPRLiRGzMUsXw+PKe7qLG0+a74qWMcT1iYH3LdtG7EwGhEHnuIeh5UmFDDo4qOsDa=
4okS
-lZh8vuc0b/oGGZW6VMKUQ5JO4+96BiMf724iITU9nJCslSKGWmYzHjx97mHRv6FkoOidX9Ew=
uTW1
-K+zuaPcR4H5C3ULdUxFEXu9U5pJWdT5j1GhofRrQB4iD6DWlv+pguHjJEHAYFOZGdjunx6EL=
qRLB
-QEUO7cO2nUkk+dZYWDgQd6532Nf751I5V6qvI5ebo81jalDozeeYNuUPWpNhLIbewy5ALI/U=
1pCn
-0kfIhxQKHkib7tlL9CmchpJceR2wpjStdmR2MnFz6g6BhDGMJwQs4RokySHydrZ+owMGplZO=
S7oy
-aE2TRNIIlh3aa9BSiJvcRJBmrRZEgxRNsm5bKb66Et3iIzfabqW1zMqznTWxTiNWF3Tjg6es=
WEPU
-fABPAkPk4Y1FlYnEVe0ANs4KBEVFyQcdPsyVMRBTguGOyipGhUFqST3HZje1WIDfIDQIdMMh=
Bp6F
-IJX06MWEQnD8Zbth94LOv3GYE7YxljxaT8B0NG4I+MxALGe1ETHxGa/5VXa3I4QeYMcKzLbG=
KToB
-HHH5ALcBurgMyNAm0H4cW0DfggnMuSWFoXL1Sblh6NMyPbRPjYDAci/oBckAKiqNZLMcM4kq=
4YLO
-E+ECiIzxS39oRAOJpgookd2eg4yJwAo8SEhEGRk7iXeyFyRMA7Mw1Q8urx9RbN4yaC3BtNNM=
tO5+
-YvBUvgJZKcmWWliV0p6pRv/P7mKbth7Y5CySwEz8rkrlO5NEF+JxI5+FD5rVaC3WnsSv+0V5=
PRXD
-wvgs9m3b/LrbXjv1TEgUMcUvnk6UpM0KCRvz0Clb17cPVzehAwYSQfWz43g54m9ejMxMq4ko=
z90M
-LrWNQQSJ+tvYUjVjhFuHUir5E6JoGxbKg2NuOXzu0GyFjAsYZ7vMXkljfBXEjHtK4XOX6Y6P=
jy/H
-U2KuH16+0xoYAtnKlzBvAkhF/pPU+Yid8KvgbngTL9CzThqWxETqvxfVTWxchdt8yMUQiR3i=
8Bh7
-E1VS8esn/thP5LjjHK8z1VDo1L5QGHdz7lT7CLQ/mbJ3/YCCI2HvnbToxxvKtHD2mIi0BtdO=
qQBQ
-GuMckKk4KAP4SF3K59tLyaPrEj0+aTJCMH2/NJnYgDOr4b7E1HuurVrdbziG+LVo76xSDU3m=
WDwC
-NsPfntiPlpjN9BkTeGFGY1YUERHYRPYVxxotKAbQrAYXfRFhQnZnj7VSlKb5BirECTlB5vp7=
KxDY
-rTkxFEe6c/HM/N6/9rTwQ7FDMCKQeeII9WIP7wf6fTpWaEUDt7VIFT9ZiBAPhAXEyAvXuQ79=
oYhA
-Wkdr9SKgT8RGMCQZWxKhyAVU63LoZt8AQFLxbX6K7tpGHLxIUiOsCBnQ8IIPQ8vOK25EGNUI=
8COk
-/3PQ3Pjyuup4DZjS7xwGP/NxZbwPNryHFP9LwUbQyxLB9XyIZALMgW7FMLog3eXDIREJKylk=
gw1H
-bFXgSpDLLio1ibAbNaM01Ep4DTkfDMg3Y+EG9ImMhTO3KUcgonrUIwSN3hys7t7K71/vfWMr=
jycJ
-w5UOy6lG6FD6rbLkYHjNVuKxc+nlrwdmBjAa6kDoS8u6UIR2nwzKzUbwowuUBmUrpK5XTjZL=
winj
-DBv/gwfad05MGRVICD1CG9EcSCmd4ZSbWkRk5l0sA++skFer6g/XOu6IbJ7vCPM+RyXX5DTt=
wII4
-q/LvXRDlcXEqM435Dir1XYej4wpYrgcHH60xr9iJqeouyQkEpQSGHy7J1oSOIi51OAXfpHJA=
PepL
-7HYcXbXKwx9pY3Z3L+7wiOxvRZQCfDQC+ye/Fb+HTIm8lkvyw/DJkpTiEFFNjj19uD+wl8Up=
62GH
-SqektRUp4Z/HgYLousRevjKY91z4irFrKlJrLFECTJCQj6YGDji60GAMiIunxSBDKjvBd70d=
595f
-VsvP186ng9TvJD6Gm5cVFCHAa6J9ToJT8/v/eCxI28b8o88W9XWZ1GvQY7fMXtSNJrX9kGBV=
KLXa
-4HmwjQm8HoBVwB24YFOuUrZM9pIPWkScSPhqguk8JMJpmms1x8qv0iXAoznlMNczScfHhEMb=
P5wY
-YnkfN8yDFDLpPxtfrHjEeFEMYw9481o+EybVcF7QKvgTD3fMCnkGjRkp5mcSJc304djWK47z=
jfyK
-Xw4srDNYo6f8HsG4y2DKWZH5UYZnMZAzLej17Ch1cTv8TkV4h6dAB7orSPw7wIU6YjI0sXz+=
0YdX
-UFzG+fTjbuksGbEDZbYlKUJRyvSJJz3tHP8rDU2PjRCHTKKiy82zE0xqqx87DtByUsn8Rrsr=
zO85
-3OSaWQdRWglR3euIURViyKLIL1AOvCekCbeBDv18/T4WrPC+IXt00vvHrxb4ly+8dRQS9GIF=
+zjw
-cNhogxe0GbzD/MDbPtUouCdKIYhx0eN6uv2/uf3Oj5/3yzsD7jX+810MbhTMr7rW30Z9H5d9=
ed3J
-4Z4atIh2J58Fpk904+dYYNFCzpAEYUoh8T3zQlirQDab3fDIzzM8LQGZgWR0AFVLGga1Nm5r=
y7Ve
-S3TsUCzBiI2Wim2rloQsinfXbWhcwy5KmG10xOQ9no/S/kJ3fbAcENfEgQbwgAXh/2ArStq7=
bGZN
-LMH5gTHItD9uW9be+h2Ib1B1+n6w1C/PdCSQqsS6D361WgruadS11WWQdwtN/3X31OTA3+Kg=
lMpx
-TkdvquMjk7mNwdBESI9kWaylFINUh0vTwprs3QwkFklLpqlpmghppGeoa9iU0jocMbBvkHcX=
Pqdd
-6X4PCReq8rBWaQCHb4xC2658KXbEWiz0KEJRJfsM+GFmImOiHCIAEdwNaK4DR0F0u37/ZszG=
m2So
-7SRP1w9hvBebqKPT8naAl8P7xQj9XAGXh2rkDlLazWQZBHt/pbnu2uO+MZ95uiZaPtExdI79=
fnFF
-PNVTr9NyhhmV6T6/2vSOVknVhDqH6Ymdtx0It6ftfnf6dZ85luv+KR9/78HdN3UF1gv2hmPZ=
yxq0
-DNnNuEfylpZupZYGJ4KxeK+SCJTXPSe9gMUDSC7dkIQMnjrvePwdmqAyipJoT6L8zclJAxmv=
+X6h
-8bjKQkbIP36jE8gi0eCXpLPvNrrB7TtMwpJTHpS2PhR7HRIWJKXN9OiTmWXDKv8PFCeDlaC3=
dsR3
-JGR2Z9bHd7IvT7qZSsCXCXHITQoHO+h1EtCHUMmhQ/vbbHFwtvn9QfV6fL6zQV/JQdh81QrA=
WAsj
-6+hXEPdpNJ3LNkOiwM9SMBQUbVEhCQCj5L6yxAdIxTBjb4UOZI5SP42aV4ce/MON0zA5eQHK=
hFNl
-X+7cGya067Xhm1GFlKqo9vn4HTeJx9aSwBQZh8qugVL8lrxEwx2LWsSW9MGhr3NGKHhDIDCy=
v0km
-YhZFJC+X9NH4kK2MKSTT0SyCzWGBYWKROls46dhJDIvKyfBUQXHGkE/g85AC/ytBrO9wxe7a=
P4ga
-CI7VvfEYYXSHVmJxtIv1IOBOvnk+vys0//Y9FFURlgdDoUEl6zkOik0WIPs29iY3i0H47z2R=
yhP5
-rs7UZns8+6jj7PmXVUsPgCBpPw1O5PBaWItD48s/AB0v+OtByZEkEfnIUOV7rg7U9We1D+wV=
y5vk
-dRApWCrYGOuqB4MmMz6BF0rlD3dsJBmXkwl8knGWBEZEDOExypgNO6iafwZfeq02gBahcfvW=
/qWv
-EXqWxNKTP2ccKNwt0GiK90apc1w4NMITLD19KqUetjRYWmGa0GLhzSFvDaU8sWPY3sTDIiuc=
51W4
-Dg+y0lmQLiaVEd2+x/8QvS+nHCe/+m4ynk9grJnE0d7mG1Nsb2juXe5wR5LL7s7JHNIgkuPj=
ORQu
-JyRKSA4W8QRzvPBED4z2AXUyLDkxe8tTS7gw2LWcw+PtypbofOKads1SwuoYTxI7slAUtd5u=
o1DO
-bzYqdl92mfIKapUGftdhNB3o1aHI4cG9Ghb8GJM2YyEpRkSUnIYE5frWuDdpDSYcn1dnVMxn=
1b+T
-8mCiG7bQA+q6Z6ZLi9lvdbfBzidkZyvJmKWJeCU2YoAJwc98Q0u9nFAiyPg0Oj3UrJzMoufE=
SsX1
-iB1s26dDZDMRyqHnvc7YquzD9gnvOP7TxjyvRUt3KVV+oPYWS1may0LSl6nTgdUPO+hhkzM7=
sUF7
-hC96vOXsdb0M7CmBcQrbDF/4moezQH/YqZ153yTHDnRDrX/Du+g1d9ZvC8Yf0B7Egs1g3YcR=
4MAZ
-yOM8phIlejWKOPfDkOFsl57IGNC1BuFhYDUn98OABR7Q0LyDD7cic7rkdNkhhGB+s7Sf0QUC=
wNQg
-QzQWWJKdkybVIdQEqHVe0O+qjV+KhDIwgscKgEnpHQovAynj8mp+Fj0oOB632dL/56MvJC1d=
RMnJ
-vNwHAEP97KD7rnD/H4UCyB0hYDVcymJJWCn8v+Vk0aII61rJpKhSvEPSc+3eX78ZPTpuHe+q=
fANi
-tVsXC95K1Y8F9qPpmdc5D7oatnwDtv2p9vcIClnSPb+Y2z2z6eK8r7R172hTev4ND35zcy5w=
tOV1
-1Ns+2+5OBY4Ph8K3i8B/NXB5nuTe3vCOi5ZFUZRn8FdtD9NEaAcvVKIMKNHupQyLDhqdbc6o=
G9yE
-Qy2+3YnSWE2SQaJKyk9sKAvhfjMjxZIazH6zM0WFhh2UpltBXCPHWyQkP0+37fJgB4P4SUly=
b4hd
-mRldooON9syTENGft4YS/lLdu6OORFBj8X3Cb5bNA0iD65dL1Z4G1HljXZXN6/Wcu3M0spIx=
CkZO
-XlLNOrMtGc2am5qbIaFggPJUCxaVxTbkkitivXQtInYDhbDh4SoMxOzxSfqmAaMrwoGPiuXs=
U4Q4
-FIgUr/IKK+GqX6bBUYBrYwFYfhpii0Ock1wLeiAocBDmCpze6vhfYgxRhH6CJBtt1UIAF0ok=
e/QT
-92YWznEX0mV5mKomVw2AF12N/RqrFXTQLSo/PJ6YtuYMzBHfGRDQmJkwcnVc35kw+ZhLzAyl=
u/uH
-IMiY23olNU6N0RBnxu9Kqp9C34729gM/Xq/q+6hDAljFx0PTCiq7cQylhYGAoGRGXqoSyMEL=
kELc
-gARkQKHyoghv+hMzIYmCqXNft0VB/v6+up6v4YPPM8IRLfuNMg4aDNQv3pOBK/2TEjZsJLZe=
X6Yw
-ewoS8SZ+oUdjIqlFkGAzwYNOaBgRaLFctZiqg61gKww4vXfJKMNmDa2MK6xgFkmBqop0Iaxi=
MAbz
-JZV0bGIRCLSr3acmXrIXqmA4ZiuZo6LNYcuPtridx9R9YEQrLZMjmUIrEVvP9X7d64D/xGWv=
jMn0
-+Dxkub9/HiHpUeJFE8PT3TwkeG7oLOcgVln25z/iuu0nmA+Xw9Jk8B831QQViRF01V4HhyQL=
aJYX
-RoS09bYb7T/xoQWkkmaV6RIY3/xLaosBdoJDzX0FgcDhOH8ierEVTwKUVUYLIi8fm/O+P8w3=
3jBV
-BQWfO8cwnX/jM8lXtFhDq/OT5h5R7HAGRm5r6LLnNyZIctLxAkUtGdSBLw1XKg1KLTF7ig/r=
6EF/
-1vTw7bbRyf0t2DUhf5hDaOXnaTgleOMg1SJfV+iqvROXwENGpMXV2Tt79st0+smySUKllovu=
Z1OK
-Qa8u84QgZpY42fjY/lxNA+vbwnxaXYhj+fNi+5E8BEHAKCLCARRK4ty7CqLG4+lon1+usBat=
NJvI
-ypq/tFtw22/TOlagGOkKbIjLLSY3MxMbDr0SUB2hSGJk6pd7adoMufdF7MaJRGCzCmPQBmsF=
G/lz
-xyba197riVAM2RYjXogphLZ5ZNoMpImsKeXbLSVaxgodRdi2BByok1Cchhe0O+5ZOMOQ5Vmd=
UP2R
-9cL1CyUUcGtFDMwcGA6Dhysier5IlNzC4mYaYHVg+J3oY7tQwFbxlWhLZbZe3gcpUXTXd0v5=
DCdI
-3WTlbhn9/lIOB5zagNoRCDrMLvlctCRcZRE0oLMqY2wuMqH0ya1/JwvbU3Mn6r9jQ4Ifc/hW=
fI+4
-rB+PrFAKo0dcP3Fe7LzEnQsPJBJo+KfxeZK/olCjjIzMxBNOicYGQB4KBzTc9B6veR86JSvy=
g4Dl
-wDHx7zHi+vatDFdyKvL1qFnzLeKqjUBwPaUGGPqZ5QpSOT7+Rm1Cmh3OTYxGf0POA42FW5Ve=
Zm9o
-QKUwZyyJCn31yRERZzav+lrBVEdRWLbYX41xWBjJRWAGzIGKPxk+VlWLsk9GhqalRlwDeQ90=
/3Bh
-SdR776XwShG6EvZj2DwruUvelJ3uNPwIqyHYgIDA6Ku3yN5HvHgUNb3ZaxkgPpKd2Q7XmjKw=
tuyQ
-1prUnZfp8Yve393YxSH3gTnhO6EW1S3QeCd97rKVJqQ5RzSL8QVpMuSLgVNd6TNZ+u/B+Cab=
MzLP
-vtbnVrS2EsVBfwFBYeub3vvV35fn/3T+MMQw6T8AJ4viMwekxiiMYMY2xjbbgv67MT0A1i2J=
uPfA
-VZ5K+WDYIPoFg0aQ731PP24yO4NSUXcTDOqBP01BmePLeyyFYnmB68tO9Xh9t6X0PA5pG9Oe=
Hyr0
-PsU+MMPhm3T+AD24bTin3vb6ZjFJiIRghVrIMMgMABl2RXSQrL5sHo9On+vKuhTTjyfJ2Kcg=
IRDd
-DyzZkr/DNXtm80NW26lIsjIDhAfIsFAzfcBSthYA5ug0QkmNHpr8Y0oJiadQ7b/WWuFrAMyC=
BDII
-L+1ciYcx5UvA8tgENUnSmJBs7JNDSPAL9pKhoegQvMLGkvNuXi69NxNyarGtxuDGHiO9l1e0=
mFXb
-EBYdbrlAxmOS2eyRqOTYMb69nsG47Xqb85LNhg2AXrtNpdKjA6VSCMAGb/MS98z5z8v0L9YM=
xK+q
-yNrRWbFlt8dluqN4akixFpK+HewQgFZpNqaYg8/o7d4irxD775CFwNOwrLOvjR7x7AqJPDSU=
E2mY
-FXd9bRHLrOvYPrvJ2xjFPCZisgGgaRWsRy7Do1D3550Aon5aliJY1YZ+NNKrM2KyaMMJmZn1=
+eWP
-j5QZ5JiniZqoXMdLrl/+xo9BPKp9+VzsJH1Bhm4fknrNlsmLpHWdQQd2EVGjmF4J5gSpimwW=
dJ59
-be32+FOk+BEqUaff4Fr1onIYDM12qsTDDEBje21BRHiBMQV0qYPDkXADD0a5JYDjVtwZDSa8=
ngWG
-m/HrGFmCgiHiA6oTEXpFsrw1BWFQu936rmM1DsMa89htW1hcM0c1zOJUCZIW4f0g0gCpVhY0=
jABn
-SE6IScCPgtYwRYvQsqFSEgmEBKjQBYiOCIPAJyVKsqxhWMG9rgu7czsznzii7Ot2hkQVCg+f=
enHe
-WqTS4vEQVb6B0NjRQEWpDGU2c2pwVltkQgKgYmgtUHJ+2upTXEQrQ5sIvDoo/r4dq0jhzom0=
CWpT
-DnCfgqoYW6JVDl6gDWiBiBNdqnznfVFFkjiAc9wYscu/lpZO96NpDR5RZEYAlG64U4wyzsOI=
/EWs
-Xc0yFLmycnS2wicbv+2aFgRIgsAOAiUdF8tBUbxd/xo3d3taSezf7eOer9f4LwbibPPjCPLb=
QkLB
-sOf2W8xcKJHcDb42TR1vbd+fyeLVASQ4hH122z+c5J9mfYZIJQH4YhqHnHDYWL0wd2p/zIEA=
dN4+
-qkeXRvLxK7DQdx10uwPGe5VC3nI6eBe4dpohbiv1ffleq8jxfjugjmmff5hoR2VQLhnZg6dY=
ZYPB
-c3nPevtLOxdVW3WTbgNMiPlpQzrTQzkf1GQZLfjNwlEkjBGHkAka9vD5p4gAKcK/dNjUAgEj=
NRoP
-QTnzqZGacW8Nu1bj3DR5RQ8FpchptT85zvz5fpR/bqs7PKg4TKUC1qAAYyVkWt9iTZihosoK=
BRBm
-+z7/R+Aw3GCglURfobbYt7LIpcPHemYepK+43Z7diqFuuze0XnKnC2IVXGVMZl9fW62A09ac=
aBJu
-EXf4OmkIrVUfmq79fK7Z+dIODRd+dmHIHCaCAzTVoOxpELbSHikY+x+JUcJj2w12WI87IyGr=
LdRl
-18kT0Ihyez9hYz8WPRI/eHywQkBSCL6UlLzG8Yw7wF3D7san3zoU1CQvNtK8cj1YoqCIg6ZV=
R1uF
-Dpg8KP6XsSpmi++E5k4yDHUEQ5ORDKbXYS74mGxyfI9hb2Nb7S20/oeeyMEwDDC/KWtlBNsC=
R0dd
-dOmK+rcoemR+2WK1tPO82C0jdLGz+tDwM7iTA5kSZT4sl3FkO37ftlhQiI/7WdIw7jM2NGAi=
DjYa
-JaMbGwoULmsddjaZrVcy1cy4djJUTtD4FKCmRJ7S6I3RUd82CGkiaVl0gpR2tS/T633rsbpv=
hc8S
-DYpodjZDRmU3uh0d5rNEdLtebmhvnjeZLqTr8MGPEtlGsGwo8L4RrWUGUthWIy20kbS6bif5=
huGn
-orifj/3SbhsHn/gmPDRFDi6wbBTGuUO85zzrZhvcSQr+j+ePXmHtGaTDaBiMTimS6Cd3EaTS=
xI23
-zCuwKwfq8GSSNMNJJsLVK0WL2DyVdYQadL/uTzupOhxH5jwg7XXqM87RzMJ0u43sUFq9keV6=
+1bv
-svVfwvCpsPUDocq0KAzT0ubkfDYHktuczZmzmFdB7cGhCxXbQldDYxsySKtSkPFZqV1vnZJS=
GXak
-kKtoSuSuThysnn/aOs9bVnG/udJatDs2vjbWjIxDTA5fEP8RlmRaPQZUt2xGmDLPnzGSgc30=
NPtQ
-0Mnp4Ob0BSDbKWjGMhjRjANShYdalmUtFEtLRolRS21Uq2Q222yBimL2rQYWEumpkjC0hdC/=
X7+A
-tJH6iGwr7shvnECERpMskbdOQqSk7uJGDsI2Yx7L+cyl3zL6BzTrWsRwTgWFojbkriVKDalM=
rW2y
-91IB0WScnd37JyHwuuOTDYRKjIVFAOThZMNWplOn9vdvZlEsg/Nga7xNPk7nn5pREVKaKNaj=
mMIE
-UKbTNSBOjYt0hunUWY6R4W3ffhiPbbKllNBPZ4FnS3M9oHtOZt5YYiywA2aOjDKIRrity70Z=
pSqC
-Xd98xbWLhHao7vu1oOWxvU4zeBmkbcG1qw6JNDGDZO4XbVeNIGwWO0R4Rd9H4Vwx8H5lx0kf=
qz2J
-gZq+HnL641BkSCDMCibGJplZ9qU0w/tIeyEDASITreh/LnPafNPl4fWIuWj7uwuafR5+T7cP=
uj6+
-HuBl+Vy75+dtPU1bPkHHAQRVp4SgVkJ/uhgKKLDGzGK2EHwnXQQTwwKSwAzaudJB1kFfhOXQ=
iiPc
-MJm8phc1ok8vY8saBHojIsaOXEbfdRl3vlIj4m0DMX5z7Or+Va/kb7V7neVQkinhpmncmium=
E6od
-OhwO58r2nOdFy2ebXGRHgU03UdUKAwrHhAcTGA0XICMeBerqwqaXn6XJ0ewnfKqfqTvQ9Ry7=
f2O+
-rZJc6ldI/b0jJ3ZIZfXbG5565scLQcfvCj/dKaVgj5Jegs+ogxGkGYJDSlY7OJK+wwuxdh0Z=
Ltkx
-LPtKr226uXVYbBAHiml4Rhhy+FTruspbqeURiT6sl8mJucu1CnT711j/A6CmNXZx5VIoQjc5=
kI/Q
-yaLdklc0IrKVAUI4I3Wxyt6WOXWgjk58pQpB07rE2yA530r+kye5qS12nscsyOYgojsFoTXT=
NPD9
-h8V7vwN7b4Z01zVsISzcz3NFjLfvOrKSSdU6yjaUqtrEtkrARIfJ1mjxHMS2UQ2tccrgKEBi=
igrI
-KKLEt6LKnOe2L5r4m+H5ulHtRUFlIkVgEq0xtCCYmIko5G02nA6+dQqiK9uzTMMrPEXo032g=
wOTM
-iQBSEEoQdQM/9yeAOlHqRUkD5C9LSPTPFt3G57ztQ0eXS9LlsIk9YUrIiwYPsks2BO/kQN4c=
SAEN
-CG3/nr30qWl5Hdbw4pgSsqkWE302zfAyYELfrXub12qetqxTk3ZOwiXV2xfzSc+nqLZz5mBr=
1SAD
-gDNOQtBgatkm2ZsIRqM3R2uCjpDXbmzJi/zedwMeYejqviXdcN4l0KsMPWc+JoOFQSZS0k32=
XuCs
-ESYZAQKhNAmVR7wzU/vloRd2sKA3WYQgQCCK27JduvJ+Q6UKmECGTamfx/cru5OBUbxSz8cH=
O2Xr
-ZbKGvDUHx7/hQx/f32PD+9naj+88IocUETrJ6t3Hx9ij/+jaKQBA0ANoegJI5EuRna3h9Hed=
eCxZ
-TQ+K+113KZruWs6rVHbY5Eww6Za9JxnDfmITD3LKsfE6BpCBdjcdiC4UgzLAg/I9Tg9adVDd=
r3/3
-Z5iHNlCUdNAbn9RmbSTH3FUCwYveW+tLDl9CaNuIU2OD9ohWQY+xv4PW9d0p8TGomNjHA05u=
1EyF
-TQ/S5a7G/Sx43PdJgEhJCELhwLRl40kq5C4/xyP4b8iXL52KCJaz92Lr899XFZgDKv2SpzU0=
YfAI
-vuzKPm0DcpntKuwi6ON/KrMwyAoagHuYA03Nx7JNPPXYyYXagZpsF0YxlMIhjC9iG0WzZtT/=
2Ypf
-Zb094vAwnlZx8ypF8TiSVHQ8xynQFLGdX5VapFEEDaL/qkIr7Xk6rczoSPiayCsYWmiJaASS=
AJc4
-gqZcGkOIjs+DKbGNGm01Mkg7w7ydGUtM0280zRD0GFE14vZu8grBf8nsvNdAok0NGJ6X3OTv=
zwfO
-ez+KtowJTzcRrWWEVtslzKq8j7lqx9SsyjhiZ5P5PqJkHk0riz323ED2CHt0qREEQRU9w+Mz=
tkHu
-7UOsh46HBigqiw84wqSf1EN2YtLBCZyjBiTRQwPYQQDbaXrsNbb12ZeOh287RpMuNooPf0Fm=
+URV
-YvfynZyci83N3XRQ6gd7STDw0dMYQ+h/K5PIVcpFOhYiyxV0HAjNU8Ask7YPDvUepigv92kZ=
dfXY
-+LXXcC8NDMxQWho2kgISGzGbt5sstvN3G6xA6bgnE1TNfeMxuNBr3cOHEgi59Qc24ac9G1uR=
3jN1
-OUG/usNWnlCqbbks9M4145Sa7iYsMZbK0VlpxsZA/FmadgUzko/ermAowZ/BXUI1/ieqUq3g=
Rgx8
-RwGiJOUhkZkDrEPBP4KyQNrXSK7Qq99qlUDXQSqcAsmSxPTQpzKsVDQSskUnpwKRhyTLfaME=
vzZF
-XxKKpkVbkTC5fQVDy6A5yBKwzaZGRjSGJAYP08DlDJ/B1782MmfDfz6vQbTDEE4gzJUTkMNq=
x3sr
-LMhvgqlptqx2Ofc1eH923LWY2sPkwQBRm4DuyJZQgwwBNJGdSKM51/wfNfBDKF54Kp6yWxSh=
kvDW
-rxmOVHtr4tg4Y3JNUNZCbfltxHk/WRTXw6CwcSTDMCQDhkN6YiEm5Ylm9uoliwFSqAGrNm1m=
5KQG
-a0dPjSRYAwgwgqh0mQO6QvhHL1Ojz9PKpWjTu8NzcHx33tsL7jcT/mH/jC8bA4leezU+7Fhj=
DBZx
-UxuBPw1HyEHgX7lg4G4lIKyk80gAWZOWoip6GhE8cqxAJhjjcRYHdeThw2rEHrdOPDs9WGKW=
W6ne
-L8076E28CzdmYQRWGDU+BkTo6i+yqj2nEIoRzoofPj7jV1aC42T/gw+Or0+Tl/XJz/WWdP3f=
33uO
-/m/2P1rMFtwJpEB0BoC43pmoKJ34aASxtHkHcmRWO+zIqyvr9L1SXoMQo8fmhKvpugfTXKN3=
BW0b
-86npKcx3Ws1295kz3sz62sg+RHkRPuzUmjB9LzFA5a+fruRsn/q8K/xrMS76GgNSu8PRUn65=
sN/y
-JrBrRAMO8X63PNUXwIS9qMGy9CBaTI3i032OtreYV7Jevm8KBIHSXLZ7JNF5ovnaFKEK3PMO=
3DoF
-r2SGApOENM8jhQ21cp7PemagFSwDtkANILIFYzFJKFGJxQElEnE42tMNCbZb2pvfF41jYbM5=
wjgs
-MUPNsHwb8TPlavGXN6eFU8jIZVWoGaPjCMXfmH3hypnCVYVEsgIxWzqfsULgSJfnsFS+L3xu=
MFtU
-JbNXks8aM4DNMoZk5pZIHMgLoP65zz4tc/DakwLDsNJTwMiC7V8MWAZK9zgDv/zxZGRTH4ay=
+pPB
-f47dy4tZ3tps1rmgkhQYp/5wvu0BkbvaejabG0aDsL+2MBsRwpkuMayM1Gf0zC9fnSTWZJ3w=
KYPX
-e3dp4wKOr4Os+VAetys61z2cZbTGrf/jdXwjv5872ezhOhPDAKMlS2yg0QlUpQMxqRbi1EDI=
Yf0v
-gjMTdbHTVhr6bOUrUkMGtjB5w97NGSUwi5c4+EuLoHcTG9wWCyHsCLmE+NyowvaZQ8QiC7T6=
cLfE
-yoMGtXtZmnkWrV6dkPLDwXi0WpFkBaPAd0zaZ+LqF74/KDei+55YfglL6tV1jEzjlJwDLtcF=
YHki
-52sFIKfbwOY+7E8V32Opfgsa5Ib2KBJvj8FPjRJBdx0wqbjxFrVeZtr3rdaKFE4Wm31uGM7n=
zJww
-eX73O14WP3nx+BmkOiMqTnJIkr2qaVDQM0hBbDM94+Nrnj1qcl/yyOmekKICVFTT66NxuhTK=
ZIkt
-UIRusGSB1oIxMGEDgIhI8+RisfStaB18y+acjgUEweNYjbk2csJm855knl4DOFDfmTmyT1fa=
kTaJ
-RNHAoQMI7ib0OdswW8+7cCGczCtXY0mTOy06XDWdMdwNqksE8CUidZfI7vzDTf2ZARnRurMN=
s8GA
-wYIuNK9ccCMOPBSzjZpD/BWpK+QHxnWXrdqkZjYMBgvT0cp/DakWaLNx4T0c06tjjSKAjTRn=
TpIU
-kLPffsxM0hUjdSzJHWGlePUnmOwMwWUEKWCi6riqhWVaaFANsDZOcXEGAgTmTjTzr/O9r3F+=
l8bh
-rr2zpvGROewJ3LQY7Sk0g1256eU1juBENbBkogwZ+pyKShGvGXE2rrLutfM6/r/7q8QVjmrk=
KNcm
-454VBq9WOSJyKkQimrLDVMi/jWwYeHTgpyqC6smdElpCYOWkWw25k7gDdav5sNiA+A9Fw0Qb=
Uvnm
-QCvdTYeahEAXhTUOA3GUBCkKVRPQ/RkQ1lfRJSQ9O4bKjauJBZZADLZ5WIM25gkFKDuUQdmC=
YsCm
-ODFWZQzY63NSXDVMJd6uPgRj2OVlaruEMRpiGuZnTghMGebliomErLqHuRmsUxwms9ccXL6Z=
pO5p
-cMTeQEqjGu9aUZmHaGC7YhBPgmML5uxYDHxsopGeYpQxjTh4iKMtsfZtosG41QQ9l9WmidPd=
NKBj
-nBekiBdIwWOH0dOEUeQtPLXM96zyEWdgRPyt9BHAQne1Y+D5GScxsTvT3PY9bmaKI2KwqJgO=
WgS3
-Iu0yxnOLWazFfy0AlTGXOvGQhmA1EqjM4yjJYGlMSHtqzxDMm2uF9lgYYGB+phcZYyTVmol9=
C4Jj
-Q1KX0bH7D9yhh16ufa8/hUJvnHpUzexU8XvVB2SJM13sPx32LfP58/X7fqI30y7so8p0u/KA=
9s1z
-2vqZt+RlDI2Ikdsw5DEjZMUjqjqK6tO7OHeIDIcPbgbgahJvqmfwMi70CRr4sSE3bBiSOqaE=
8yEh
-pui7x3AO3wuCfSc+mpitbEfRDSxGZr5U+ISyGUXVglpmcgntVcmY7KnYQxjFjUdelILTRtHV=
nWhZ
-iJtkKLK5vE3DO//h1mJV5D2XzU8Cn1gfvjBxDKARA2siXT3FpjmhUESa8jORu63DiI4cOFst=
CWfW
-mmOq688biIiHrlhOy7DrVrNvEKYlkK9eqNzYBcEGQ8aaDssiqq7tILG6xfkzUNopOX7/mXJn=
Cs5n
-RWb0CR0jF0yHQ0qTGOk8Wfr0bvmqMRBuqAyGo7ejEZcx9yhgzM0eUdnf5Poy2zQt1GOjtqmg=
sIW0
-0X8LIz06B4qN92mAG2MmyTIxmqwarDLaCCcTU7ML6unv4MPh0kp2bRaLNPeh0two3voe79vz=
upzP
-m6brs46loSbSLouhIzyiFnDEkjV6ORIMIGVA25qQBIsFzzCjDgUTe7Cc5jIIAmDAGiAa2P+8=
trdt
-CcQ9N9pYTyEJ5hBXsjR+wG+i552kh4XyTbrwgWIqGEmr6pmGMUKs7kswFj7HpKQSXyj5cG9Z=
Q1u+
-TFvOZmKAyUh6dx/b9X2UWpgQ7pLZHB99NEJNHcV9t2nlZqb17+8MqYs6G3BwjpCevgHBnh99=
QYDs
-WdM4zC6e0LJZUmIQGzaLGDK5/0/7Z3JVA6e83EzNrpDk4n0iSpenTMRgJoYJCxQ+n+f8t7nJ=
n1a9
-6e5tIR140NovoAX/8XckU4UJAK1QopA=3D
-=3D=3D=3D=3D
Index: sys/contrib/dev/nve/basetype.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/basetype.h (revision 261434)
+++ sys/contrib/dev/nve/basetype.h (working copy)
@@ -1,281 +0,0 @@
-/***********************************************************************=
****\
-|* =
*|
-|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL=
*|
-|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY=
*|
-|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT =
*|
-|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED =
*|
-|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A=
*|
-|* PARTICULAR PURPOSE. =
*|
-|* =
*|
-\***********************************************************************=
****/=20
-
-
-/*++
-
-File:
-
- basetype.h
-
-
-Abstract:
-
- This file contains the base type definitions used by the networking dri=
ver.
-
-
-Revision History:
-
- SNo. Date Author Description
- 1. 2/7/2000 AJha Created=09
-
-*/
-
-#ifndef _BASETYPE_H_
-#define _BASETYPE_H_
-
-#ifndef IN
-#define IN
-#endif
-
-#ifndef OUT
-#define OUT
-#endif
-
-//
-// Useful "types"
-
-#ifndef NULL
-#define NULL 0
-#endif
-
-#ifndef TRUE
-#define TRUE 1
-#endif
-
-#ifndef FALSE
-#define FALSE 0
-#endif
-
-#if 1
-//
-// Don't use as these are going to be deleted soon. Use NV_ instead
-//
-#define VOID void
-typedef VOID *PVOID;
-
-typedef unsigned char UCHAR;
-typedef UCHAR * PUCHAR;
-typedef unsigned short USHORT;
-typedef USHORT * PUSHORT;
-#ifdef linux
-typedef unsigned int ULONG;
-#else
-typedef unsigned long ULONG;
-#endif
-typedef ULONG * PULONG;
-
-typedef char CHAR;
-typedef short SHORT;
-typedef long LONG;
-
-typedef unsigned int UINT;
-typedef unsigned int *PUINT;
-
-
-#endif
-
-
-#define NV_VOID void
-typedef NV_VOID *PNV_VOID;
-
-typedef unsigned long NV_BOOLEAN, *PNV_BOOLEAN;
-
-typedef unsigned char NV_UINT8, *PNV_UINT8;
-typedef unsigned short NV_UINT16, *PNV_UINT16;
-#ifdef linux
-typedef unsigned int NV_UINT32, *PNV_UINT32;
-#else
-typedef unsigned long NV_UINT32, *PNV_UINT32;
-#endif
-
-typedef signed char NV_SINT8, *PNV_SINT8;
-typedef signed short NV_SINT16, *PNV_SINT16;
-typedef signed long NV_SINT32, *PNV_SINT32;
-
-
-#if defined(linux)
-
- typedef unsigned long long NV_UINT64, *PNV_UINT64;
- typedef signed long long NV_SINT64, *PNV_SINT64;
-
-#else
- #if _MSC_VER >=3D 1200 // MSVC 6.0 onwards
- typedef unsigned __int64 NV_UINT64, *PNV_UINT64;
- typedef signed __int64 NV_SINT64, *PNV_SINT64;
- #else
- typedef unsigned long NV_UINT64, *PNV_UINT64;
- typedef signed long NV_SINT64, *PNV_SINT64;
- #endif
-
-#endif
-
-#ifndef _AMD64_
-typedef unsigned int NV_UINT;
-typedef signed int NV_INT;
-#else
-
-#if defined(linux)
-
-typedef unsigned long long NV_UINT;
-typedef signed long long NV_INT;
-
-#else
-
-typedef unsigned __int64 NV_UINT;
-typedef signed __int64 NV_INT;
-
-#endif
-#endif
-
-
-//
-// Floating point definitions
-//
-typedef float NV_REAL32; // 4-byte floating point
-typedef double NV_REAL64; // 8-byte floating point
-
-
-
-//
-// Bit defintions
-//
-#define NV_BIT(bitpos) (1 << (bitpos))
-
-// NV_BIT_SET=20
-// Sets the specified bit position (0..31).=20
-// Parameter bits can be 1 byte to 4 bytes, but the caller needs to make=
sure bitpos fits into it.
-// x =3D 0xA0
-// NV_BIT_SET(x, 1)
-// Result: x =3D 0xA2
-#define NV_BIT_SET(bits, bitpos) ((bits) |=3D (NV_BIT(bitpos)))
-
-// NV_BIT_CLEAR
-// Clears the specified bit position (0..31)
-// Parameter bits can be 1 byte to 4 bytes, but the caller needs to make=
sure bitpos fits into it.
-// x =3D 0xAA
-// NV_BIT_CLEAR(x, 1)
-// Result: x =3D 0xA8
-#define NV_BIT_CLEAR(bits, bitpos) ((bits) &=3D (~NV_BIT(bitpos)))
-
-// NV_BIT_GET=20
-// Gets the bit at the specified bit position (0..31)
-// Parameter bits can be 1 byte to 4 bytes, but the caller needs to make=
sure bitpos fits into it.
-// Result is either 1 or 0.
-// x =3D 0xAA
-// NV_BIT_GET(x, 1)
-// Result: x =3D 1
-#define NV_BIT_GET(bits, bitpos) (((bits) >> (bitpos)) & 0x0001)
-
-
-// NV_BIT_GETVALUE
-// Gets the value from a 32 bit ULONG at specified bit position.
-// Parameter bits needs to be 4 bytes long.
-// Ex. ul32 =3D 0xFEDCBA98
-// ulVal =3D NV_BIT_GETVALUE(ul32, 3, 0) : Gets value from Bit position=
3 to 0
-// Result : ulVal =3D 8
-#define NV_BIT_GETVALUE(ulOrigValue, bitposHi, bitposLow) (((ulOrigValu=
e) >> (bitposLow)) & (~(0xFFFFFFFF << ((bitposHi) - (bitposLow) +1))))
-
-// NV_BIT_SETVALUE
-// Set a value in a 32 bit ULONG at a specific bit position.
-// Parameter bits needs to be 4 bytes long.
-// Ex. ul32 =3D 0xFEDCBA98
-// NV_BIT_SETVALUE(ul32, 0xF, 3, 0) : Sets value at Bit position 3 to 0=
-// Result : ul32 becomes 0xFEDCBA9F
-#define NV_BIT_SETVALUE(ulOrigValue, ulWindowValue, bitposHi, bitposLow)=
\
- ((ulOrigValue) =3D ((((ulOrigValue) & (~ ((0xFFFFFFFF >> (31 - (bitp=
osHi))) & (0xFFFFFFFF << (bitposLow))))) | ((ulWindowValue) << (bitposLow=
)))))
-
-
-#define NV_BYTE(ulus, bytepos) ((ulus >> (8 * (bytepos))) & 0xFF)
-
-
-#define SWAP_U16(us) ((((us) & 0x00FF) << 8) | \
- (((us) & 0xFF00) >> 8))
-
-#define SWAP_U32(ul) ((((ul) & 0x000000FF) << 24) | \
- (((ul) & 0x0000FF00) << 8) | \
- (((ul) & 0x00FF0000) >> 8) | \
- (((ul) & 0xFF000000) >> 24))
-
-#define NV_FIELD_OFFSET(TYPE, FIELD) ((NV_UINT32)((NV_UINT64)&((TYPE *)=
0)->FIELD))
-
-#define ADDRESS_OFFSET(structure, member) ((NV_UINT32) ((NV_UINT8 =
*) &(structure).member \
- - (NV_UINT8 =
*) &(structure)))
-
-
-#define NV_MIN(a, b) ((a < b) ? a : b)
-#define NV_MAX(a, b) ((a > b) ? a : b)
-
-#ifdef AMD64
-#define PNV_VOID_TO_NV_UINT64(x) ((NV_UINT64)(x))
-#define PNV_VOID_TO_NV_UINT32(x) ((NV_UINT32)(NV_UINT64)(x))
-#define NV_UINT64_TO_PNV_VOID(x) ((PNV_VOID)(x))
-#define NV_UINT32_TO_PNV_VOID(x) ((PNV_VOID)(NV_UINT64)(x))
-#else
-#define PNV_VOID_TO_NV_UINT64(x) ((NV_UINT64)(NV_UINT32)(x))
-#define PNV_VOID_TO_NV_UINT32(x) ((NV_UINT32)(x))
-#define NV_UINT64_TO_PNV_VOID(x) ((PNV_VOID)(NV_UINT32)(x))
-#define NV_UINT32_TO_PNV_VOID(x) ((PNV_VOID)(x))
-#endif
-
-#define NV_MAKE_TAG32(s) (((NV_UINT32)((s)[3]) << 24) | ((NV_=
UINT32)((s)[2]) << 16) | \
- ((NV_UINT32)((s)[1]) << 8) | ((NV_=
UINT32)((s)[0])))
-
-#define NV_MAKE_TAG64(s) (((NV_UINT64)((s)[7]) << 56) | ((NV_=
UINT64)((s)[6]) << 48) | \
- ((NV_UINT64)((s)[5]) << 40) | ((NV_=
UINT64)((s)[4]) << 32) | \
- ((NV_UINT64)((s)[3]) << 24) | ((NV_=
UINT64)((s)[2]) << 16) | \
- ((NV_UINT64)((s)[1]) << 8) | ((NV_=
UINT64)((s)[0])))
-
-typedef union _NVLARGE_INTEGER {
-
-#if 0
- // NO UNNAMED UNIONS ALLOWED !@
- struct {
- NV_UINT32 LowPart;
- NV_SINT32 HighPart;
- };
-#endif
-
- struct {
- NV_UINT32 LowPart;
- NV_SINT32 HighPart;
- } u;
-
- NV_SINT64 QuadPart;
-
-} NVLARGE_INTEGER, *PNVLARGE_INTEGER;
-
-
-#ifndef LINUX
-typedef unsigned short NV_WCHAR;
-#else
-typedef unsigned long NV_WCHAR;
-#endif
-
-typedef NV_WCHAR *PNV_WSTR;
-
-#if defined(linux)
-#if !defined(NV_API_CALL)
-#if defined (__i386__)
-#define NV_API_CALL __attribute__ ((regparm(0)))
-#else
-#define NV_API_CALL
-#endif
-#endif
-#else
-#define NV_API_CALL
-#endif
-
-#endif // _BASETYPE_H_
Index: sys/contrib/dev/nve/drvinfo.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/drvinfo.h (revision 261434)
+++ sys/contrib/dev/nve/drvinfo.h (working copy)
@@ -1,190 +0,0 @@
-/***********************************************************************=
****\
-|* =
*|
-|* Copyright 2001-2003 NVIDIA, Corporation. All rights reserved=
=2E *|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL=
*|
-|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY=
*|
-|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT =
*|
-|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED =
*|
-|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A=
*|
-|* PARTICULAR PURPOSE. =
*|
-|* =
*|
-\***********************************************************************=
****/
-
-/* =20
- * This file contains the header info common to the network drivers an=
d applications.
- * Currently, these applications include ASF, co-installers, and qstat=
s.
- *
- *
- */
-
-#ifndef _DRVINFO_H_
-#define _DRVINFO_H_
-
-// Switch to byte packing, regardless of global packing specified by the=
compiler switch
-#pragma pack(1) =20
-
-//////////////////////////////////////////////////////////////////
-// For the ADAPTER_GetStatistics call used by qstats. This=20
-// is the template used by the legacy driver.
-#define MAX_TRANSMIT_COLISION_STATS 16
-
-#define ADAPTER_STATS_LEGACY_VERSION 1
-#define ADAPTER_STATS_RM_VERSION 2
-
-typedef struct _ADAPTER_STATS_V1
-{
- NV_UINT32 ulVersion;
-
- NV_UINT32 ulSuccessfulTransmissions;
- NV_UINT32 ulFailedTransmissions;
- NV_UINT32 ulRetryErrors;
- NV_UINT32 ulUnderflowErrors;
- NV_UINT32 ulLossOfCarrierErrors;
- NV_UINT32 ulLateCollisionErrors;
- NV_UINT32 ulDeferredTransmissions;
- NV_UINT32 ulExcessDeferredTransmissions;
- NV_UINT32 aulSuccessfulTransmitsAfterCollisions[MAX_TRANSMIT_COLIS=
ION_STATS];
-
- NV_UINT32 ulMissedFrames;
- NV_UINT32 ulSuccessfulReceptions;
- NV_UINT32 ulFailedReceptions;
- NV_UINT32 ulCRCErrors;
- NV_UINT32 ulFramingErrors;
- NV_UINT32 ulOverFlowErrors;
- NV_UINT32 ulFrameErrorsPrivate; //Not for public.
- NV_UINT32 ulNullBufferReceivePrivate; //Not for public, These are=
the packets which we didn't indicate to OS
-
- //interrupt related statistics
- NV_UINT32 ulRxInterrupt;
- NV_UINT32 ulRxInterruptUnsuccessful;
- NV_UINT32 ulTxInterrupt;
- NV_UINT32 ulTxInterruptUnsuccessful;
- NV_UINT32 ulPhyInterrupt;
-
-} ADAPTER_STATS_V1, *PADAPTER_STATS_V1;
-//////////////////////////////////////////////////////////////////
-
-//////////////////////////////////////////////////////////////////
-// For the ADAPTER_GetStatistics call used by qstats. This=20
-// is the template used by the FD.
-typedef struct _ADAPTER_STATS
-{
- NV_UINT32 ulVersion;
- NV_UINT8 ulMacAddress[6];
-
- //
- // Tx counters.
- //
- NV_UINT64 ulSuccessfulTransmissions;
- NV_UINT64 ulFailedTransmissions;
- NV_UINT64 ulRetryErrors;
- NV_UINT64 ulUnderflowErrors;
- NV_UINT64 ulLossOfCarrierErrors;
- NV_UINT64 ulLateCollisionErrors;
- NV_UINT64 ulDeferredTransmissions;
- NV_UINT64 ulExcessDeferredTransmissions;
- NV_UINT64 aulSuccessfulTransmitsAfterCollisions[MAX_TRANSMIT_COLIS=
ION_STATS];
-
- //
- // New Tx counters for GigE.
- //
- NV_UINT64 ulTxByteCount;
-
- //
- // Rx counters.
- //
- NV_UINT64 ulMissedFrames;
- NV_UINT64 ulSuccessfulReceptions;
- NV_UINT64 ulFailedReceptions;
- NV_UINT64 ulCRCErrors;
- NV_UINT64 ulLengthErrors;
- NV_UINT64 ulFramingErrors;
- NV_UINT64 ulOverFlowErrors;
- NV_UINT64 ulRxNoBuffer;
- NV_UINT64 ulFrameErrorsPrivate; //Not for public.
- NV_UINT64 ulNullBufferReceivePrivate; //Not for public, These are =
the packets which we didn't indicate to OS
-
- //
- // New Rx counters for GigE.
- //
- NV_UINT64 ulRxExtraByteCount;
- NV_UINT64 ulRxFrameTooLongCount;
- NV_UINT64 ulRxFrameAlignmentErrorCount;
- NV_UINT64 ulRxLateCollisionErrors;
- NV_UINT64 ulRxRuntPacketErrors;
-
- NV_UINT64 ulRxUnicastFrameCount;
- NV_UINT64 ulRxMulticastFrameCount;
- NV_UINT64 ulRxBroadcastFrameCount;
- NV_UINT64 ulRxPromiscuousModeFrameCount;
-
- //Interrupt related statistics
- NV_UINT64 ulRxInterrupt;
- NV_UINT64 ulRxInterruptUnsuccessful;
- NV_UINT64 ulTxInterrupt;
- NV_UINT64 ulTxInterruptUnsuccessful;
- NV_UINT64 ulPhyInterrupt;
-
-
- //
- // Handy things to know
- //
- NV_UINT64 ulDescriptorVersion;
- NV_UINT64 ulPollingCfg; // configured for cpu or throughput
- NV_UINT64 ulPollingState; // current optimizefor state.
-
- NV_UINT64 ulNumTxDesc;
- NV_UINT64 ulNumRxDesc;
-
- //=20
- // Useful to determine if TX is stuck.
- //
- NV_UINT64 ulNumTxPktsQueued;
- NV_UINT64 ulNumTxPktsInProgress;
-
- //
- // Rx Xsum Cntrs
- //
- NV_UINT64 ulNoRxPktsNoXsum;
- NV_UINT64 ulNoRxPktsXsumIpPassTcpFail;
- NV_UINT64 ulNoRxPktsXsumIpPassUdpFail;
- NV_UINT64 ulNoRxPktsXsumIpFail;
- NV_UINT64 ulNoRxPktsXsumIpPassNoTcpUdp;
- NV_UINT64 ulNoRxPktsXsumIpPassTcpPass;
- NV_UINT64 ulNoRxPktsXsumIpPassUdpPass;
- NV_UINT64 ulNoRxPktsXsumReserved;
-
-#ifdef _PERF_LOOP_CNTRS
- NV_UINT64 ulNumTxCmplsToProcess;
- NV_UINT64 ulNumRxCmplsToProcess;
- NV_UINT64 ulNumIntsToProcess;
-
- NV_UINT64 IntLoop0Cnt;
- NV_UINT64 IntLoop1Cnt;
- NV_UINT64 IntLoop2Cnt;
- NV_UINT64 IntLoop3Cnt;
- NV_UINT64 IntLoop4Cnt;
- NV_UINT64 IntLoop5Cnt;
- NV_UINT64 IntLoop6To10Cnt;
- NV_UINT64 IntLoop11Cnt;
- NV_UINT64 IntMaxLoopCnt;
-
- NV_UINT64 IntRxCnt0;
- NV_UINT64 IntTxCnt0;
-
- NV_UINT64 MaxRxLoopCnt;
- NV_UINT64 MaxTxLoopCnt;
-
-#endif
-} ADAPTER_STATS, *PADAPTER_STATS;
-//////////////////////////////////////////////////////////////////
-
-#pragma pack() =20
-
-
-#endif // #define _DRVINFO_H_
-
-
Index: sys/contrib/dev/nve/i386/nvenetlib.README
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/i386/nvenetlib.README (revision 261434)
+++ sys/contrib/dev/nve/i386/nvenetlib.README (working copy)
@@ -1,52 +0,0 @@
-$FreeBSD$
-
-The installation and use of this software is subject to the following li=
cense terms and conditions:
-
-License For Customer Use of NVIDIA Software=20
-
-IMPORTANT NOTICE -- READ CAREFULLY: This License For Customer Use of NVI=
DIA Software ("LICENSE") is the agreement which governs use of the softwa=
re of NVIDIA Corporation and its subsidiaries ("NVIDIA") enclosed herewit=
h, including computer software and associated printed materials ("SOFTWAR=
E"). By downloading, installing, copying, or otherwise using the SOFTWARE=
, you agree to be bound by the terms of this LICENSE. If you do not agree=
to the terms of this LICENSE, do not download, install or use the SOFTWA=
RE.
-
-RECITALS
-Use of NVIDIA's products requires three elements: the SOFTWARE, the hard=
ware on a computer motherboard, and a personal computer. The SOFTWARE is =
protected by copyright laws and international copyright treaties, as well=
as other intellectual property laws and treaties. The SOFTWARE is not so=
ld, and instead is only licensed for use, strictly in accordance with thi=
s document. The hardware is protected by various patents, and is sold, bu=
t this agreement does not cover that sale, since it may not necessarily b=
e sold as a package with the SOFTWARE. This agreement sets forth the term=
s and conditions of the SOFTWARE LICENSE only.
-
-1. DEFINITIONS
-
-1.1 Customer. Customer means the entity or individual that installs or u=
ses the SOFTWARE.
-
-2. GRANT OF LICENSE
-
-2.1 Rights and Limitations of Grant. NVIDIA hereby grants Customer the f=
ollowing non-exclusive, non-transferable right to use the SOFTWARE, with =
the following limitations:
-
-2.1.1 Rights. Customer may install and use one copy of the SOFTWARE on a=
single computer, and except for making one back-up copy of the Software,=
may not otherwise copy the SOFTWARE. This LICENSE of SOFTWARE may not be=
shared or used concurrently on different computers.
-
-2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Se=
ction 2.1.1, SOFTWARE designed exclusively for use on the Linux operating=
system may be copied and redistributed, provided that the binary files t=
hereof are not modified in any way (except for uncompressing/compressing =
files). SOFTWARE designed exclusively for use on the Linux Operating sys=
tem but which has been authorized by NVIDIA for use on the FreeBSD Operat=
ing System may also be copied and redistributed, provided that the binary=
files thereof are not modified in any way (except for unzipping of compr=
essed files). =20
-
-2.1.3 Limitations.
-
-No Reverse Engineering. Customer may not reverse engineer, decompile, or=
disassemble the SOFTWARE, nor attempt in any other manner to obtain the =
source code.=20
-
-No Separation of Components. The SOFTWARE is licensed as a single produc=
t. Its component parts may not be separated for use on more than one comp=
uter, nor otherwise used separately from the other parts.=20
-
-No Rental. Customer may not rent or lease the SOFTWARE to someone else.
-
-3. TERMINATION
-
-This LICENSE will automatically terminate if Customer fails to comply wi=
th any of the terms and conditions hereof. In such event, Customer must d=
estroy all copies of the SOFTWARE and all of its component parts.
-
-4. COPYRIGHT
-
-All title and copyrights in and to the SOFTWARE (including but not limit=
ed to all images, photographs, animations, video, audio, music, text, and=
other information incorporated into the SOFTWARE), the accompanying prin=
ted materials, and any copies of the SOFTWARE, are owned by NVIDIA, or it=
s suppliers. The SOFTWARE is protected by copyright laws and internationa=
l treaty provisions. Accordingly, Customer is required to treat the SOFTW=
ARE like any other copyrighted material, except as otherwise allowed purs=
uant to this LICENSE and that it may make one copy of the SOFTWARE solely=
for backup or archive purposes.
-
-5. APPLICABLE LAW
-
-This agreement shall be deemed to have been made in, and shall be constr=
ued pursuant to, the laws of the State of California.
-
-6. DISCLAIMER OF WARRANTIES AND LIMITATION ON LIABILITY
-
-6.1 No Warranties. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, TH=
E SOFTWARE IS PROVIDED "AS IS" AND NVIDIA AND ITS SUPPLIERS DISCLAIM ALL =
WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMP=
LIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
-
-6.2 No Liability for Consequential Damages. TO THE MAXIMUM EXTENT PERMIT=
TED BY APPLICABLE LAW, IN NO EVENT SHALL NVIDIA OR ITS SUPPLIERS BE LIABL=
E FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOE=
VER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS,=
BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNI=
ARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVE=
N IF NVIDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-7. MISCELLANEOUS=20
-
-The United Nations Convention on Contracts for the International Sale of=
Goods is specifically disclaimed. If any provision of this LICENSE is in=
consistent with, or cannot be fully enforced under, the law, such provisi=
on will be construed as limited to the extent necessary to be consistent =
with and fully enforceable under the law. This agreement is the final, co=
mplete and exclusive agreement between the parties relating to the subjec=
t matter hereof, and supersedes all prior or contemporaneous understandin=
gs and agreements relating to such subject matter, whether oral or writte=
n. Customer agrees that it will not ship, transfer or export the SOFTWARE=
into any country, or use the SOFTWARE in any manner, prohibited by the U=
nited States Bureau of Export Administration or any export laws, restrict=
ions or regulations. This LICENSE may only be modified in writing signed =
by an authorized officer of NVIDIA.
Index: sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu (revision 261434)
+++ sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu (working copy)
@@ -1,320 +0,0 @@
-$FreeBSD$
-begin-base64 644 nvenetlib.o.bz2
-QlpoOTFBWSZTWSDHheUAMsL/////////////////////////////////////////////4EQz=
TUNc
-bl2envbuoZ32+6l7UqAC3Z7vc94Or3e71IAA8D6+8zp9Pb2cpz25cy8899HK75hzz68d9fKf=
Z93z
-u9ze3vrw+hRSIffLl3Nd7OXbuFTV73dzoyVHba69t98z7b77dV6ejnXt729noPPc869rl6u9=
bvrd
-ffF7bw3nmPHsD3tY7dmR7Fdua3ZezWgE73uldi+7wLkRt6H3vd76++9o+3ci3rr2zNN6uK++=
CPvR
-5B4YaEQmgATTRoGgIwBMENM0TTBMRiTGk2jRTyYmAmRo0xNMKaMmNMEnpPRpPQp+jUaeUaeo=
wyaU
-/VPGIU9NPTU2VPJtR6npHpHqeSZNPFHpqINCE0ACAmmEGhoTJppiYTTVPDQU2CMGpk1T2U2p=
tQ9U
-8mRpqPNJPU/VPGiniCeTJp6p+qG1PTQ0gemgYUbZTSH6ptE9I08jQj1DCepoDQBpo0EpoQhB=
Gkw0
-Jqep6mJMo/SYTaJPU9I8mp6T02qeKe1T8jSPIeqn6p7VNpqaeptTNTR6m1PSGj1AB6mj1DaT=
1DZQ
-HqDRoZGnqHqNG1A9Jo08po0ZAAA0AZAk0kSImmiYUbQmgp4NJ6myp7TUyNTDU/TU1PRqHpPU=
9TGi
-aepkaZG1NPUPTUB5TQPSepoyaBpkAAAaA00BoaHpAHqaaAAAAyAAAYpCT1NPVR7VDNJ5T1PR=
pPU2
-o9Awp40po8jKB6mQ09T0mI9QPUNqbKaPU9TR6TyaJ6gA9T1HqPKD01G1NqPU9R6mTRppozUB=
kzU9
-J6m1D0RkGnqNBp6h6mj1D0jGoJEiEAJoATCnpiZTwk8pg1MEU9ppqbJpiKeTZJ6Knp5KftJt=
Ggp+
-VPR6VPeqn6ps01TZT0aTzUT9T0pnkk2aTU08pp+qaAeU09qmBNlNPCRp6aZCGjTQ9Q0DQd8s=
sO5h
-vAz8/gqHlJiqlbkKQeWmWEv4AKp5389QWX755RUTliUQIlUUBJzvOWQ/dBn0FK7qi9BFQVGc=
LDJS
-qpnSQsek+Gia16cd8J1fFMT1vNdzKgSAkJwfPE5cxTXvelz7OlHJONaHhLUDaNTb7ne7/Uj6=
q11n
-J5Xt/c/mcvt+4gu72wBTB2mXdUNvKDovb83x0rZj8qfvmZG+OXW0J9WzWsmU932Wr2sGzpLD=
z+ai
-vyKRTxwZxALmGlECIEVBh8i5tpIDBaHG9rhH0v69LptFABhromioVy+CwCrSMw9u7V29cQh+=
RxCI
-vZ72EKc1E9ccLq5pmEN2y+VfjNUhQlIVXNotbVIYXielSdFGFqYP+HlBgefd/ueZIwU0AOp7=
rgeX
-yaiHMUvMm0oz5oWz+vie1BtV8ztPR5eg0nhaTaz7HKxGV6+uoJtjXp71DX0W5tMPkcpu5PYf=
h0Lp
-vxf44Lf29D2+VewONmuR4fybju+dhWnW1f5GJuzyQ/rYN1rFr+fKDtFkH8Fw4MQ/ko+b8asb=
kjhO
-3mIQ9NC99pnCy91a8Z01pIQfWVJ38n1WxMDLp1Ox80F6yptw+Tt37aJ2PK9HCFLZXLI3HMQZ=
NfYn
-A6oeBbd/qGJfEb88pBh+tpVDKeBltS/jt+5n/ZzylBaQpVThO7lX3Xw0Q2XqjCkQkRAh1Ksf=
SsKu
-JVW26T1Hma56furzz0Hor0CHTaj7z0/xNfYdHOyto++xaleYd+kppOdAsnqffmKunXct0l6a=
z879
-d899brk8KPxydedr5Shadjkcbxau7+yL2SVLREO9bQ42XLl0L6FhK+6cenSdawaaz6nNaqyn=
Mlhb
-mAsQCAB8zMuz+Sz5loV2rmMRGC0X07bxMW7ecebtb+sMlThXDdNrggix/7f8ey6vL0vcfhrX=
lSaU
-UcQZavvba49rmZoeeFwwSgRiNzm4+hUk1q6fa1KVue1HZp69cFewoPReX619HmjnqIN6CfYq=
HwAn
-mq36HzS0CGmTOIFBCH0fT/n/l5svL7XrVToOra/T/M+JXRwXO8uuIdVwYZlqjGELusof0Hvb=
Q1jY
-QwPt2mBGwbU68XvcCkwAh4vC0g8smFvObWu87XUMqm/gVkKuHIILqVra+pt71fTXiW/+9vJw=
canx
-v04ECBNoEDNT/aZpsRqJiERK5ANjF/0GVq/uep9UNxSBmZhwUrdDFqzK8dwzprdVeOW2arrF=
tYdY
-7jwv+pWrwMpzqX46CRIMjKgVMDcUPQ+xw8vtB90ZTaEwuRSGVWwgK6MDW5plzu65gvxD4gva=
n0Id
-C2B2yeiVgYwFnqTxwsJ+Vg0S1kCJZm2gQgESDCGklXJs1ZGr9N3+4vodAeSOfBL+tN40laEG=
Rgx0
-MmTzZOZJKtaKX7/s0r169myta1KM2mkozxxTL5Lplzc3lkz0hdBkxLBatPIvPWO1iNwivmYe=
QMgM
-iFJSfv+z6jOtIceXPKFtsg3JD6z4Pr/XfvfvnL2fMsenwU2K2qMFEbNAChQr06oKBeQlEQ2e=
TiWv
-dlvMaHKRNHAIftC3dD6rvG9Btki99jnUDrlN717nWsGxTbZW+E3j3G+ejllEYcXBypJVRSiP=
nU73
-jz0UMJ6thyZEeV55KiqGXLgovV1XYu7tM+WsrBQmmvorZiTwPDNK6aIj9VbrCQGaIgIGI4de=
vEi+
-lj1wzf+K+gh18+LsP4Pm0RW9VPn1cF9csU3SN1ZE6Lomoo1AyVnTzq+lU8hQaQMGTwgq+Czu=
qTd2
-ux3fT9Pv9Pcw4cG7jbEbBpIhoUFFI7KhR6JyRITA601KY4KYpj6dG6o6Gn8zPu8zl9vWvFu6=
8ufJ
-oShobbUxsxeqYqz0dvli8uej5+r5MBFdgG3FmIK2U943E3S3Mb50LaQKohj4qYaxkad3yaad=
VA99
-4oST2mneAm+4PpRYlyjkRvMeZq4ybRRrLF+uvnRM5FiX/LHLuLaPvn5OxyIrVPrQUWn3dGSh=
TOfU
-iIilGQXJJXIQjFmSix7Kv/c7Q/90bIbcyzy0ztC0+DjlW3KWMYBDQNAwhgz9i6NV9DWe2d9a=
jjKX
-L8HJBO7DpkqJrlEKkNfGdEKU+kn3E0Ve6MMCaoCyHQ5J7Tgg4pF1OMx8KQ7zLHHr9Hopqwl8=
bipS
-CBoTD3sScbQsAkaWSgoGDUEGfzKckybR8WlrOLRDOWV9I0tagzMsPS+l9Nhvm9WsO5c/ObCU=
NMiF
-wJzXXUbfoZnSQxDkRaCKwzIijz3cCab02G+IbyDrdC2aTXFHKlKlHeFXzF3lbKLjyp85BZMY=
IZms
-FROaKYJBXAmBIaQTfFcpBkq2S0sBUlwGPUCzCkha9Dvi61SutyQ6zjLTQx1wz5deUGLCKoCY=
Idqo
-JW89t3OrJBeXxz17sXtg7KtcS43xeqzA5JmW2qa1INmkOTjNs6vlevo0pst4legQz3uBpTop=
pX5G
-8Em+RcsNmpkiWzWVV0lutaLxvB2wlTilVRVVTFbwj49P7eqp2eOjNFyXs8+1xPEd6pRKKWlT=
pyZg
-SqxWJXmWvNO3ve5S9PwLy2Gy0FUtqPIuctENdd0Lu1iqdKcmavFybGs6Ccxkoa0vnZMYbHWW=
5Q4z
-WcZOW+KbDh21t3ky3WjnsvCadoI+p5YcM0pllYIqxQFioJTWGmalTNctHLjM42crthpszg0Y=
pNmp
-scM1LarlrbbS2oILNsM2b3mYXndzV27QtsxdQo4+f03G+NcF6a5MFycTfEceHlMRD5BAHRdl=
CgK9
-qg0Gqq+3YtvYp7PGORnmZh7BMu22zsC7iTUxWMXzbLko6s6eOMCV9lV+znZUFrBe0+DQn7Ck=
36Pt
-+M+CFKJ9RGBTxzhNRLcMzCjMzXWta0qmCEw9E1OqclhVPSWuLqZOauDUmsNu9BWMywVlrdnM=
pTbH
-ZYSqkV6COP891OlUvRe78OHYRg5KBbZgLsi2xztTRp/hwlNn5/VtyLNqFSNNhkvhNFC6XTPp=
v26z
-S4jArX0k9QhdzmGnLj46Czz/d6zvLNsVmLysHV83mwm6HtoOuqZSODJ7llEPV+pvqlO35BgV=
x+/M
-qekuneoacOG4j7aHQki6rwqViAiUOWl4RRQxtdNTjT21Q4vCfDJisSys99R5RF0RDtJkmB7D=
tCgc
-5n+Pf8jnO899S6p4fadsq5sw3u+xOx7ek477gwSqdRV8ZByO8zOz4brj32ujMIAVk3Bo3npc=
/u6g
-Pfx8lr1mo9H6v6UqLFkH9D4cEmkkP+pAAQMSbGkAjQYXmrNi19y6Rdl6lOrV9v93AsdG1nMA=
AuRA
-fVPUxSYcugEi9kWC+YLnbpx3DRXGJst2IFDE2C6TR/bslgyrf1+FUs5toRaa8Rwzvq7jZYCD=
zWAN
-g+k4G0eUwqa3TQBevKwsLn393UJHQybiECVUkiJ30N5YKBznPg73g7nHs2lYohAGsNI8lgWX=
QxfU
-/7TXIOI39r3ZU6I8JhDUgeBCHgYB60HxELBA8NDgVCQ2hSYk5MSqyIngyxvtQhqPKYpNuwFF=
arQz
-HIa+Xlq1xsyimty8TSwqG3YjrWSgv65tSZ+ZysNclgxPJu1EpqDOsIH0QgAZgFLP8OXOA76u=
oZsW
-oRnpOrPE1qZaq2wnWzjCyNOkZtCgdnxe1xdG0iyKKr6C3lSsPasCTzGB4HSDTSsZ0dXDr4Uo=
waKz
-QLT049VoRjs4+sT/RnQ0dLm6+zvNye9TDl7H4OvHQ74wHs0goRe4nNJ6QVknxvR06ZgqGQzg=
NBD3
-+Njb+ZQPdcX6hWJD4L4k6VUMLI2PgNEJpeuWW+VwRCditSlWYYbRJi3BO+GBAP6ySdtCBWQP=
AySL
-Ah6xDmkKwFIqiwk+XZAOb0IN6MxgZbCAYyEDfOixSQKMFgRGE8RDmwgbSZEJKKivpWkRWT3j=
PU7p
-82zYkUREZ6NkKefQrIoKBOhqSAsFiMgj7IQk7AM9Q767AFhJpJ1sJ6pgWIxIc0h20neYQ+AM=
JPt2
-ST2rDpQJDhFhWALAOQkxIoAHSwNJoQ+wZITHcSoqgjJ1DIqrBRYiQ8+1fGYVD17WThhUFIIi=
qEKw
-PB8GkNMgdKSChd07SQ0M0govcZijIjDoiSaYTwmsWSTqQj1lgiQY/m2ClGEFIaf/vyT9UGQ0=
xZ2W
-FYxUBSPh0rvg4FyaRRQk62RZJPPQAqBAxUUnvLQ8e0FhBehlE+L26eERkOc+AvCa3/cMlRnc=
mXwA
-bW+U+xDQnmOqPHcCrrDFiCINkhkPmWrmLGhblR0FjtboGNkKtl4s1hYWIH3jM1OA86nC/T6k=
lYce
-y+zi+Vhvhj8Yh91LnuJLJL/aX3+Plnf32/H0f4Lu41R+xe2dZ0Z09/V6asi7/g42GJiWmSjT=
QHpf
-aTpNFTs3NA+gB02o5L0kBW2r6vS9OehgBoSSVDv7k0xB5NrsW4sU5BgklB/PRslGjAv3z/p7=
aGBM
-hoV1a50zlAeMMWv6FiwhzDM15sm/Y27dz+n8Wp/H4/45Ubyy9PXeFtvnpufz/kluf+7dykWo=
VN+l
-JVXffs96kpMjVF3y6Jt0pHBzzuBXWVn7N06/e5bTb1zKNzeuz3oMg6/S7DWDm/VpbPucqKCI=
FtOb
-TTXtlK+F9W7oKGJMh7qxVjPz2lMYFS6xN66ap2fS1zDkf7fFlcnk32T7ibpL+Pfzd7NW0ePe=
5G36
-apIOBwELB8rd7yvcxvYY+HEZwdzurzC083Od4j+EMSUqJkCIF3mkgLmtfE1oP1mELpkAC3Ob=
AhfR
-GFEQKmqONPvn+RqVvVVWcVEJIVsfBPf3pfK+OW+/8/6xMn5C/cRDUqzvW4lhBvNRrbQBkmIA=
WIAl
-94FSRnRNcw1uUHhDxgKD0Mdxrfiy+YbGy8YbMqXQt1GvIq4NgJttlwTNpzBgwVwYMJ68FfMP=
gvLG
-k167PDteG12+suuBiazA+uNlcKxjr7/ufrp3hZzDqPOtN1yOd7a+j7O+tMVyuNGzG5G4F0Ls=
age8
-HRWfy4d7H/jiXlfYRbHNqGzMIMEYz5fwIigo1Y9PBbp95lZa2lo1FM20EPRtrtSoPIh4Gt+W=
g0+g
-lQ0RSoBgyPlb2XhmJfruf+afOQxA+7llouSL3UgGkhCH8iGolvHpxWSUnFTW2dYdGvNQyov+=
i8yu
-yvj5EiRZytnMyJFlZYyzsbGzkSJEiD2tVHrrKReyJ+e2pYcwKqXrlHQIKMwr2rXBQ2aMtQ8p=
HuCy
-XsKiOFqFWgzesR2xvnAqXjmDErXAFpM3VvJ293cUYoP5lnC15MAvAKBgUFGa6VWPe07/VVvr=
a9+v
-8fZqmfVtkmXfnSWi3ln+UpSF6JVLKlAJMfbop+Ceyj1friZ4u1WV2SS0Ek0P3vUI72KP9RMR=
No+6
-xJG00JecwX79VeQoGv8f7f11l2lulCDAIkgWjxhVJkbCz87OmHBb8QyDsPnPkWu6jW5eZrtb=
mul9
-/f+6ojGG4EbHY444499A+dUF0penYOmG50BXG5GMNQboaggY/iwZOFfT97rcNn41F9zuNaJe=
jC5k
-JjxOWIsws91wafs3+B59vSz8/PT2azWD8/z7zaXveywliKU3uD2qpaZRppcwFTQDzMbjhX7g=
txon
-RB4ZV87NvHD8b7HdkYzUn9k+QWNA4IWjkvoyNSlVAbMmjI5DLnXbmTQGdnz5+20MfF1mLtK+=
vg4y
-TfxLPD2RyzBCWj0WozedcDCcEk+kL0f3sLFg7TDwLeDY2zEiRIuBZWVlZWVhZWWMrRDk8WJ4=
Axmq
-/i9Bhxcm1QBxWICNyU7O2KqV9R2MR7TgPH1gQNy/RHw9KJ6/T4EMFo5RYeecEDcfvhwNL01H=
OUQF
-LWMeiU7yRVwO1cuKT/OfLUY9mjscj+XZm8IFX5e5t7+tsF9iwnsxt4kDGTIEYBx5ImQGwIAQ=
ooZj
-SXOAZIDPAY6mEWlrbxySzv1eRCwJPMVwdgzNK1Q9/IgZfFBbL4K7ln6MgGe/NYFmo6oBKJ6v=
hxBy
-oqv0/FIceeMJdlqAQlpsmu7Pbdxc4OJ12LHFVei4qqwz7durXr9kb79r/S5iXeHfX3W43HuD=
HphL
-c3ltnqETG4PSemJQNH1d3NUdAbwwDfxAhSEFmY3/f+t+30M83d+O2QU3s/N/UKRfQZShNhoL=
nBfk
-H+8Nv+JY7HTxV124njwzdUZff/dYxhmkYQzBap4Kx5Nc8HqCgBmt4XEj9Y8a3+2pcIvyfv9O=
iGnr
-Bboe4c5AzA3zNKgALFl+YgG8aUIB4U11WLJMGbQ7DABT20LHhSiBBZ6QNAoIX0/X+8otm3wD=
2J3Z
-g7eIQpmZjuBRhedgdk8P4JIbpiLZH1ih64P03GxHqSkB03yLtZF+A4aiDUum2OulNTlB7vew=
AjbD
-xjZHhea0T5XO06tHXwcz/JXgL5BZybhMntrECMXJqPIK29HSJBUQEnnayVEvjwIEN5Pnf8ba=
58Ui
-iwIsMilwIW42j1i9pLWzp9Fh93NeBoWnH+QomBD29VODWCfDkIg2p12SCjF67CQYuUYGJIWO=
UwNl
-kc7Ma+O3MtseZlxGKZ7zqSu5/DypXr3UMrEGuYHV16uwrOQpDBJCBXSbDHDHAH+sxRGWAQc4=
Cqqs
-c4IuuPu08rJsDZ3u77Vnk+SsAZ9R8//5+FQbyL+q34/y7XWBzE4W9gugXrRYqsBBzc3uwwsZ=
UyIk
-lyMnE2ZLAUvUBkEQEzRu0URW0hwCu9ywUid7ng5fA329vndnpNrr91NsjhVCBx4fEVoPj3is=
MYim
-YIhMHZbG0UNreIJ2z530l4NuA5/wGLn3gpGGGgkStVgWkiotwNpLoe/gMH3P4D/Amt4P8Npf=
ZaEe
-3GFtw/bjP5wzw5fWmb3gkj3xyxhILHalgXR7cKLM1ewteVd/hJ5K2VV56zaa9snezO1NQLxE=
QhRC
-2ZU1FDlWbyiND9GX2F5iGXgNz2UEflEW7OkSkzOQ0y9ARKQpQWY+E0cyzAYyzFuE1V1cfAbA=
81Eh
-0hwkZnZRrWDJfz2IDpGoFqAzRicGOCWrx7PWOkUYx/5B2w2TmYO0LzR4B+jJfBLU5vSFJo3e=
+vNu
-0wm4RXI8qSDE61WgMtMXLcF6BsUeMOOmZn1HPpiQqVL20L+hJ0PM8OWtNErJQHKtYlfm4gII=
coS4
-rOAyrodAv+Z8P/h9TJrB/fxUfLgLQXPA0udz45ukjTfOMyCQyH2js0tss8OOveUP1muInmcf=
sSQY
-vzaO+49BUWKNiaOYapAHIBoJ+qXDSmcopherE5KGxtiX22HKrnqldExINpng3oBJb7E7HAOt=
48zt
-GgeP3SvDAPhGBnG02Jjix0K3sGzTBELCAZeVNM/5gaIdM5wHPmKE55U+Ys6RoTF0b+ZhgWnS=
NLjB
-iTsmyg8EXgKH9x5PGHPzGLXa67XuqBe3QqB234ridP1vuvS6+IznbM7dOx8d6vldUtre3aGk=
feN4
-TXzFK/zOdF9az67f1+V+selPutVOym6N3hL4C9ugy4+5rNllWJeTSigfQyzKs9L3khMPoMmd=
z2ub
-6bXsPA91ihp7GrmqXL6p8XvU28MzsBxIxciPNWowqmjhksdIeQnhg6Bg2cLQQufu0GTDqjJ4=
SMkq
-ZTMLeUEUKH2FZaxXFrF/IPjXlq86+8qA8b8GnFV3VCYoStLohVYO4cYdf71SemaxOUSIYgtq=
f+Uw
-L3H0POWRFsulSpdrduFViF5J9TguQOMgahpGMeZQoIn7I9+GxVZJ+CVRHhBKyksxTz1iMQMg=
oiDo
-HQI47EHr7SlinNO+kUQIpc6iA/Aox4Oeom68UdsMJwNM6JaBo/Rt9Bxke6d7tnTads6cuTO5=
UyP9
-pBJbiGPiWK050GWhGkAQbgdxvp+aDiuzxvJrk0faohlx9MkLy2luWLsx+2usUbLQHxeNOS82=
/GFb
-i8O0PHxoEsRhu+nBd6lg+JdIpCkaYpMOAYfdogBZBgEhDomOIoe2oZj81cVc9LjC/7W6yedu=
7ufZ
-ZZwGWa5mJF8YbYbx7iUHEIV5ggUOVGa0jJcupVSVz6kUrsJmc0rTihJEV+pYyVuBhT2yvex6=
hzoH
-8v4MylKg+B44kkj+EQ6Rc7iqXElaQrEiZ6FO9ve2tdeHIcvCeGT80kWhnIS1xt58fYM98lub=
CgmQ
-0P3U0Wt7+B6c4gE8gMEBDsrDYs6628E1BlpCB13f2/LNhb6oULYwlxqFECrDKcMAHcVh9f27=
Ickm
-rKevE6HTDuJw8cX0h37O9GcbqF55rZRLGGXN4M0q27NX8VB6A2uAyGmzh8PlN9VdsDxfqsZL=
2oPn
-5vGzd5J+4XwsNAh+xHpVsZtHzqztqpRpQ0pYT1JZK277CejRdgFHTrMD79v+PrI8Ed18AaA1=
7Mgv
-BW4oBeI6V4IcyYEuBoMjBqMpGebF8wDa3LlFhTTVPb1oNa3jH2I1oht2Pp7OQ0r53pb6BUnJ=
v0no
-KejEPO9H8t43szfX5dnHDSfyfOpzZxWnCBWeey0O17LKpTHV1tzeFOA9GxSyQOm8O+8hK69J=
PjhC
-QGQhMB+R5TVqkHK/5wc/v4XHUM6J0TnMMw0+5sND1Yta7e9gMnkR7yLdSoJfhxbPZVwNvKjQ=
eCM0
-O63H1lLGPqXgLhArRggRg5AL6ru/Hfyta8K+sZ5DBSTyU2hz3Q0iPi+NQxtqlOTRiYYdTE6J=
Qb21
-WTHJ8iuXSwB67VgsTrV3uX6S3xvoOTAH7WFlKHAvpMaK4YV3jFIMgTJ5MTgbzPrdzN08pAOG=
DoIw
-ytjQsstfnUoCxe/065rOfTbNMyiURsHqPtA+61Rzw9LouNwdQYJkgiIAeZzSE+iXEUglCp8E=
Kqiy
-dU/jU+MgxlbQgSAxzkMsLAZoW67wHUOszeBAypvXLpNdFdBkPSnAyy41jA4nCqK4ZsHIUZD5=
kYQ+
-mQD3LDtYrwLNe7NmuNOHGXi2YJEEt2YQJijtOI6MuNTaSDN6wMyFAEZFkCfZJJCcsoSUZdBe=
QJLW
-wyUTMprVM0zArmAVlZCqHo7MEvENRBImFMSTZVmgq1VBKpSIXCZwcbDVullNMXgN7mUciKIk=
TISq
-wkHj2JfNPgfOnTykh0cUEYwwoXp6DFyXp1hqPBeGAVK5xo1heCw2pNnBW8aUgnF2GapCpKJv=
NYRE
-4SgqjFXIGQDxWIlx2mAco7SRVNWjkyqDJdk1no/cfE6CaIodPLnhTpwuROllk1k0OCJrTM0a=
ZvWs
-dYgLwDLaVZS6wzMYYmGsUzKTK6G3DTMLA7vKzbd1SFzkOh5mrjotCqyiom0rnGhNW1oZhFgl=
ApkW
-ZbrWJIcM5oHJZq0SXjjXLLpm9bXaZt2zqYUSDyLNnENaTMORc3rQjs03KomCXa0s4nFL1hTU=
pNaU
-qiakvFU0QiGmIKzRqId37DsNEi5lVWHizQ8py5SpAvE0zWSU0UITCKQohqpmM+v0nBm1TQHT=
aabM
-jK/SOxOiXX0ph5dC68OlPb8+RrZhYbpbDjbICiwRiMDcMbHNaMNZkmknOwDeuDgDjbrou0yI=
wt5+
-uecmMNbCF4ehJ0cNDgQD4R18TiHAsrvq1DSLplYD1NDZqnT0zEWEmCBs2+h/JvjQ3O0YoQ00=
uSz7
-bXGXjDIVADQjKVYQpfDuB9aynCG8eS7lwO0LxbvwG1FBrELjmVOolggDwKm/mAIanzxT10DL=
8y7o
-iAge+WCggdYW2kVmiLu3RY9J4d15LNajvTlWf/1VAq2a9zINlh2owNhjHE8fcTBu2MSGSCo7=
0ZMd
-0K/S6WNXCtfJjrBNjP6zkvXdTB54X+nsXMaNvvvYaXpChlbWXzkHBxW1DOcfSgvRIO4bbIvL=
QF70
-1xw7rj+YOOppaOiqKmjEGygvUSnOue7qm2xy4J5UgHt/b907kfVxs8ZJ7ZCesVgqhfBYcIfv=
vg8j
-8vv5M6zGK9lB3cYvjuaY9znv7vY3sHjDkmE8E8YyIzi1Wzw5YqAa4xrmMLANyY3vUSUscz0x=
q8QY
-1dOcStUZcMLx1O0ObPPInimSYlMeJNSZi/ebnY5lFJTEMW0whpWHDbSY0BydtEjBmqxsIrP9=
9q8n
-LZF0pSxVtYSxJ1JxmfBMfFkxuEnTQp+8npuhBgJta9/0vhOx72zsJDWT+/f8lHpaedrOcjTR=
WEeD
-Rz8OVQqLxWu2U0au6Mw4lljKxUXqgjjJhPMvHVvmrhWwiuW3YMabChaPCqb/rrB+0W4+ww0w=
JL44
-yw6/xOvbw6qAr44oKUa33h8tWZejG8RYfMF6pt3dFWFBgyffYMw4O7wSFuwK4AHK9bRqbVDw=
OoGr
-jeM9rnSnYsZOh2tFj3MRxD2xsWOQdy0u5PEiUoRgknA47pwR4ZMmyhuIRkOGriQBLc4t3/WT=
MVh4
-jbRJoML0z3RJb4woMifFA+QeBEW94B+8bxqrgyJrFfrYoDwxeOENFpYTnEVxaR2lTkNucm7k=
3PcF
-ObNfClYqFourKrI7v9fI6PsMbhCfNPK0gnOZ/GQtTFJm2ZLGj91r9yyexqVFCNaXtE2OG2TC=
kAWb
-Hx1f26ihYgTjciqu6SLHiSePCOhzpLIC7+YSevaCz+/oHA9XOd2p2p2ff0s4fhtyyW6lMXqL=
/SFf
-pfN4cdG1g8Z/5StyW0MzUFDVcHfhpF5CBVhAHMkT7t96oPT41Ws7GbSQyJ4dukXRQIlgS4GK=
4DoJ
-xIsV8BrGUCwig7gUJbNn72RXlMA7l6D9hk7A+UNq4APvjPF+N6Fsq6BEWv5dtbgPCmnMzHAE=
SuEh
-nXMa0b7hBUfUXtV187PM66+w3TFnTilk3psRhpc/VZn6Wi9mpFUQ3Jgal+A8DXua2Q6nIhcA=
yw1F
-rLzThwcepbyWfBd/Z7vJ8zeTe/Mq4f62ONZ6rm0B498BzlLfIr7M1hO+huVLMM4oop5Iy+Hf=
ISzm
-ACWWcBNb7MeflYjrOuppuBGQB49T8JgL9wWXqAyiYWZp5xgQXKl75U31PMoNm3ue6jgRIlnH=
MIAa
-lEagoH6AeBj8ehgzxotX0Apkjw0AvhVH9M5W9PVvz8Cn9va+7U7Dvn+/saa9/vzPz5W2dTJO=
ylTE
-0YCEUwslmXwGFmYWq6rpydGeDXuPD1t1826GZxtcwC3fphWmTGyJEpSiHKA02QMjZgKkU3JP=
jeT7
-g1pm76bt+03okkds3OnVQwIoxCcl/OY4J0MbjeAn5GpfH7QPimEeTkYrSsQ1z1+5N20OvuBY=
jAcD
-yxJTMaZIbIaLH0oPIGSIZ6NPaNRhmsZvCBsBMEeR7FBQ7LFDwOPsKUtuugZiSWaA0Idlg2Jr=
2RLE
-ZCCMhCZCBKMKMkiM9iZJ5STWoITp54ENPkBZt8QSv4wGySTYQ+RCG5JoTDKHCwkw3WuW65DP=
QzQ1
-mGV5QH0KnWanWnYUOxTlF45zl0HWZtOCopzglF3ZRnGbcmw20t2dC75cuXITbygOCupxBsNs=
3Ddj
-CGpZKMyMqmeQbOZyA4gjBVxorNFYmQoZepqkFJBCOl6Gze4CAWiR774wbC4OxyBspmfVI7lK=
8u56
-5GsrvZwSWAfGmUFBDGwKNiBT4e8mdfieZ3g6uOjlZRCvfHEUcoNW1KrW0oLBOnxeXLovhmjx=
dGvX
-X2nmQ5QSqaRMGipyOn6qAWOTyOuwraSWQ+Rq3D+LT2fe3xYAHWlktFFRYosHq6tAa0whTF9Z=
974o
-ZnvbmCVFPsdWR8nuvUl0svFzC3IxfHowK2ZENH7OGlDSlCEeE5I2OxwylpLLC69x0f/N4NoK=
3AIf
-Bi5M9Hc2KFMXhCRcD4Mg7v778vA327yS+FaO6/9Zv2NK6uCfFHu0Tcx9bo88tj0enkefAlSm=
JpAW
-LE0tzz/W82T+TD8Lb+uKN/DEh4Kl9YA1HPPQgTxlOvJflOk+bDOfgPBLdGB80dUNrPXpS0Rf=
naYs
-QMaBsUkxEq3M5N2XIf9LyiaXXs5Wzsy+JdyMM3xr2/s1IQQx/v+Uo3Revv8i4nqRMnXCSGLD=
4Xjj
-sfZotI4apGLCOYMylQYvx86mo9b6fNLOyUW9sghh4rHs7veZARwoA8xchm9rxQk3gm+VcZjW=
LMA2
-gd+Z9ZVJIfHBM/0ENrjx3Emo3RP84gkb6PDkpM0ebjHNvGvlPl/MwuGjLF2Z1soGmwxjDx7e=
tzpc
-ab6SczeRFGDmMEQgMXWzIAFshMz6KeJOWuojA89xnNwVFWd/QJ09Yya21MabBvWDetC2lLJH=
tUYF
-EBkbuz0ZekmPEKKZ0apEGDGti1VPVe4QjpNJaHgwhycaPqamqaeLhWnuSYEcvCNSAvJeXrp5=
866w
-hVNRJvCpQw4LxgR0eEEiiDGaoV/BNESQt80QmAfjaZAYIG2XUWF9gaukVZrExQwMuGRjmVKo=
kMcD
-hqkhIUu+7tAKvo4eiaHtauqT1FkcLRuYF45efekGEkHnafXlzVqkE2Pp1SQ5ceSI6rhEysYJ=
WRuz
-z+r7NDodX8G0+i0r7/+uOjZcQ5aYCEhgIiBBHNRg0Ioq0IwEArPBfrnxvD4Pszxufn9n4vp+=
zzg2
-1IdPY+eDWiyZ9PUKGKHLiWs6EYutEz6PHq1fXwN8GQc3f8TqUYXD4hCWUydqQ34w0s5bBR2m=
N7a8
-qXz/xdZ7vua3o4sDvYgiHFx/su2A77Pq3+qo8d2hUi9SXs8hxI3Ic744Xp4h/WeJHtvqYhNr=
oO7z
-zbysI+ztt8zfBjXhIuyxe5W8lRa0dOv/JkLsQzzsD19k3XoE8sL4m0MTSb50HYSojGJIlZSL=
BVFF
-kUigpAjhl+d5R+b8i8Vie44QgMPTvVLgYVYtlgZ3IJFf4ffdxVYHzPsZ9uIqnn0oqowWRF93=
7r23
-f+2OOIwVYNg2vKrSkL6IgO/9IOA2+o5hhZnsGxofx/rfYzff5HBa07gBgUwkKsvAKaEgcA0l=
mcQG
-+4Y244OOkarhz66qXGPMrXWW8r5JthYt6Be60sVweWeQg7BF3mqnoHeo5CME8v1655968WqV=
gokl
-CpZZOs5mNgEG7Lmxa/QxjaUu1H4PStyKA9rqbfGta9RaBadr/3Ex6aJoEQUBVIrQCKCu9geQ=
mh3R
-73aCfbDPniERhN4FJyHshkbr9L9of0pYXp4G9Pitpr2+DUVbAfJgwRGYYSY3jbbLeyiSkHvi=
gM3W
-VbemRk9vlniurrGuaDCUR1cPb62LbpKw+QD7EUR+EOG2t3hdeSoBm9Ko3SIKYS32YTYHjyGp=
4sew
-dMnM8oNPB2b2AKfAuMsZDC9Z5fTJzh0HSsz0Id4/HC9wslFHBrRqo+E/dBtysiehYsrOWFRb=
x4xZ
-waNG+iRB8FkAZj0R1mdQeiMdnlfU/uDvb604fgxVRH6hqrH3KUQ76BYTVvgOw667szdJhvc9=
5MYV
-DttFdl0iyY8foU5IsytTjSVnxfpYaIFog2hd3jrqOCE6J1AKkGEKtIr7F9zk6bt7kCBS33aB=
ZjSA
-IrlQAxo9uWv4hATucXr8i4Xs8gt6LwmEKZlnDec2AS7HeOzhD+8Cc8094ItKlug7k43cZCpN=
AOec
-gi/EFdJluRbCoyuAsWHhJbxWqSjUX0mrUPCAevhPErNtlOxyZoCnHxmZjLKRQzyJn0vk4+Ef=
W++1
-n2h3Qh5X5G2222KClaMWNjmZRqmeGosI3nfAVZeYTxSdc10HnFcz6iOxeAGUZXbOzusEPGk2=
9Ozr
-ovKqZVoTjpzw6tK4i3+Y62mOxzmbTWZH2xXR5QLZCjXo+105TQmSGhCGQxDE0CQKK4DwLvE1=
/4cz
-Jrb1b8zkF9Hknui2Syc4zM5vFDMbdSkWBkBwgOlWKBm/UWQqCvwSlGpRjbPtorZOVY0dhZ5u=
yA3b
-2TK6CPGGwkpKxsFqWlsE0NI8Iu1JUNDyiF4h0s1ZuGY2LyWrv6/wNzgtu67fCr2phXYVMqiB=
jL5L
-c9ejN0qgr1tvf6JnqtSYZpJV66rhWpvq5DdCCG6SQU8ADEpAb/8Q8WrbOd4GcrylaNjVL1mk=
Iyii
-QNPMF8HdikRFQB28sIBVaTlPTIQQaWxeIq0QeIMCzgu+UlUQC5k5F/LimRiw9mDhykCIsJiA=
4Or2
-dzSh+LLIYDgg3mGEIDpsIYGF3bgLYqsQZLQiXtHvJ4fzPvLMVEjlJxOhxZXrDnu0OJujplwL=
qDVB
-IIQ1Ed07/RlH0zJEXZIbyE2lNIH/rc18nngXu6w59NPC8882TpC0T5ClEREFEEilaMEVKhUW=
B2Tj
-vd3u9fR0BDfE/Xm5LSJ9apk/Fr2MWSXoTOUgdOTgjwLYSad3VvJdvsN0YLEAeyarcHPV/wKd=
/jiB
-iW0PWDC8ry52YOx7Wz/ZK3Xts1LO9FgMr799whSuNDLMEDTY+VewjZCV+YWNYwAZgnmeGeTo=
SAFs
-Z453uE5RKcTD4T0IXKgDCj0xLeLJXZKGajVD6/D8Kmabeq4ezpxJpd/BwaNeXSpxivB5/zz3=
WpFV
-sqyVq+qupFX4KHMz8BNRjRT29yW8mcq0EFod0/TRCq8rhKY0E5vj7sHNam01tvk+nljq+DLM=
gOYN
-uc9XbZOzDaY2u8yJbeYu89nNKD/DYpkN9x3fp2fP7RZLAhmWnGsBiD3lQRVAEYwhi+R0y0AO=
93tN
-E/HDK4mICD326jvXZS2PauTlxLo9rEKIgWHgLvaMNHJDJO8I2gXXNa3kHYz6NMHod4mpzrx6=
0kaU
-WoWVl8vburY/84WfMYYTDtQFdphNKCr1qwaw9LpsSfAHwKWFrN3yLJP9prgGNaYj5eIZB1eM=
yFnj
-/LjxycNBIE2SbDPInj6768+85pG8FzZMQswY0aIwUXhGiEhoYMjfEV5N/78z1tZrdzy7rzeP=
HGFv
-UjfzVRaLDsXern4MOvqAJW3yRmvFwXe6h+zbR7zn/i9TkbJ/JGROH+GVp4W6wVdDzu88V1Um=
946f
-wWm9SpGvrfTvhntBGfHyH8WzLeXG57FFu2abM+xPyR036jaNeaKh/DtNGj89hcCKVAFboSAl=
q1fE
-1unG19tUykCIEODbfqL/imhXinpkEIZ9A2pIS4Cn6WGZdE0tBNpjvmP/doR434LE3nW/EHVh=
t8fF
-ZwSrxgNh+YMwYclamPdiVAOBpboZcKQgemnFUDXGtQpf7Cp93CieeD/ac5d4yri8nnrD2zDk=
szAz
-mFuGyBkuJIVx4QrcX3c2JwZoTU/7T2JB6b6simKCdFSg4cCBAkIgUEB41QUpAvtyOviUmg3z=
j1cd
-IR0mLPJL6cYI26DwkyhCpRynPLj9EN7FDeWMFN0LIgggsFR2FZaaaz7S9syxBlPOMwYMEYT9=
phc4
-ZfBAoVOrZTEGREp1ZkXWjWuKOmkmJmIhRI6BY6OTJEEW6HfX0bOzjlRJVgZa+RR1vr8NtvsS=
Inj5
-cUEEdwwsWsp35F/B31u3XIIaqr1KcodEGdCey+Q68N77oYfHhImo6bhGE5neYHlNj+LEMvzi=
gQmi
-zw2xz+K/vx8kMvriISu3Y30WPp1kDDxbKCVoTYD3iY9gfXAaHw99sOvrjfhx7UIC9lpUQxpG=
wAz+
-ODv9AmM0NLkUHWKzCbuBKV4purJBJtL8d8Iejy7dmvCRVqU6gXt4oy2hg6vw0AsVIbVpCRMR=
SlX8
-keCf2jUfqJm9cPCUzUtjwKtXIcBDqge9Oo6y+u91XW2nVqor4KBbwWLV7Mocqekz0Rx8b8v6=
c6+z
-7OfE9xfvAtjVtQjPr7jBUTLSN8pAoIZHqlBUT9nZppkQAB6dDKv4Bo+2vIExxK3ItNDm5lMt=
a8vP
-rdCnl+2AhWDIEQaZCYMeS/q/WU+w5+CGmhGjKLadLdM2t05MYpOf4R3vy3Jtxan+/4eUM6fi=
8yRX
-JIklDEiswBsAbBeAxtAs/Le9pJjYYrBK34kEetWkHuqWdaWMOkWlRs+1OugZBD9d0UfozQdv=
U9Xq
-4wDUtOQHgFPbJVh/Htoz55+ZZp2Ifj3OFtRN349KONW+bbkQdXys74fOX5VDkdi/ODOc/Y1n=
yiZj
-np8/odHZ8SwuUmZYXOWxvmVwrlKvhxvoKOdQnQq2jkoJ7S6WnjCoWEctEYOSqyai1UcJYYZO=
0nCM
-IY2BJaqC7SrDSsdN48HoEF4rvnXMJZ02jXcvcLjRinFE5FwIr0YOqhCgUErhDyVJ0QDG4/FR=
b6l6
-5AKaSmbU7fyHjmj2htnd7j+WZ7ZDJ1WowUEEZBEnmnmUoxTIyijqmZERKNUT1tphbClsUpaK=
RSKI
-nwTeYcgtFjEjEUQUn0Igdh6NmzJ67RhjKXk46sqBt3lQHdKhu70ca1tREbdZLiFlzx80iqa1=
QxEY
-j41uqWPsH2HHyfsj7n7n4fcmk2FK5yxJGCURoLEJ43j+pDfQGXyxBvAgm4+BJ/9SNUDzGvpq=
rXi0
-MtDPoGEPfYOH9bpSxHTnv1KsXubnZEjzY4csfx/GrTOo1XJJbob4nTDcmtpvnoKCj5owXxhn=
Y4JQ
-RZzkAxguEPsGZPnDjyGdvgRxtxuM61cpmxrz4gabU6S8UB9rKadVwYDp+nZhhOLMdp7bDF2N=
9AlV
-2zHaLNo4U4+iMNnynKFfrASJEiKFRqWVAwDznZmFLdU4vMFeWP1/Ni6lcobo3V9MqzEuE91E=
HYNx
-zXfkGrEQmXhlM4CT1BPqDajE8qM/RfuGP6Kd5HIowvJbdSjB2bivEagpmEMOGEMc3G91ycq+=
cdFy
-kOar6GFy8G7gfldurCwqE8SZ2xB2Y2zEzK3oke8z7KV3gwCz99G4aSDK7Zwff2cRT5jRx42U=
+SQ3
-enie97CpYSbR7usJ1ehLAqSVc9CXdMUQHlmHidi/67wQ1KHQ+y3OECI/I6t2iwHANFwzAZCb=
Xmm6
-pxCM3AajQ3nh/vzunZdakm6xQhehCgyIk099XuLG7pRJNCHmuDom3jU5GFc7LXoXLbiCo5jS=
+kZC
-+9JBYa/O84hbGdj4sxeaY8cbRp1RA1NmP+zIkDPxHBd3dqWdQRlh5QHzsHnf4e9992Pk9/eb=
CeSL
-VW+1mojIstMHfDK0CfNEGjZDQsHX1x5G+yEy8faCeXBgBmEgoRgFMJm+xllfly25GKM9XRaJ=
FQpG
-DRYpUwajk/lqRn01qWmKQOEU1RmYvDhkjpVFv1LCXoF1ekpmWUyx9X1V25LOIxrAEmZdLkmS=
a2cX
-B5xQMXiyIzaomxtPXkySRivE/BiuFRGIyKzIXUy/LrU0FlrQGoYqXtndwbMgvPsgbcpRiYaO=
NkV/
-UpNZoprkJUjRcad6JygA+6yTCga08+mizjO6qkkWaG8O7OUkPtp0rOwsScghzY9C6Ui6h8kY=
ivkc
-nxrc/Y0kGRFtpUMucOKMKblgMwS7BWxONIMEZ9Ir2ZLLZddf5+7JQh1vpmSdaL6l7W+jw9Hs=
3sJd
-XPQU35hTpZF+lfJTaKbhpmwTfCzmZBmnnZliOWtFaqa1QmeJ39fiKT2fcRjkZgDqEus9L8JF=
+hpQ
-ODMsNNiJmr8/C/PkL1uyxiegur2uKI0Za8Y+7QYdOkP8n8K04Htpbr+HI4zNQGblAM0R4oYK=
WlCF
-An9x1vWa6meJZ6FMGp8ZMy/SMLjPk/u75j+52cfVunIf8KfcK6t3ZFAQH2R8gS9tofqeDg6k=
Vmyv
-bDBYMbayVUCDLyOQMODjuYAP5ATdrjna72gsrsSI0sMfjqm8reI0rH35hLe9VUHarL/a8jpY=
K4wM
-R2CDCkn48bIw8FUcPB5VJF9elWDkPA1Oj6K2ntuagpHrz/BTStgvW6Yk1jGjq9iy6ubWBcED=
z8Vg
-DvkGRDJeQnGtQgSHWONgbFw2oUIqiBReuYfBlNOnfHEN6PaQiQMACot1qLF/IoxFQ7vpcryL=
HQ1L
-vGquouMtPGRBCCBpIKYvPkYltdsPVnbLDmH/xKvhDpQ/Z6O6buYQG0nqpvWULYNUCUip4C1V=
mPZ0
-jLBh20lk2TA8W5vGe98ObkrhoJqu4iFil5PadvTKqd9AmJ7ZfXBghZBleI1ycGOA6FuV2BYu=
003R
-alsBgfmzFZBvRdPOGqjHZNqGVDZvb0lquDsAcHJ7eCR/ctwZkz58v70jEfBeSvtHZ4oTorIA=
WDYl
-fXSclvVERLrGTX+3k9q8HRvjIC4YAs7HfzY41JLlwuxDdOo8PhbHumPsPQ/Y8HwVMyJJoQjd=
Szia
-NdT9blS+HiUn965AemRLyr1CAuDmzhwQjWm4LsZFgZWR3rnYcTIhILiIY3kKzjWWSkZi7k2V=
ttua
-oYS6RSyp+VbGJBEyiGqxPI+QjzrnzPPwWYb8tpAIhVt9iuEyo5FD2L23/qQR2Pt4OjouYFES=
O51L
-Euwwm/knq81iKM6mEeaNNz85sDqSWFzB51wzjD84CDdnYfxXIQ8DhXlNYFxoBLgDKEczQJVS=
JIj8
-DCf3UASyURtlvuKHBTkBg5BCcGUJAfhUIVNE6TrGFEtjmua+tkDaDkD7KbIV0CCsvQW7OnLi=
doB+
-dSBESWQSlAS1o+GJKZ0accxB9LOItr93yzjoLcXLv+OsPOCxSi+fDD070h7nEdV5lbPkkoOA=
zAPq
-HUqLIGUwH1PdrFtgtujzWIQ5ISXFeGHcWpmHYcEZH5Tgb4Ks9On6M9iFN/Whf3MhKOzQT5ib=
IwCi
-Ii4KR6YLlJua5cu4AGjOfMsBsPY0MBjoXJnAaDMe2i1x7WkNPYuDq4QvU73PPD6nElExCSXN=
zepl
-JJKDPxGteq2eh1pVVe3aqqvKL307afmbedv/R6X4DKGesNGC86zmxLfUQFmmCGnmvxfI/H4V=
KPzO
-HGj413rTOVPUKtjrUaNoGJM5TPCE2sUclOUIEpYrZ0xjfUaAvfvc9jljwcdkXK+UMLe1CWK0=
Cvc6
-P9GBgyyWfenqxkOv5fwrpPLZvKau8mXmTbiE6IWThbVwnlWCqXltLVxdSXI3+Jd5TMOUFId9=
uILD
-DMH4l0rbGYlGsBc+b+JYcQtgLlfATa+QZG2VXjUDlNaoW01plDVZudvfb+47Uq0HxWWXrmIE=
WuCT
-NA0KEG8/RglqkQWbPvIhpAyQJBLjnCdwBNucIp1lm5e798Uu6Xe7KcMdKfr16oXKsUr08oSQ=
puI4
-Q8SIw4Z8lRd0at1DztCwwcRHhOjSlfpGNiqy2ZVImUpupM5TJMUAf4mcAw5uDZB4yVQgMzJY=
lkpQ
-CI7gYSCQsWl0vMNw7pYeLGgYT4fG2UB4wQBV8rxTtp5amD8892awYMNMIQsSRwVXOUhXdb1u=
Kz7V
-w4KiwepDFdoEDrt8Q6WKgFJHNvw25+L58uyV2qWp4Zp8MSxi6OdY0CV1zMWrhCic36L4TX6j=
k0+l
-/Y+5wrwbdh8oMZbViBcTJxDb840RUq/4cU0/C3+7+S+aPturo+fSpW/Z9mmLFRjQoVLTofIN=
VlLW
-UoVKcXFwzJS0Wig1paHfcBx+1t2jLoMqvbmqNuNtuZgsXuMqL022ceT8WxS9x9amFh2d8j+R=
N6+p
-11Tteu4mux3uedwTh5lvnT6c+LuTgdiHSPOlVFERE7GsMPoJBKmVnTvAwYIydR43M0anQ07u=
UkNJ
-sUts3dK1/CLeBu0iQzDLtB+1VFo/h5eRe7KgwVWXcMyYzVzdhj0fb6SlwkuI2IHg32V9c73U=
ybBp
-DuOPcXUiXd1QsJnuQfBpXYWMy33OerzGweBarGjuPqYc66UpNeXcg12Nw7PBLvgFuChlYepk=
9gby
-jrVBWxAtyuuTHjToKMu2SMGFYGaZo492it+PmXMbLzTOWC0212ycanf6ct8MoFIYdKx+bLo+=
VtiR
-b090XtSiAbHo5eLlbp0MyFOTZzX3IINzcgxmS1VA4jQEyJJcVbtTPk0FbemODZ6XJTNmqXhd=
u4Zv
-dreUljWi6CZpGadMhsrUdnE1NU7e9uLlMFAJrHCYJOfvM5FMgjLr3ANvmYqmGDRSG93XI9j4=
R0TZ
-ICyQ4YQ8cSHV5c6CD2q62BzToX6ecn5r9AZxXzGl6mhMkLRftUWzKzCjcV6xK3wNzLxetOKg=
EYXv
-eVWLdYuOrGy5ihJISkHTYEBuFJyjBVZ1ptnLnPziLzCfiMR4LBYmFF164w2WvCeS1wH8fp5O=
HilT
-dOnn+zQETufMqJSfYeiJeUM4TO0YeD7Nbn+toH+UY2NjqixKNS3ua/5eBE8rJjR4cTZzmLRN=
T8iR
-xUzv9HyB1HER2tUgVk3M6UNk8/c2TdcCjkzkSIN5HFSCVqvxOrH32ZSF8eBeikrQjaanoIkY=
ERII
-HulIC1l0HusgHbqhAHcxTc+edGgPO1BV3aKNWxGjHitQoUuR2B5lzMMx955uHdWuVEmAuZNZ=
gY0V
-CEUhFk3nQyZT1WcJNCMSQUYhw6E1JEQhNn2d93HnE1qPshpWlX/YBXAOHnwaX9GS4Ytx535X=
RbQV
-F6qGF/eFQsMiiY8RelFuLcTUKE6sw4aD9Kt2pYejJ+pMO5mT2A8q30gld9xxJhUR6OpjiyOD=
SRXT
-ogCRB1rmcSLgQiHnhJcK71wtRAxTfU4y76m+KAoexuwpX9vae8SJu6Rj5xE7ZWqbkB9PCR2b=
9Orh
-Fsw77X2Er40YE9wYfD7mlUNTKia5XXuQ/hWJmoQjxbkYkwdGZsVcuOKlls/GrNMayvRayXa2=
iquv
-hXrOtf/Drs37ndEFDAA3hzDQRanpUd5nER82o9eqthn/iOTmw+LoFtu+Ec1xYDgGU684Yh3C=
bMKt
-8VFmQMc64GhmH4313XafM9In/aJpU93TdicROhvc5MEq7G1x2BaaWJ1IRisnr7T+d8D878Uq=
PgtB
-kl9Wv82/w6V72SWdIrRj8Y8xuknMJ0Kz1wqyxsHgcUS36VFqEcJhkfn+0FewZRXuSK8iHZEW=
EROG
-5K2hYkGboVH3nZzFXkGUsTeZuOYOTC2RkTjDb44QEv4zqclEi99y+Mquz6NTbCHCYKJ/HrJO=
DYDa
-ifF29SGDSPY+4gLHPB7jtD+Y4M1SQy27OL/pcbvn/G37hXw4w3KltkU+59nte25/b8XtM/8a=
EHLJ
-wjuxldlRciSWYcctdnOp7afL8Pu1AdsDBMGyZIuXYNNoC6SLqFFzLlIZq40z1Hv6/+nq+LhW=
7T8D
-CMo4+JZ83S/mK1J6LlcshspfUysoh8uTAcuPNtxzejDeIX69UPPMCAt023DfNpttX8xO8xXw=
aliJ
-KwzQyHYoHM32xlWPFym9QdotzVOawnfVpBpTn1YUxKUKBiSwaOrOYqJnoZELgkXpLAKdqDye=
8rC9
-s3oDgpm+GdshEiUGYGSeFMUrjxGDtrRVMQqBAKMiBOT+tfmU3EqFfDReLvlt/L4bTlgTwpHI=
9mpF
-J70WDTWwUoUcqFC7ZxXnAwfEriQ8lYS+iVE8QSNyzkDv2uCYC43BnCs0NFtJugYTCALO4k6N=
znec
-3u/nu1EyQZt9B010I5f3GxoDioUgoTsB1ZPGPtat1dPnjsJ8wavX+53ULfSMVHaRFxT9MV+j=
6Cex
-3sYMFE+r+yznqWD2umvBRQ9t4HR45qHoMjaRRjcQRsRVsQIQKmHQF/4VITiDHidWZgiLiEAW=
pmlP
-LsPpuDCwTR8zksyJIximTIy0VGYA6L1B8PlA15luABYF78ly3FL8FFUx+3jUkaNWFUDMXTaJ=
7I6g
-Gl771ahmTw9KPRkrWiHf9gYTxPjU0eJM9N9EB5Y9JYtrVVZ+DzMW2Mo/L+tNBrRZYm8onfho=
xUaE
-hOh3dHMR1/CuytPLRKaUbzkvy17pFl/AvHyZYGwYe+ccT370+RTq6OM7LzZjj9N2tY/oKWPl=
so/+
-nl7uwNM2krDxkrPrOLM/0394KPZ8L7Hg0fD86zu973/0GuGYdhKA7d6waBYgnBgX1z802ha+=
15vG
-fxz9E+eYs6vrNle8vURobXnaWHkZvXxS3/7y6iQTGtl2u8hTY8UiLzhHQcOs/sH0O9lU4R4p=
kEq1
-sf3i2uDG2GaxZB80MOA1mmUiYGHhcHC2+nokcgJGuSigCyMABmgUlizNUB4/uBd118Vckt7F=
YYxl
-2AofZ1erzON49NJrdc/DdG7RfWvpLXYRtO4jlQ1fQSxRHGdjeQLWjY1kh6H6uxysfBoNrcjg=
G6bV
-sNnLzOwJbGzmyD/geqhnRBOri73FK+yZtXU35nqcwGMbOhDgoXjHp73bFG+j9jzKN1cye7fy=
mvn3
-bqSTd4Rcgk0KUQoIbM6hmTE6tjy14n1VA/Y1aQtDoe04GbneN6W8aiZfYpiaHF4+WnbzWYT/=
jFYL
-pNBQtPS7KGDVNCVkyBMoEIZYMKQLbxGi6xsTtMgLDA2meBFs6XE5Qsk7dBQZQQnY1Oe62o6c=
36t4
-TggdU58m00/U7729xLY50Y2c49YkJkwYViRGskH5P8a+xom3wLYg0KO7ZXnzEqGR+lgsHi4S=
mxDa
-vYmTVVGKog14b8IdmqeCwX8HnnnlcbtP42MTYeFi39WRAAnsIFaD+cn/rcdfkfbudry+vTv8=
K5qu
-f+WlY9DDfBbflz2r9HrfVQjzsx7dXUUm8n1ztYvhQ7ENAsacxQiMPfgl7Gr+Ks6DFx1fLVJ0=
vN9v
-6OT08VJ3+T63z7/N3HE8jF3+Dg7uu28PKZX78fPW15vI+srPwsK2TW2cua+apptrW8DJfwJH=
U733
-JKoptLHdr8c7D8LmOgq7TfZvLYi9jWgdcgUiADjLhJLPwl76z4B02s5CCScIpyUCICIuxFDB=
2zYJ
-s0SIZ4M6ahruHqIbl6Rt06HRkoClYAwokbTowKUoCIgkYm0oMmMNJQ6pSQSaWBReQyaJsggj=
wGSX
-n1CAv8YxT7Eyff2KAIoyB2nQyQnyo9lkJD2JooQnSkIeFOSB2SNoUUiwEWLEFixY9R4f8HpO=
UnYY
-AbOhpDhToyFiY+kskk6tsvZwR7oTOeQggjNDB6xGn8m6dJJ62Iih2CYG/lWLDCuIj5/k4zuf=
W0tJ
-5sQySTCQBiZDmKkMQgVtoqIttiiT+v7zw+H/F2s4H8xSc4Y3oaK23v2VURWIojDqbytV27Sa=
1LDi
-27os3opje9eGfRunfJcjci4iy2iqThObvVDbIcsMmFO7cwbCptAuLSsOpMZwzw47dCW0637i=
MYwC
-cw/3fxqI4BkB5hhuiS58PK4Cx4+zT/hgAc71UArDKx0d5pXcpvb76myEXZVKgHO07fxvN7WQ=
1+Y2
-ZKVzdT9efaG7Oa+TmTX7/UjtD15109XfGOq5oIK5LI38PscHDwRPr3WG6X9ud/qL0Kvn04cD=
5uJi
-PLlZTv65C9kwB8D7A/bl+OzUvUICWMgUpUcXLSdaj3+lT6qDLhfecjue+QEwo0AWYZWiIi1I=
GbIL
-WmiaD/8XckU4UJAgx4Xl
-=3D=3D=3D=3D
Index: sys/contrib/dev/nve/nvenet_version.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/nvenet_version.h (revision 261434)
+++ sys/contrib/dev/nve/nvenet_version.h (working copy)
@@ -1,29 +0,0 @@
-/****************************************************************** \
-|* *|
-|* *|
-|* (c) NVIDIA Corporation. All rights reserved *|=20
-|* *|
-|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND *|
-|* CONFIDENTIAL *|
-|* TO NVIDIA, CORPORATION. USE, REPORDUCTION OR DISCLOSURE TO ANY *|
-|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA CORP. *|
-|* *|
-|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT *|
-|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED *|
-|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS *|
-|* FOR A PARTICULAR PURPOSE. *|
-|* *|
-********************************************************************/
-
-#ifndef __NVENET_VERSION_H__
-#define __NVENET_VERSION_H__=20
-
-#define DRIVER_VERSION_MAJOR "1"
-#define DRIVER_VERSION_MINOR "0"
-#define DRIVER_VERSION_PATCH "13"
-#define DRIVER_VERSION DRIVER_VERSION_MAJOR"."\
- DRIVER_VERSION_MINOR"-"\
- DRIVER_VERSION_PATCH
-
-#endif
-
Index: sys/contrib/dev/nve/os.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/os.h (revision 261434)
+++ sys/contrib/dev/nve/os.h (working copy)
@@ -1,128 +0,0 @@
-/***********************************************************************=
****\
-|* =
*|
-|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL=
*|
-|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY=
*|
-|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT =
*|
-|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED =
*|
-|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A=
*|
-|* PARTICULAR PURPOSE. =
*|
-|* =
*|
-\***********************************************************************=
****/=20
-
-/*
- FILE: os.h
- DATE: 2/7/00
-
- This file contains the os interface. Note that the os interface is
- itself an OS-independent API. The OS specific module is implemented
- by ndis.c for Win9X/NT and linuxnet.c for linux.
-*/
-#ifndef _OS_H_
-#define _OS_H_
-
-#include "phy.h"
-
-#define HDO_VERSION_STRING "HDR O: $Revision: #21 $";
-
-// This is the maximum packet size that we will be sending
-// #define MAX_PACKET_SIZE 2048
-//#define RX_BUFFER_SIZE 2048
-
-#define MIN_PACKET_MTU_SIZE 576
-#define MAX_PACKET_MTU_SIZE 9202
-#define MAX_PACKET_SIZE_2048 2048
-#define MAX_PACKET_SIZE_1514 1514
-#define MAX_PACKET_SIZE_1518 1518
-#define MAX_PACKET_SIZE_JUMBO (9 * 1024)
-
-typedef struct _MEMORY_BLOCK
-{
- PNV_VOID pLogical;
- PNV_VOID pPhysical;
- NV_UINT32 uiLength;
-} MEMORY_BLOCK, *PMEMORY_BLOCK;
-
-#define ALLOC_MEMORY_NONCACHED 0x0001
-#define ALLOC_MEMORY_ALIGNED 0x0002
-
-typedef struct _MEMORY_BLOCKEX
-{
- PNV_VOID pLogical;
- PNV_VOID pPhysical;
- NV_UINT32 uiLength;
- /* Parameter to OS layer to indicate what type of memory is needed *=
/
- NV_UINT16 AllocFlags;
- NV_UINT16 AlignmentSize; //always power of 2
- /* Following three fields used for aligned memory allocation */
- PNV_VOID pLogicalOrig;
- NV_UINT32 pPhysicalOrigLow;
- NV_UINT32 pPhysicalOrigHigh;
- NV_UINT32 uiLengthOrig;
-} MEMORY_BLOCKEX, *PMEMORY_BLOCKEX;
-
-
-// The typedefs for the OS functions
-typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_ALLOC) (PNV_VOID pOSCX, PMEM=
ORY_BLOCK pMem);
-typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_FREE) (PNV_VOID pOSCX, PMEM=
ORY_BLOCK pMem);
-typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_ALLOCEX) (PNV_VOID pOSCX, PM=
EMORY_BLOCKEX pMem);
-typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_FREEEX) (PNV_VOID pOSCX, PM=
EMORY_BLOCKEX pMem);
-typedef NV_API_CALL NV_SINT32 (* PFN_CLEAR_MEMORY) (PNV_VOID pOSCX, PNV=
_VOID pMem, NV_SINT32 iLength);
-typedef NV_API_CALL NV_SINT32 (* PFN_STALL_EXECUTION) (PNV_VOID pOSCX, N=
V_UINT32 ulTimeInMicroseconds);
-typedef NV_API_CALL NV_SINT32 (* PFN_ALLOC_RECEIVE_BUFFER) (PNV_VOID pOS=
CX, PMEMORY_BLOCK pMem, PNV_VOID *ppvID);
-typedef NV_API_CALL NV_SINT32 (* PFN_FREE_RECEIVE_BUFFER) (PNV_VOID pOSC=
X, PMEMORY_BLOCK pMem, PNV_VOID pvID);
-typedef NV_API_CALL NV_SINT32 (* PFN_PACKET_WAS_SENT) (PNV_VOID pOSCX, P=
NV_VOID pvID, NV_UINT32 ulSuccess);
-typedef NV_API_CALL NV_SINT32 (* PFN_PACKET_WAS_RECEIVED) (PNV_VOID pOSC=
X, PNV_VOID pvADReadData, NV_UINT32 ulSuccess, NV_UINT8 *pNewBuffer, NV_U=
INT8 uc8021pPriority);
-typedef NV_API_CALL NV_SINT32 (* PFN_LINK_STATE_HAS_CHANGED) (PNV_VOID p=
OSCX, NV_SINT32 nEnabled);
-typedef NV_API_CALL NV_SINT32 (* PFN_ALLOC_TIMER) (PNV_VOID pvContext, P=
NV_VOID *ppvTimer);
-typedef NV_API_CALL NV_SINT32 (* PFN_FREE_TIMER) (PNV_VOID pvContext, PN=
V_VOID pvTimer);
-typedef NV_API_CALL NV_SINT32 (* PFN_INITIALIZE_TIMER) (PNV_VOID pvConte=
xt, PNV_VOID pvTimer, PTIMER_FUNC pvFunc, PNV_VOID pvFuncParameter);
-typedef NV_API_CALL NV_SINT32 (* PFN_SET_TIMER) (PNV_VOID pvContext, PNV=
_VOID pvTimer, NV_UINT32 dwMillisecondsDelay);
-typedef NV_API_CALL NV_SINT32 (* PFN_CANCEL_TIMER) (PNV_VOID pvContext, =
PNV_VOID pvTimer);
-
-typedef NV_API_CALL NV_SINT32 (* PFN_PREPROCESS_PACKET) (PNV_VOID pvCont=
ext, PNV_VOID pvADReadData, PNV_VOID *ppvID,
- NV_UINT8 *pNewBuffer, NV_UINT8 uc8021pPriority);
-typedef NV_API_CALL PNV_VOID (* PFN_PREPROCESS_PACKET_NOPQ) (PNV_VOID pv=
Context, PNV_VOID pvADReadData);
-typedef NV_API_CALL NV_SINT32 (* PFN_INDICATE_PACKETS) (PNV_VOID pvConte=
xt, PNV_VOID *ppvID, NV_UINT32 ulNumPacket);
-typedef NV_API_CALL NV_SINT32 (* PFN_LOCK_ALLOC) (PNV_VOID pOSCX, NV_SIN=
T32 iLockType, PNV_VOID *ppvLock);
-typedef NV_API_CALL NV_SINT32 (* PFN_LOCK_ACQUIRE) (PNV_VOID pOSCX, NV_S=
INT32 iLockType, PNV_VOID pvLock);
-typedef NV_API_CALL NV_SINT32 (* PFN_LOCK_RELEASE) (PNV_VOID pOSCX, NV_S=
INT32 iLockType, PNV_VOID pvLock);
-typedef NV_API_CALL PNV_VOID (* PFN_RETURN_BUFFER_VIRTUAL) (PNV_VOID pvC=
ontext, PNV_VOID pvADReadData);
-
-// Here are the OS functions that those objects below the OS interface
-// can call up to.
-typedef struct _OS_API
-{
- // OS Context -- this is a parameter to every OS API call
- PNV_VOID pOSCX;
-
- // Basic OS functions
- PFN_MEMORY_ALLOC pfnAllocMemory;
- PFN_MEMORY_FREE pfnFreeMemory;
- PFN_MEMORY_ALLOCEX pfnAllocMemoryEx;
- PFN_MEMORY_FREEEX pfnFreeMemoryEx;
- PFN_CLEAR_MEMORY pfnClearMemory;
- PFN_STALL_EXECUTION pfnStallExecution;
- PFN_ALLOC_RECEIVE_BUFFER pfnAllocReceiveBuffer;
- PFN_FREE_RECEIVE_BUFFER pfnFreeReceiveBuffer;
- PFN_PACKET_WAS_SENT pfnPacketWasSent;
- PFN_PACKET_WAS_RECEIVED pfnPacketWasReceived;
- PFN_LINK_STATE_HAS_CHANGED pfnLinkStateHasChanged;
- PFN_ALLOC_TIMER pfnAllocTimer;
- PFN_FREE_TIMER pfnFreeTimer;
- PFN_INITIALIZE_TIMER pfnInitializeTimer;
- PFN_SET_TIMER pfnSetTimer;
- PFN_CANCEL_TIMER pfnCancelTimer;
- PFN_PREPROCESS_PACKET pfnPreprocessPacket;
- PFN_PREPROCESS_PACKET_NOPQ pfnPreprocessPacketNopq;
- PFN_INDICATE_PACKETS pfnIndicatePackets;
- PFN_LOCK_ALLOC pfnLockAlloc;
- PFN_LOCK_ACQUIRE pfnLockAcquire;
- PFN_LOCK_RELEASE pfnLockRelease;
- PFN_RETURN_BUFFER_VIRTUAL pfnReturnBufferVirtual;
-} OS_API, *POS_API;
-
-#endif // _OS_H_
Index: sys/contrib/dev/nve/phy.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/contrib/dev/nve/phy.h (revision 261434)
+++ sys/contrib/dev/nve/phy.h (working copy)
@@ -1,164 +0,0 @@
-/***********************************************************************=
****\
-|* =
*|
-|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL=
*|
-|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY=
*|
-|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. =
*|
-|* =
*|
-|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT =
*|
-|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED =
*|
-|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A=
*|
-|* PARTICULAR PURPOSE. =
*|
-|* =
*|
-\***********************************************************************=
****/=20
-
-/*
- FILE: phy.h
- DATE: 2/7/00
-
- This file contains the functional interface to the PHY.
-*/
-#ifndef _PHY_H_
-#define _PHY_H_
-
-//#include "basetype.h"
-//#include "nvevent.h"
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-#define DEFAULT_PHY_ADDRESS 1
-
-
-#define HDP_VERSION_STRING "HDR P: $Revision: #23 $"
-
-//
-// Defaults for PHY timeout values.
-//
-#define PHY_POWER_ISOLATION_MS_TIMEOUT_DEFAULT 50
-#define PHY_RESET_MS_TIMEOUT_DEFAULT 50
-#define PHY_AUTONEG_MS_TIMEOUT_DEFAULT 3000
-#define PHY_LINK_UP_MS_TIMEOUT_DEFAULT 2400
-#define PHY_RDWR_US_TIMEOUT_DEFAULT 2048
-#define PHY_POWER_DOWN_US_TIMEOUT_DEFAULT 500
-
-
-////////////////////////////////////////////////////////////////////////=
/
-// The phy module knows the values that need to go into the phy register=
s
-// but typically the method of writing those registers is controlled by
-// another module (usually the adapter because it is really the hardware=
-// interface.) Hence, the phy needs routines to call to read and write t=
he
-// phy registers. This structure with appropriate routines will be provi=
ded
-// in the PHY_Open call.
-
-typedef NV_API_CALL NV_SINT32 (* PFN_READ_PHY) (PNV_VOID pvData, NV_UIN=
T32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 *pulValue);
-typedef NV_API_CALL NV_SINT32 (* PFN_WRITE_PHY) (PNV_VOID pvData, NV_UIN=
T32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 ulValue);
-
-typedef struct PHY_SUPPORT_API
-{
- PNV_VOID pADCX;
- PFN_READ_PHY pfnRead;
- PFN_WRITE_PHY pfnWrite;
- // PFN_EVENT_OCCURED pfnEventOccurred;
-
- //
- // These fields are passed down via the FD. FD get's them
- // from the registry. They allow one to fine tune the timeout
- // values in the PHY.
- //
- NV_UINT32 PhyPowerIsolationTimeoutInms;
- NV_UINT32 PhyResetTimeoutInms;
- NV_UINT32 PhyAutonegotiateTimeoutInms;
- NV_UINT32 PhyLinkupTimeoutInms;
- NV_UINT32 PhyPowerdownOnCloseInus;
-
-} PHY_SUPPORT_API, *PPHY_SUPPORT_API;
-////////////////////////////////////////////////////////////////////////=
/
-
-
-////////////////////////////////////////////////////////////////////////=
/
-// The functional typedefs for the PHY Api
-typedef NV_SINT32 (* PFN_PHY_INIT) (PNV_VOID pvContext, NV_UINT32 *pulLi=
nkState, NV_UINT32 PhyMode);
-typedef NV_SINT32 (* PFN_PHY_DEINIT) (PNV_VOID pvContext);
-typedef NV_SINT32 (* PFN_PHY_CLOSE) (PNV_VOID pvContext);
-typedef NV_SINT32 (* PFN_GET_LINK_SPEED) (PNV_VOID pvContext);
-typedef NV_SINT32 (* PFN_GET_LINK_MODE) (PNV_VOID pvContext);
-typedef NV_SINT32 (* PFN_GET_LINK_STATE) (PNV_VOID pvContext, NV_UINT32 =
*pulLinkState);
-typedef NV_SINT32 (* PFN_IS_LINK_INITIALIZING) (PNV_VOID pvContext);
-typedef NV_SINT32 (* PFN_RESET_PHY_INIT_STATE) (PNV_VOID pvContext);
-typedef NV_SINT32 (* PFN_FORCE_SPEED_DUPLEX) (PNV_VOID pvContext, NV_UIN=
T16 usSpeed, NV_UINT8 ucForceDpx, NV_UINT8 ucForceMode);
-typedef NV_SINT32 (* PFN_PHY_POWERDOWN) (PNV_VOID pvContext);
-typedef NV_SINT32 (* PFN_SET_LOW_SPEED_FOR_PM) (PNV_VOID pvContext);
-
-
-typedef struct _PHY_API
-{
- // This is the context to pass back in as the first arg on all
- // the calls in the API below.
- PNV_VOID pPHYCX;
-
- PFN_PHY_INIT pfnInit;
- PFN_PHY_INIT pfnInitFast;
- PFN_PHY_DEINIT pfnDeinit;
- PFN_PHY_CLOSE pfnClose;
- PFN_GET_LINK_SPEED pfnGetLinkSpeed;
- PFN_GET_LINK_MODE pfnGetLinkMode;
- PFN_GET_LINK_STATE pfnGetLinkState;
- PFN_IS_LINK_INITIALIZING pfnIsLinkInitializing;
- PFN_RESET_PHY_INIT_STATE pfnResetPhyInitState;
- PFN_FORCE_SPEED_DUPLEX pfnForceSpeedDuplex;
- PFN_PHY_POWERDOWN pfnPowerdown;
- PFN_SET_LOW_SPEED_FOR_PM pfnSetLowSpeedForPM;
-} PHY_API, *PPHY_API;
-////////////////////////////////////////////////////////////////////////=
/
-
-
-////////////////////////////////////////////////////////////////////////=
/
-// This is the one function in the PHY interface that is publicly
-// available. The rest of the interface is returned in the pPhyApi;
-// The first argument needs to be cast to a POS_API structure ptr.
-// On input the second argument is a ptr to a PPHY_SUPPORT_API.
-// On output, the second argument should be treated as a ptr to a
-// PPHY_API and set appropriately.
-extern NV_SINT32 PHY_Open (PNV_VOID pvOSApi, PNV_VOID pPhyApi, NV_UINT32=
*pulPhyAddr, NV_UINT32 *pulPhyConnected);
-////////////////////////////////////////////////////////////////////////=
/
-
-
-////////////////////////////////////////////////////////////////////////=
/
-// Here are the error codes the phy functions can return.
-#define PHYERR_NONE 0x0000
-#define PHYERR_COULD_NOT_ALLOC_CONTEXT 0x0001
-#define PHYERR_RESET_NEVER_FINISHED 0x0002
-#define PHYERR_NO_AVAILABLE_LINK_SPEED 0x0004
-#define PHYERR_INVALID_SETTINGS 0x0005
-#define PHYERR_READ_FAILED 0x0006
-#define PHYERR_WRITE_FAILED 0x0007
-#define PHYERR_NO_PHY 0x0008
-#define PHYERR_NO_RESOURCE 0x0009
-#define PHYERR_POWER_ISOLATION_TIMEOUT 0x000A
-#define PHYERR_POWER_DOWN_TIMEOUT 0x000B
-#define PHYERR_AUTONEG_TIMEOUT 0x000C
-#define PHYERR_PHY_LINK_SPEED_UNCHANGED 0x000D
-
-#define PHY_INVALID_PHY_ADDR 0xFFFF;
-
-////////////////////////////////////////////////////////////////////////=
/
-
-// This value can be used in the ulPhyLinkSpeed field.
-#define PHY_LINK_SPEED_UNKNOWN 0x0FFFFFFFF
-
-//
-// Values used to configure PHY mode.
-//
-#define PHY_MODE_MII 1
-#define PHY_MODE_RGMII 2
-
-typedef NV_VOID (* PTIMER_FUNC) (PNV_VOID pvContext);
-
-#ifdef __cplusplus
-} // extern "C"
-#endif
-
-#endif //_PHY_H_
Index: sys/dev/nve/if_nve.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/dev/nve/if_nve.c (revision 261434)
+++ sys/dev/nve/if_nve.c (working copy)
@@ -1,1791 +0,0 @@
-/*-
- * Copyright (c) 2005 by David E. O'Brien <obrien@FreeBSD.org>.
- * Copyright (c) 2003,2004 by Quinton Dolan <q@onthenet.com.au>.=20
- * All rights reserved.
- *=20
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions=20
- * are met:=20
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.=20
- * 2. Redistributions in binary form must reproduce the above copyright =
- * notice, this list of conditions and the following disclaimer in th=
e=20
- * documentation and/or other materials provided with the distributio=
n.
- *=20
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN=
D ANY
- * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
- * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE F=
OR
- * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIA=
L
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO=
DS OR
- * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HO=
WEVER
- * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY=
WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O=
F
- * SUCH DAMAGE.
- *=20
- * $Id: if_nv.c,v 1.19 2004/08/12 14:00:05 q Exp $
- */
-/*
- * NVIDIA nForce MCP Networking Adapter driver
- *=20
- * This is a port of the NVIDIA MCP Linux ethernet driver distributed by=
NVIDIA
- * through their web site.
- *=20
- * All mainstream nForce and nForce2 motherboards are supported. This mo=
dule
- * is as stable, sometimes more stable, than the linux version. (Recent
- * Linux stability issues seem to be related to some issues with newer
- * distributions using GCC 3.x, however this don't appear to effect Free=
BSD
- * 5.x).
- *=20
- * In accordance with the NVIDIA distribution license it is necessary to=
- * link this module against the nvlibnet.o binary object included in the=
- * Linux driver source distribution. The binary component is not modifie=
d in
- * any way and is simply linked against a FreeBSD equivalent of the nvne=
t.c
- * linux kernel module "wrapper".
- *=20
- * The Linux driver uses a common code API that is shared between Win32 =
and
- * i386 Linux. This abstracts the low level driver functions and uses
- * callbacks and hooks to access the underlying hardware device. By usin=
g
- * this same API in a FreeBSD kernel module it is possible to support th=
e
- * hardware without breaching the Linux source distributions licensing
- * requirements, or obtaining the hardware programming specifications.
- *=20
- * Although not conventional, it works, and given the relatively small
- * amount of hardware centric code, it's hopefully no more buggy than it=
s
- * linux counterpart.
- *
- * NVIDIA now support the nForce3 AMD64 platform, however I have been
- * unable to access such a system to verify support. However, the code i=
s
- * reported to work with little modification when compiled with the AMD6=
4
- * version of the NVIDIA Linux library. All that should be necessary to =
make
- * the driver work is to link it directly into the kernel, instead of as=
a
- * module, and apply the docs/amd64.diff patch in this source distributi=
on to
- * the NVIDIA Linux driver source.
- *
- * This driver should work on all versions of FreeBSD since 4.9/5.1 as w=
ell
- * as recent versions of DragonFly.
- *
- * Written by Quinton Dolan <q@onthenet.com.au>=20
- * Portions based on existing FreeBSD network drivers.=20
- * NVIDIA API usage derived from distributed NVIDIA NVNET driver source =
files.
- */
-
-#include <sys/cdefs.h>
-__FBSDID("$FreeBSD$");
-
-#include <sys/param.h>
-#include <sys/systm.h>
-#include <sys/sockio.h>
-#include <sys/mbuf.h>
-#include <sys/malloc.h>
-#include <sys/kernel.h>
-#include <sys/socket.h>
-#include <sys/sysctl.h>
-#include <sys/queue.h>
-#include <sys/module.h>
-
-#include <net/if.h>
-#include <net/if_var.h>
-#include <net/if_arp.h>
-#include <net/ethernet.h>
-#include <net/if_dl.h>
-#include <net/if_media.h>
-#include <net/if_types.h>
-#include <net/bpf.h>
-#include <net/if_vlan_var.h>
-
-#include <machine/bus.h>
-#include <machine/resource.h>
-
-#include <vm/vm.h> /* for vtophys */
-#include <vm/pmap.h> /* for vtophys */
-#include <sys/bus.h>
-#include <sys/rman.h>
-
-#include <dev/pci/pcireg.h>
-#include <dev/pci/pcivar.h>
-#include <dev/mii/mii.h>
-#include <dev/mii/miivar.h>
-#include "miibus_if.h"
-
-/* Include NVIDIA Linux driver header files */
-#include <contrib/dev/nve/nvenet_version.h>
-#define linux
-#include <contrib/dev/nve/basetype.h>
-#include <contrib/dev/nve/phy.h>
-#include "os+%DIKED-nve.h"
-#include <contrib/dev/nve/drvinfo.h>
-#include <contrib/dev/nve/adapter.h>
-#undef linux
-
-#include <dev/nve/if_nvereg.h>
-
-MODULE_DEPEND(nve, pci, 1, 1, 1);
-MODULE_DEPEND(nve, ether, 1, 1, 1);
-MODULE_DEPEND(nve, miibus, 1, 1, 1);
-
-static int nve_probe(device_t);
-static int nve_attach(device_t);
-static int nve_detach(device_t);
-static void nve_init(void *);
-static void nve_init_locked(struct nve_softc *);
-static void nve_stop(struct nve_softc *);
-static int nve_shutdown(device_t);
-static int nve_init_rings(struct nve_softc *);
-static void nve_free_rings(struct nve_softc *);
-
-static void nve_ifstart(struct ifnet *);
-static void nve_ifstart_locked(struct ifnet *);
-static int nve_ioctl(struct ifnet *, u_long, caddr_t);
-static void nve_intr(void *);
-static void nve_tick(void *);
-static void nve_setmulti(struct nve_softc *);
-static void nve_watchdog(struct nve_softc *);
-static void nve_update_stats(struct nve_softc *);
-
-static int nve_ifmedia_upd(struct ifnet *);
-static void nve_ifmedia_upd_locked(struct ifnet *);
-static void nve_ifmedia_sts(struct ifnet *, struct ifmediareq *);
-static int nve_miibus_readreg(device_t, int, int);
-static int nve_miibus_writereg(device_t, int, int, int);
-
-static void nve_dmamap_cb(void *, bus_dma_segment_t *, int, int);
-static void nve_dmamap_tx_cb(void *, bus_dma_segment_t *, int, bus_s=
ize_t, int);
-
-static NV_API_CALL NV_SINT32 nve_osalloc(PNV_VOID, PMEMORY_BLOCK);
-static NV_API_CALL NV_SINT32 nve_osfree(PNV_VOID, PMEMORY_BLOCK);
-static NV_API_CALL NV_SINT32 nve_osallocex(PNV_VOID, PMEMORY_BLOCKEX);
-static NV_API_CALL NV_SINT32 nve_osfreeex(PNV_VOID, PMEMORY_BLOCKEX);
-static NV_API_CALL NV_SINT32 nve_osclear(PNV_VOID, PNV_VOID, NV_SINT32);=
-static NV_API_CALL NV_SINT32 nve_osdelay(PNV_VOID, NV_UINT32);
-static NV_API_CALL NV_SINT32 nve_osallocrxbuf(PNV_VOID, PMEMORY_BLOCK, P=
NV_VOID *);
-static NV_API_CALL NV_SINT32 nve_osfreerxbuf(PNV_VOID, PMEMORY_BLOCK, PN=
V_VOID);
-static NV_API_CALL NV_SINT32 nve_ospackettx(PNV_VOID, PNV_VOID, NV_UINT3=
2);
-static NV_API_CALL NV_SINT32 nve_ospacketrx(PNV_VOID, PNV_VOID, NV_UINT3=
2, NV_UINT8 *, NV_UINT8);
-static NV_API_CALL NV_SINT32 nve_oslinkchg(PNV_VOID, NV_SINT32);
-static NV_API_CALL NV_SINT32 nve_osalloctimer(PNV_VOID, PNV_VOID *);
-static NV_API_CALL NV_SINT32 nve_osfreetimer(PNV_VOID, PNV_VOID);
-static NV_API_CALL NV_SINT32 nve_osinittimer(PNV_VOID, PNV_VOID, PTIMER_=
FUNC, PNV_VOID);
-static NV_API_CALL NV_SINT32 nve_ossettimer(PNV_VOID, PNV_VOID, NV_UINT3=
2);
-static NV_API_CALL NV_SINT32 nve_oscanceltimer(PNV_VOID, PNV_VOID);
-
-static NV_API_CALL NV_SINT32 nve_ospreprocpkt(PNV_VOID, PNV_VOID, PNV_VO=
ID *, NV_UINT8 *, NV_UINT8);
-static NV_API_CALL PNV_VOID nve_ospreprocpktnopq(PNV_VOID, PNV_VOID);
-static NV_API_CALL NV_SINT32 nve_osindicatepkt(PNV_VOID, PNV_VOID *, NV_=
UINT32);
-static NV_API_CALL NV_SINT32 nve_oslockalloc(PNV_VOID, NV_SINT32, PNV_VO=
ID *);
-static NV_API_CALL NV_SINT32 nve_oslockacquire(PNV_VOID, NV_SINT32, PNV_=
VOID);
-static NV_API_CALL NV_SINT32 nve_oslockrelease(PNV_VOID, NV_SINT32, PNV_=
VOID);
-static NV_API_CALL PNV_VOID nve_osreturnbufvirt(PNV_VOID, PNV_VOID);
-
-static device_method_t nve_methods[] =3D {
- /* Device interface */
- DEVMETHOD(device_probe, nve_probe),
- DEVMETHOD(device_attach, nve_attach),
- DEVMETHOD(device_detach, nve_detach),
- DEVMETHOD(device_shutdown, nve_shutdown),
-
- /* MII interface */
- DEVMETHOD(miibus_readreg, nve_miibus_readreg),
- DEVMETHOD(miibus_writereg, nve_miibus_writereg),
-
- DEVMETHOD_END
-};
-
-static driver_t nve_driver =3D {
- "nve",
- nve_methods,
- sizeof(struct nve_softc)
-};
-
-static devclass_t nve_devclass;
-
-static int nve_pollinterval =3D 0;
-SYSCTL_INT(_hw, OID_AUTO, nve_pollinterval, CTLFLAG_RW,
- &nve_pollinterval, 0, "delay between interface polls");
-
-DRIVER_MODULE(nve, pci, nve_driver, nve_devclass, 0, 0);
-DRIVER_MODULE(miibus, nve, miibus_driver, miibus_devclass, 0, 0);
-
-static struct nve_type nve_devs[] =3D {
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE_LAN,
- "NVIDIA nForce MCP Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE2_LAN,
- "NVIDIA nForce2 MCP2 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN1,
- "NVIDIA nForce2 400 MCP4 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN2,
- "NVIDIA nForce2 400 MCP5 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE3_LAN1,
- "NVIDIA nForce3 MCP3 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE3_250_LAN,
- "NVIDIA nForce3 250 MCP6 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE3_LAN4,
- "NVIDIA nForce3 MCP7 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE4_LAN1,
- "NVIDIA nForce4 CK804 MCP8 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE4_LAN2,
- "NVIDIA nForce4 CK804 MCP9 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP04_LAN1,
- "NVIDIA nForce MCP04 Networking Adapter"}, // MCP10
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP04_LAN2,
- "NVIDIA nForce MCP04 Networking Adapter"}, // MCP11
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE430_LAN1,
- "NVIDIA nForce 430 MCP12 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE430_LAN2,
- "NVIDIA nForce 430 MCP13 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP55_LAN1,
- "NVIDIA nForce MCP55 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP55_LAN2,
- "NVIDIA nForce MCP55 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN1,
- "NVIDIA nForce MCP61 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN2,
- "NVIDIA nForce MCP61 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN3,
- "NVIDIA nForce MCP61 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN4,
- "NVIDIA nForce MCP61 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN1,
- "NVIDIA nForce MCP65 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN2,
- "NVIDIA nForce MCP65 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN3,
- "NVIDIA nForce MCP65 Networking Adapter"},
- {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN4,
- "NVIDIA nForce MCP65 Networking Adapter"},
- {0, 0, NULL}
-};
-
-/* DMA MEM map callback function to get data segment physical address */=
-static void
-nve_dmamap_cb(void *arg, bus_dma_segment_t * segs, int nsegs, int error)=
-{
- if (error)
- return;
-
- KASSERT(nsegs =3D=3D 1,
- ("Too many DMA segments returned when mapping DMA memory"));
- *(bus_addr_t *)arg =3D segs->ds_addr;
-}
-
-/* DMA RX map callback function to get data segment physical address */
-static void
-nve_dmamap_rx_cb(void *arg, bus_dma_segment_t * segs, int nsegs,
- bus_size_t mapsize, int error)
-{
- if (error)
- return;
- *(bus_addr_t *)arg =3D segs->ds_addr;
-}
-
-/*
- * DMA TX buffer callback function to allocate fragment data segment
- * addresses
- */
-static void
-nve_dmamap_tx_cb(void *arg, bus_dma_segment_t * segs, int nsegs, bus_siz=
e_t mapsize, int error)
-{
- struct nve_tx_desc *info;
-
- info =3D arg;
- if (error)
- return;
- KASSERT(nsegs < NV_MAX_FRAGS,
- ("Too many DMA segments returned when mapping mbuf"));
- info->numfrags =3D nsegs;
- bcopy(segs, info->frags, nsegs * sizeof(bus_dma_segment_t));
-}
-
-/* Probe for supported hardware ID's */
-static int
-nve_probe(device_t dev)
-{
- struct nve_type *t;
-
- t =3D nve_devs;
- /* Check for matching PCI DEVICE ID's */
- while (t->name !=3D NULL) {
- if ((pci_get_vendor(dev) =3D=3D t->vid_id) &&
- (pci_get_device(dev) =3D=3D t->dev_id)) {
- device_set_desc(dev, t->name);
- return (BUS_PROBE_LOW_PRIORITY);
- }
- t++;
- }
-
- return (ENXIO);
-}
-
-/* Attach driver and initialise hardware for use */
-static int
-nve_attach(device_t dev)
-{
- u_char eaddr[ETHER_ADDR_LEN];
- struct nve_softc *sc;
- struct ifnet *ifp;
- OS_API *osapi;
- ADAPTER_OPEN_PARAMS OpenParams;
- int error =3D 0, i, rid;
-
- if (bootverbose)
- device_printf(dev, "nvenetlib.o version %s\n", DRIVER_VERSION);
-
- DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_attach - entry\n");
-
- sc =3D device_get_softc(dev);
-
- /* Allocate mutex */
- mtx_init(&sc->mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
- MTX_DEF);
- callout_init_mtx(&sc->stat_callout, &sc->mtx, 0);
-
- sc->dev =3D dev;
-
- /* Preinitialize data structures */
- bzero(&OpenParams, sizeof(ADAPTER_OPEN_PARAMS));
-
- /* Enable bus mastering */
- pci_enable_busmaster(dev);
-
- /* Allocate memory mapped address space */
- rid =3D NV_RID;
- sc->res =3D bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1,
- RF_ACTIVE);
-
- if (sc->res =3D=3D NULL) {
- device_printf(dev, "couldn't map memory\n");
- error =3D ENXIO;
- goto fail;
- }
- sc->sc_st =3D rman_get_bustag(sc->res);
- sc->sc_sh =3D rman_get_bushandle(sc->res);
-
- /* Allocate interrupt */
- rid =3D 0;
- sc->irq =3D bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1,
- RF_SHAREABLE | RF_ACTIVE);
-
- if (sc->irq =3D=3D NULL) {
- device_printf(dev, "couldn't map interrupt\n");
- error =3D ENXIO;
- goto fail;
- }
- /* Allocate DMA tags */
- error =3D bus_dma_tag_create(bus_get_dma_tag(dev),
- 4, 0, BUS_SPACE_MAXADDR_32BIT,
- BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES * NV_MAX_FRAGS,
- NV_MAX_FRAGS, MCLBYTES, 0,
- busdma_lock_mutex, &Giant,
- &sc->mtag);
- if (error) {
- device_printf(dev, "couldn't allocate dma tag\n");
- goto fail;
- }
- error =3D bus_dma_tag_create(bus_get_dma_tag(dev),
- 4, 0, BUS_SPACE_MAXADDR_32BIT,
- BUS_SPACE_MAXADDR, NULL, NULL,
- sizeof(struct nve_rx_desc) * RX_RING_SIZE, 1,
- sizeof(struct nve_rx_desc) * RX_RING_SIZE, 0,
- busdma_lock_mutex, &Giant,
- &sc->rtag);
- if (error) {
- device_printf(dev, "couldn't allocate dma tag\n");
- goto fail;
- }
- error =3D bus_dma_tag_create(bus_get_dma_tag(dev),
- 4, 0, BUS_SPACE_MAXADDR_32BIT,
- BUS_SPACE_MAXADDR, NULL, NULL,
- sizeof(struct nve_tx_desc) * TX_RING_SIZE, 1,
- sizeof(struct nve_tx_desc) * TX_RING_SIZE, 0,
- busdma_lock_mutex, &Giant,
- &sc->ttag);
- if (error) {
- device_printf(dev, "couldn't allocate dma tag\n");
- goto fail;
- }
- /* Allocate DMA safe memory and get the DMA addresses. */
- error =3D bus_dmamem_alloc(sc->ttag, (void **)&sc->tx_desc,
- BUS_DMA_WAITOK, &sc->tmap);
- if (error) {
- device_printf(dev, "couldn't allocate dma memory\n");
- goto fail;
- }
- bzero(sc->tx_desc, sizeof(struct nve_tx_desc) * TX_RING_SIZE);
- error =3D bus_dmamap_load(sc->ttag, sc->tmap, sc->tx_desc,
- sizeof(struct nve_tx_desc) * TX_RING_SIZE, nve_dmamap_cb,
- &sc->tx_addr, 0);
- if (error) {
- device_printf(dev, "couldn't map dma memory\n");
- goto fail;
- }
- error =3D bus_dmamem_alloc(sc->rtag, (void **)&sc->rx_desc,
- BUS_DMA_WAITOK, &sc->rmap);
- if (error) {
- device_printf(dev, "couldn't allocate dma memory\n");
- goto fail;
- }
- bzero(sc->rx_desc, sizeof(struct nve_rx_desc) * RX_RING_SIZE);
- error =3D bus_dmamap_load(sc->rtag, sc->rmap, sc->rx_desc,
- sizeof(struct nve_rx_desc) * RX_RING_SIZE, nve_dmamap_cb,
- &sc->rx_addr, 0);
- if (error) {
- device_printf(dev, "couldn't map dma memory\n");
- goto fail;
- }
- /* Initialize rings. */
- if (nve_init_rings(sc)) {
- device_printf(dev, "failed to init rings\n");
- error =3D ENXIO;
- goto fail;
- }
- /* Setup NVIDIA API callback routines */
- osapi =3D &sc->osapi;
- osapi->pOSCX =3D sc;
- osapi->pfnAllocMemory =3D nve_osalloc;
- osapi->pfnFreeMemory =3D nve_osfree;
- osapi->pfnAllocMemoryEx =3D nve_osallocex;
- osapi->pfnFreeMemoryEx =3D nve_osfreeex;
- osapi->pfnClearMemory =3D nve_osclear;
- osapi->pfnStallExecution =3D nve_osdelay;
- osapi->pfnAllocReceiveBuffer =3D nve_osallocrxbuf;
- osapi->pfnFreeReceiveBuffer =3D nve_osfreerxbuf;
- osapi->pfnPacketWasSent =3D nve_ospackettx;
- osapi->pfnPacketWasReceived =3D nve_ospacketrx;
- osapi->pfnLinkStateHasChanged =3D nve_oslinkchg;
- osapi->pfnAllocTimer =3D nve_osalloctimer;
- osapi->pfnFreeTimer =3D nve_osfreetimer;
- osapi->pfnInitializeTimer =3D nve_osinittimer;
- osapi->pfnSetTimer =3D nve_ossettimer;
- osapi->pfnCancelTimer =3D nve_oscanceltimer;
- osapi->pfnPreprocessPacket =3D nve_ospreprocpkt;
- osapi->pfnPreprocessPacketNopq =3D nve_ospreprocpktnopq;
- osapi->pfnIndicatePackets =3D nve_osindicatepkt;
- osapi->pfnLockAlloc =3D nve_oslockalloc;
- osapi->pfnLockAcquire =3D nve_oslockacquire;
- osapi->pfnLockRelease =3D nve_oslockrelease;
- osapi->pfnReturnBufferVirtual =3D nve_osreturnbufvirt;
-
- sc->linkup =3D FALSE;
- sc->max_frame_size =3D ETHERMTU + ETHER_HDR_LEN + FCS_LEN;
-
- /* TODO - We don't support hardware offload yet */
- sc->hwmode =3D 1;
- sc->media =3D 0;
-
- /* Set NVIDIA API startup parameters */
- OpenParams.MaxDpcLoop =3D 2;
- OpenParams.MaxRxPkt =3D RX_RING_SIZE;
- OpenParams.MaxTxPkt =3D TX_RING_SIZE;
- OpenParams.SentPacketStatusSuccess =3D 1;
- OpenParams.SentPacketStatusFailure =3D 0;
- OpenParams.MaxRxPktToAccumulate =3D 6;
- OpenParams.ulPollInterval =3D nve_pollinterval;
- OpenParams.SetForcedModeEveryNthRxPacket =3D 0;
- OpenParams.SetForcedModeEveryNthTxPacket =3D 0;
- OpenParams.RxForcedInterrupt =3D 0;
- OpenParams.TxForcedInterrupt =3D 0;
- OpenParams.pOSApi =3D osapi;
- OpenParams.pvHardwareBaseAddress =3D rman_get_virtual(sc->res);
- OpenParams.bASFEnabled =3D 0;
- OpenParams.ulDescriptorVersion =3D sc->hwmode;
- OpenParams.ulMaxPacketSize =3D sc->max_frame_size;
- OpenParams.DeviceId =3D pci_get_device(dev);
-
- /* Open NVIDIA Hardware API */
- error =3D ADAPTER_Open(&OpenParams, (void **)&(sc->hwapi), &sc->phyaddr=
);
- if (error) {
- device_printf(dev,
- "failed to open NVIDIA Hardware API: 0x%x\n", error);
- goto fail;
- }
-=09
- /* TODO - Add support for MODE2 hardware offload */=20
-=09
- bzero(&sc->adapterdata, sizeof(sc->adapterdata));
-=09
- sc->adapterdata.ulMediaIF =3D sc->media;
- sc->adapterdata.ulModeRegTxReadCompleteEnable =3D 1;
- sc->hwapi->pfnSetCommonData(sc->hwapi->pADCX, &sc->adapterdata);
-=09
- /* MAC is loaded backwards into h/w reg */
- sc->hwapi->pfnGetNodeAddress(sc->hwapi->pADCX, sc->original_mac_addr);
- for (i =3D 0; i < 6; i++) {
- eaddr[i] =3D sc->original_mac_addr[5 - i];
- }
- sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX, eaddr);
-
- /* Display ethernet address ,... */
- device_printf(dev, "Ethernet address %6D\n", eaddr, ":");
-
- /* Allocate interface structures */
- ifp =3D sc->ifp =3D if_alloc(IFT_ETHER);
- if (ifp =3D=3D NULL) {
- device_printf(dev, "can not if_alloc()\n");
- error =3D ENOSPC;
- goto fail;
- }
-
- /* Setup interface parameters */
- ifp->if_softc =3D sc;
- if_initname(ifp, device_get_name(dev), device_get_unit(dev));
- ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
- ifp->if_ioctl =3D nve_ioctl;
- ifp->if_start =3D nve_ifstart;
- ifp->if_init =3D nve_init;
- ifp->if_baudrate =3D IF_Mbps(100);
- IFQ_SET_MAXLEN(&ifp->if_snd, TX_RING_SIZE - 1);
- ifp->if_snd.ifq_drv_maxlen =3D TX_RING_SIZE - 1;
- IFQ_SET_READY(&ifp->if_snd);
- ifp->if_capabilities |=3D IFCAP_VLAN_MTU;
- ifp->if_capenable |=3D IFCAP_VLAN_MTU;
-
- /* Attach device for MII interface to PHY */
- DEBUGOUT(NVE_DEBUG_INIT, "nve: do mii_attach\n");
- error =3D mii_attach(dev, &sc->miibus, ifp, nve_ifmedia_upd,
- nve_ifmedia_sts, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0);
- if (error !=3D 0) {
- device_printf(dev, "attaching PHYs failed\n");
- goto fail;
- }
-
- /* Attach to OS's managers. */
- ether_ifattach(ifp, eaddr);
-
- /* Activate our interrupt handler. - attach last to avoid lock */
- error =3D bus_setup_intr(dev, sc->irq, INTR_TYPE_NET | INTR_MPSAFE,
- NULL, nve_intr, sc, &sc->sc_ih);
- if (error) {
- device_printf(dev, "couldn't set up interrupt handler\n");
- goto fail;
- }
- DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_attach - exit\n");
-
-fail:
- if (error)
- nve_detach(dev);
-
- return (error);
-}
-
-/* Detach interface for module unload */
-static int
-nve_detach(device_t dev)
-{
- struct nve_softc *sc =3D device_get_softc(dev);
- struct ifnet *ifp;
-
- KASSERT(mtx_initialized(&sc->mtx), ("mutex not initialized"));
-
- DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_detach - entry\n");
-
- ifp =3D sc->ifp;
-
- if (device_is_attached(dev)) {
- ether_ifdetach(ifp);
- NVE_LOCK(sc);
- nve_stop(sc);
- NVE_UNLOCK(sc);
- callout_drain(&sc->stat_callout);
- }
-
- if (sc->miibus)
- device_delete_child(dev, sc->miibus);
- bus_generic_detach(dev);
-
- /* Reload unreversed address back into MAC in original state */
- if (sc->original_mac_addr)
- sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX,
- sc->original_mac_addr);
-
- DEBUGOUT(NVE_DEBUG_DEINIT, "nve: do pfnClose\n");
- /* Detach from NVIDIA hardware API */
- if (sc->hwapi->pfnClose)
- sc->hwapi->pfnClose(sc->hwapi->pADCX, FALSE);
- /* Release resources */
- if (sc->sc_ih)
- bus_teardown_intr(sc->dev, sc->irq, sc->sc_ih);
- if (sc->irq)
- bus_release_resource(sc->dev, SYS_RES_IRQ, 0, sc->irq);
- if (sc->res)
- bus_release_resource(sc->dev, SYS_RES_MEMORY, NV_RID, sc->res);
-
- nve_free_rings(sc);
-
- if (sc->tx_desc) {
- bus_dmamap_unload(sc->rtag, sc->rmap);
- bus_dmamem_free(sc->rtag, sc->rx_desc, sc->rmap);
- bus_dmamap_destroy(sc->rtag, sc->rmap);
- }
- if (sc->mtag)
- bus_dma_tag_destroy(sc->mtag);
- if (sc->ttag)
- bus_dma_tag_destroy(sc->ttag);
- if (sc->rtag)
- bus_dma_tag_destroy(sc->rtag);
-
- if (ifp)
- if_free(ifp);
- mtx_destroy(&sc->mtx);
-
- DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_detach - exit\n");
-
- return (0);
-}
-
-/* Initialise interface and start it "RUNNING" */
-static void
-nve_init(void *xsc)
-{
- struct nve_softc *sc =3D xsc;
-
- NVE_LOCK(sc);
- nve_init_locked(sc);
- NVE_UNLOCK(sc);
-}
-
-static void
-nve_init_locked(struct nve_softc *sc)
-{
- struct ifnet *ifp;
- int error;
-
- NVE_LOCK_ASSERT(sc);
- DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init - entry (%d)\n", sc->linkup);
-
- ifp =3D sc->ifp;
-
- /* Do nothing if already running */
- if (ifp->if_drv_flags & IFF_DRV_RUNNING)
- return;
-
- nve_stop(sc);
- DEBUGOUT(NVE_DEBUG_INIT, "nve: do pfnInit\n");
-
- nve_ifmedia_upd_locked(ifp);
-
- /* Setup Hardware interface and allocate memory structures */
- error =3D sc->hwapi->pfnInit(sc->hwapi->pADCX,=20
- 0, /* force speed */=20
- 0, /* force full duplex */
- 0, /* force mode */
- 0, /* force async mode */
- &sc->linkup);
-
- if (error) {
- device_printf(sc->dev,
- "failed to start NVIDIA Hardware interface\n");
- return;
- }
- /* Set the MAC address */
- sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX, IF_LLADDR(sc->ifp));
- sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX);
- sc->hwapi->pfnStart(sc->hwapi->pADCX);
-
- /* Setup multicast filter */
- nve_setmulti(sc);
-
- /* Update interface parameters */
- ifp->if_drv_flags |=3D IFF_DRV_RUNNING;
- ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE;
-
- callout_reset(&sc->stat_callout, hz, nve_tick, sc);
-
- DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init - exit\n");
-
- return;
-}
-
-/* Stop interface activity ie. not "RUNNING" */
-static void
-nve_stop(struct nve_softc *sc)
-{
- struct ifnet *ifp;
-
- NVE_LOCK_ASSERT(sc);
-
- DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_stop - entry\n");
-
- ifp =3D sc->ifp;
- sc->tx_timer =3D 0;
-
- /* Cancel tick timer */
- callout_stop(&sc->stat_callout);
-
- /* Stop hardware activity */
- sc->hwapi->pfnDisableInterrupts(sc->hwapi->pADCX);
- sc->hwapi->pfnStop(sc->hwapi->pADCX, 0);
-
- DEBUGOUT(NVE_DEBUG_DEINIT, "nve: do pfnDeinit\n");
- /* Shutdown interface and deallocate memory buffers */
- if (sc->hwapi->pfnDeinit)
- sc->hwapi->pfnDeinit(sc->hwapi->pADCX, 0);
-
- sc->linkup =3D 0;
- sc->cur_rx =3D 0;
- sc->pending_rxs =3D 0;
- sc->pending_txs =3D 0;
-
- ifp->if_drv_flags &=3D ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE);
-
- DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_stop - exit\n");
-
- return;
-}
-
-/* Shutdown interface for unload/reboot */
-static int
-nve_shutdown(device_t dev)
-{
- struct nve_softc *sc;
-
- DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_shutdown\n");
-
- sc =3D device_get_softc(dev);
-
- /* Stop hardware activity */
- NVE_LOCK(sc);
- nve_stop(sc);
- NVE_UNLOCK(sc);
-
- return (0);
-}
-
-/* Allocate TX ring buffers */
-static int
-nve_init_rings(struct nve_softc *sc)
-{
- int error, i;
-
- DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - entry\n");
-
- sc->cur_rx =3D sc->cur_tx =3D sc->pending_rxs =3D sc->pending_txs =3D 0=
;
- /* Initialise RX ring */
- for (i =3D 0; i < RX_RING_SIZE; i++) {
- struct nve_rx_desc *desc =3D sc->rx_desc + i;
- struct nve_map_buffer *buf =3D &desc->buf;
-
- buf->mbuf =3D m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR);
- if (buf->mbuf =3D=3D NULL) {
- device_printf(sc->dev, "couldn't allocate mbuf\n");
- nve_free_rings(sc);
- return (ENOBUFS);
- }
- buf->mbuf->m_len =3D buf->mbuf->m_pkthdr.len =3D MCLBYTES;
- m_adj(buf->mbuf, ETHER_ALIGN);
-
- error =3D bus_dmamap_create(sc->mtag, 0, &buf->map);
- if (error) {
- device_printf(sc->dev, "couldn't create dma map\n");
- nve_free_rings(sc);
- return (error);
- }
- error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, buf->mbuf,
- nve_dmamap_rx_cb, &desc->paddr, 0);
- if (error) {
- device_printf(sc->dev, "couldn't dma map mbuf\n");
- nve_free_rings(sc);
- return (error);
- }
- bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_PREREAD);
-
- desc->buflength =3D buf->mbuf->m_len;
- desc->vaddr =3D mtod(buf->mbuf, caddr_t);
- }
- bus_dmamap_sync(sc->rtag, sc->rmap,
- BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
-
- /* Initialize TX ring */
- for (i =3D 0; i < TX_RING_SIZE; i++) {
- struct nve_tx_desc *desc =3D sc->tx_desc + i;
- struct nve_map_buffer *buf =3D &desc->buf;
-
- buf->mbuf =3D NULL;
-
- error =3D bus_dmamap_create(sc->mtag, 0, &buf->map);
- if (error) {
- device_printf(sc->dev, "couldn't create dma map\n");
- nve_free_rings(sc);
- return (error);
- }
- }
- bus_dmamap_sync(sc->ttag, sc->tmap,
- BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
-
- DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - exit\n");
-
- return (error);
-}
-
-/* Free the TX ring buffers */
-static void
-nve_free_rings(struct nve_softc *sc)
-{
- int i;
-
- DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_free_rings - entry\n");
-
- for (i =3D 0; i < RX_RING_SIZE; i++) {
- struct nve_rx_desc *desc =3D sc->rx_desc + i;
- struct nve_map_buffer *buf =3D &desc->buf;
-
- if (buf->mbuf) {
- bus_dmamap_unload(sc->mtag, buf->map);
- bus_dmamap_destroy(sc->mtag, buf->map);
- m_freem(buf->mbuf);
- }
- buf->mbuf =3D NULL;
- }
-
- for (i =3D 0; i < TX_RING_SIZE; i++) {
- struct nve_tx_desc *desc =3D sc->tx_desc + i;
- struct nve_map_buffer *buf =3D &desc->buf;
-
- if (buf->mbuf) {
- bus_dmamap_unload(sc->mtag, buf->map);
- bus_dmamap_destroy(sc->mtag, buf->map);
- m_freem(buf->mbuf);
- }
- buf->mbuf =3D NULL;
- }
-
- DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_free_rings - exit\n");
-}
-
-/* Main loop for sending packets from OS to interface */
-static void
-nve_ifstart(struct ifnet *ifp)
-{
- struct nve_softc *sc =3D ifp->if_softc;
-
- NVE_LOCK(sc);
- nve_ifstart_locked(ifp);
- NVE_UNLOCK(sc);
-}
-
-static void
-nve_ifstart_locked(struct ifnet *ifp)
-{
- struct nve_softc *sc =3D ifp->if_softc;
- struct nve_map_buffer *buf;
- struct mbuf *m0, *m;
- struct nve_tx_desc *desc;
- ADAPTER_WRITE_DATA txdata;
- int error, i;
-
- DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_ifstart - entry\n");
-
- NVE_LOCK_ASSERT(sc);
-
- /* If link is down/busy or queue is empty do nothing */
- if (ifp->if_drv_flags & IFF_DRV_OACTIVE ||
- IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- return;
-
- /* Transmit queued packets until sent or TX ring is full */
- while (sc->pending_txs < TX_RING_SIZE) {
- desc =3D sc->tx_desc + sc->cur_tx;
- buf =3D &desc->buf;
-
- /* Get next packet to send. */
- IFQ_DRV_DEQUEUE(&ifp->if_snd, m0);
-
- /* If nothing to send, return. */
- if (m0 =3D=3D NULL)
- return;
-
- /*
- * On nForce4, the chip doesn't interrupt on transmit,
- * so try to flush transmitted packets from the queue
- * if it's getting large (see note in nve_watchdog).
- */
- if (sc->pending_txs > TX_RING_SIZE/2) {
- sc->hwapi->pfnDisableInterrupts(sc->hwapi->pADCX);
- sc->hwapi->pfnHandleInterrupt(sc->hwapi->pADCX);
- sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX);
- }
-
- /* Map MBUF for DMA access */
- error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, m0,
- nve_dmamap_tx_cb, desc, BUS_DMA_NOWAIT);
-
- if (error && error !=3D EFBIG) {
- m_freem(m0);
- sc->tx_errors++;
- continue;
- }
- /*
- * Packet has too many fragments - defrag into new mbuf
- * cluster
- */
- if (error) {
- m =3D m_defrag(m0, M_NOWAIT);
- if (m =3D=3D NULL) {
- m_freem(m0);
- sc->tx_errors++;
- continue;
- }
- m0 =3D m;
-
- error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, m,
- nve_dmamap_tx_cb, desc, BUS_DMA_NOWAIT);
- if (error) {
- m_freem(m);
- sc->tx_errors++;
- continue;
- }
- }
- /* Do sync on DMA bounce buffer */
- bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_PREWRITE);
-
- buf->mbuf =3D m0;
- txdata.ulNumberOfElements =3D desc->numfrags;
- txdata.pvID =3D (PVOID)desc;
-
- /* Put fragments into API element list */
- txdata.ulTotalLength =3D buf->mbuf->m_len;
- for (i =3D 0; i < desc->numfrags; i++) {
- txdata.sElement[i].ulLength =3D
- (ulong)desc->frags[i].ds_len;
- txdata.sElement[i].pPhysical =3D
- (PVOID)desc->frags[i].ds_addr;
- }
-
- /* Send packet to Nvidia API for transmission */
- error =3D sc->hwapi->pfnWrite(sc->hwapi->pADCX, &txdata);
-
- switch (error) {
- case ADAPTERERR_NONE:
- /* Packet was queued in API TX queue successfully */
- sc->pending_txs++;
- sc->cur_tx =3D (sc->cur_tx + 1) % TX_RING_SIZE;
- break;
-
- case ADAPTERERR_TRANSMIT_QUEUE_FULL:
- /* The API TX queue is full - requeue the packet */
- device_printf(sc->dev,
- "nve_ifstart: transmit queue is full\n");
- ifp->if_drv_flags |=3D IFF_DRV_OACTIVE;
- bus_dmamap_unload(sc->mtag, buf->map);
- IFQ_DRV_PREPEND(&ifp->if_snd, buf->mbuf);
- buf->mbuf =3D NULL;
- return;
-
- default:
- /* The API failed to queue/send the packet so dump it */
- device_printf(sc->dev, "nve_ifstart: transmit error\n");
- bus_dmamap_unload(sc->mtag, buf->map);
- m_freem(buf->mbuf);
- buf->mbuf =3D NULL;
- sc->tx_errors++;
- return;
- }
- /* Set watchdog timer. */
- sc->tx_timer =3D 8;
-
- /* Copy packet to BPF tap */
- BPF_MTAP(ifp, m0);
- }
- ifp->if_drv_flags |=3D IFF_DRV_OACTIVE;
-
- DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_ifstart - exit\n");
-}
-
-/* Handle IOCTL events */
-static int
-nve_ioctl(struct ifnet *ifp, u_long command, caddr_t data)
-{
- struct nve_softc *sc =3D ifp->if_softc;
- struct ifreq *ifr =3D (struct ifreq *) data;
- struct mii_data *mii;
- int error =3D 0;
-
- DEBUGOUT(NVE_DEBUG_IOCTL, "nve: nve_ioctl - entry\n");
-
- switch (command) {
- case SIOCSIFMTU:
- /* Set MTU size */
- NVE_LOCK(sc);
- if (ifp->if_mtu =3D=3D ifr->ifr_mtu) {
- NVE_UNLOCK(sc);
- break;
- }
- if (ifr->ifr_mtu + ifp->if_hdrlen <=3D MAX_PACKET_SIZE_1518) {
- ifp->if_mtu =3D ifr->ifr_mtu;
- nve_stop(sc);
- nve_init_locked(sc);
- } else
- error =3D EINVAL;
- NVE_UNLOCK(sc);
- break;
-
- case SIOCSIFFLAGS:
- /* Setup interface flags */
- NVE_LOCK(sc);
- if (ifp->if_flags & IFF_UP) {
- if ((ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0) {
- nve_init_locked(sc);
- NVE_UNLOCK(sc);
- break;
- }
- } else {
- if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
- nve_stop(sc);
- NVE_UNLOCK(sc);
- break;
- }
- }
- /* Handle IFF_PROMISC and IFF_ALLMULTI flags. */
- nve_setmulti(sc);
- NVE_UNLOCK(sc);
- break;
-
- case SIOCADDMULTI:
- case SIOCDELMULTI:
- /* Setup multicast filter */
- NVE_LOCK(sc);
- if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
- nve_setmulti(sc);
- }
- NVE_UNLOCK(sc);
- break;
-
- case SIOCGIFMEDIA:
- case SIOCSIFMEDIA:
- /* Get/Set interface media parameters */
- mii =3D device_get_softc(sc->miibus);
- error =3D ifmedia_ioctl(ifp, ifr, &mii->mii_media, command);
- break;
-
- default:
- /* Everything else we forward to generic ether ioctl */
- error =3D ether_ioctl(ifp, command, data);
- break;
- }
-
- DEBUGOUT(NVE_DEBUG_IOCTL, "nve: nve_ioctl - exit\n");
-
- return (error);
-}
-
-/* Interrupt service routine */
-static void
-nve_intr(void *arg)
-{
- struct nve_softc *sc =3D arg;
- struct ifnet *ifp =3D sc->ifp;
-
- DEBUGOUT(NVE_DEBUG_INTERRUPT, "nve: nve_intr - entry\n");
-
- NVE_LOCK(sc);
- if (!ifp->if_flags & IFF_UP) {
- nve_stop(sc);
- NVE_UNLOCK(sc);
- return;
- }
- /* Handle interrupt event */
- if (sc->hwapi->pfnQueryInterrupt(sc->hwapi->pADCX)) {
- sc->hwapi->pfnHandleInterrupt(sc->hwapi->pADCX);
- sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX);
- }
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- nve_ifstart_locked(ifp);
-
- /* If no pending packets we don't need a timeout */
- if (sc->pending_txs =3D=3D 0)
- sc->tx_timer =3D 0;
- NVE_UNLOCK(sc);
-
- DEBUGOUT(NVE_DEBUG_INTERRUPT, "nve: nve_intr - exit\n");
-
- return;
-}
-
-/* Setup multicast filters */
-static void
-nve_setmulti(struct nve_softc *sc)
-{
- struct ifnet *ifp;
- struct ifmultiaddr *ifma;
- PACKET_FILTER hwfilter;
- int i;
- u_int8_t andaddr[6], oraddr[6];
-
- NVE_LOCK_ASSERT(sc);
-
- DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_setmulti - entry\n");
-
- ifp =3D sc->ifp;
-
- /* Initialize filter */
- hwfilter.ulFilterFlags =3D 0;
- for (i =3D 0; i < 6; i++) {
- hwfilter.acMulticastAddress[i] =3D 0;
- hwfilter.acMulticastMask[i] =3D 0;
- }
-
- if (ifp->if_flags & (IFF_PROMISC | IFF_ALLMULTI)) {
- /* Accept all packets */
- hwfilter.ulFilterFlags |=3D ACCEPT_ALL_PACKETS;
- sc->hwapi->pfnSetPacketFilter(sc->hwapi->pADCX, &hwfilter);
- return;
- }
- /* Setup multicast filter */
- if_maddr_rlock(ifp);
- TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
- u_char *addrp;
-
- if (ifma->ifma_addr->sa_family !=3D AF_LINK)
- continue;
-
- addrp =3D LLADDR((struct sockaddr_dl *) ifma->ifma_addr);
- for (i =3D 0; i < 6; i++) {
- u_int8_t mcaddr =3D addrp[i];
- andaddr[i] &=3D mcaddr;
- oraddr[i] |=3D mcaddr;
- }
- }
- if_maddr_runlock(ifp);
- for (i =3D 0; i < 6; i++) {
- hwfilter.acMulticastAddress[i] =3D andaddr[i] & oraddr[i];
- hwfilter.acMulticastMask[i] =3D andaddr[i] | (~oraddr[i]);
- }
-
- /* Send filter to NVIDIA API */
- sc->hwapi->pfnSetPacketFilter(sc->hwapi->pADCX, &hwfilter);
-
- DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_setmulti - exit\n");
-
- return;
-}
-
-/* Change the current media/mediaopts */
-static int
-nve_ifmedia_upd(struct ifnet *ifp)
-{
- struct nve_softc *sc =3D ifp->if_softc;
-
- NVE_LOCK(sc);
- nve_ifmedia_upd_locked(ifp);
- NVE_UNLOCK(sc);
- return (0);
-}
-
-static void
-nve_ifmedia_upd_locked(struct ifnet *ifp)
-{
- struct nve_softc *sc =3D ifp->if_softc;
- struct mii_data *mii;
- struct mii_softc *miisc;
-
- DEBUGOUT(NVE_DEBUG_MII, "nve: nve_ifmedia_upd\n");
-
- NVE_LOCK_ASSERT(sc);
- mii =3D device_get_softc(sc->miibus);
-
- LIST_FOREACH(miisc, &mii->mii_phys, mii_list)
- PHY_RESET(miisc);
- mii_mediachg(mii);
-}
-
-/* Update current miibus PHY status of media */
-static void
-nve_ifmedia_sts(struct ifnet *ifp, struct ifmediareq *ifmr)
-{
- struct nve_softc *sc;
- struct mii_data *mii;
-
- DEBUGOUT(NVE_DEBUG_MII, "nve: nve_ifmedia_sts\n");
-
- sc =3D ifp->if_softc;
- NVE_LOCK(sc);
- mii =3D device_get_softc(sc->miibus);
- mii_pollstat(mii);
-
- ifmr->ifm_active =3D mii->mii_media_active;
- ifmr->ifm_status =3D mii->mii_media_status;
- NVE_UNLOCK(sc);
-
- return;
-}
-
-/* miibus tick timer - maintain link status */
-static void
-nve_tick(void *xsc)
-{
- struct nve_softc *sc =3D xsc;
- struct mii_data *mii;
- struct ifnet *ifp;
-
- NVE_LOCK_ASSERT(sc);
-
- ifp =3D sc->ifp;
- nve_update_stats(sc);
-
- mii =3D device_get_softc(sc->miibus);
- mii_tick(mii);
-
- if (mii->mii_media_status & IFM_ACTIVE &&
- IFM_SUBTYPE(mii->mii_media_active) !=3D IFM_NONE) {
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- nve_ifstart_locked(ifp);
- }
-
- if (sc->tx_timer > 0 && --sc->tx_timer =3D=3D 0)
- nve_watchdog(sc);
- callout_reset(&sc->stat_callout, hz, nve_tick, sc);
-
- return;
-}
-
-/* Update ifnet data structure with collected interface stats from API *=
/
-static void
-nve_update_stats(struct nve_softc *sc)
-{
- struct ifnet *ifp =3D sc->ifp;
- ADAPTER_STATS stats;
-
- NVE_LOCK_ASSERT(sc);
-
- if (sc->hwapi) {
- sc->hwapi->pfnGetStatistics(sc->hwapi->pADCX, &stats);
-
- ifp->if_ipackets =3D stats.ulSuccessfulReceptions;
- ifp->if_ierrors =3D stats.ulMissedFrames +
- stats.ulFailedReceptions +
- stats.ulCRCErrors +
- stats.ulFramingErrors +
- stats.ulOverFlowErrors;
-
- ifp->if_opackets =3D stats.ulSuccessfulTransmissions;
- ifp->if_oerrors =3D sc->tx_errors +
- stats.ulFailedTransmissions +
- stats.ulRetryErrors +
- stats.ulUnderflowErrors +
- stats.ulLossOfCarrierErrors +
- stats.ulLateCollisionErrors;
-
- ifp->if_collisions =3D stats.ulLateCollisionErrors;
- }
-
- return;
-}
-
-/* miibus Read PHY register wrapper - calls Nvidia API entry point */
-static int
-nve_miibus_readreg(device_t dev, int phy, int reg)
-{
- struct nve_softc *sc =3D device_get_softc(dev);
- ULONG data;
-
- DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_readreg - entry\n");
-
- ADAPTER_ReadPhy(sc->hwapi->pADCX, phy, reg, &data);
-
- DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_readreg - exit\n");
-
- return (data);
-}
-
-/* miibus Write PHY register wrapper - calls Nvidia API entry point */
-static int
-nve_miibus_writereg(device_t dev, int phy, int reg, int data)
-{
- struct nve_softc *sc =3D device_get_softc(dev);
-
- DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_writereg - entry\n");
-
- ADAPTER_WritePhy(sc->hwapi->pADCX, phy, reg, (ulong)data);
-
- DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_writereg - exit\n");
-
- return 0;
-}
-
-/* Watchdog timer to prevent PHY lockups */
-static void
-nve_watchdog(struct nve_softc *sc)
-{
- struct ifnet *ifp;
- int pending_txs_start;
-
- NVE_LOCK_ASSERT(sc);
- ifp =3D sc->ifp;
-
- /*
- * The nvidia driver blob defers tx completion notifications.
- * Thus, sometimes the watchdog timer will go off when the
- * tx engine is fine, but the tx completions are just deferred.
- * Try kicking the driver blob to clear out any pending tx
- * completions. If that clears up any of the pending tx
- * operations, then just return without printing the warning
- * message or resetting the adapter, as we can then conclude
- * the chip hasn't actually crashed (it's still sending packets).
- */
- pending_txs_start =3D sc->pending_txs;
- sc->hwapi->pfnDisableInterrupts(sc->hwapi->pADCX);
- sc->hwapi->pfnHandleInterrupt(sc->hwapi->pADCX);
- sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX);
- if (sc->pending_txs < pending_txs_start)
- return;
-
- device_printf(sc->dev, "device timeout (%d)\n", sc->pending_txs);
-
- sc->tx_errors++;
-
- nve_stop(sc);
- nve_init_locked(sc);
-
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- nve_ifstart_locked(ifp);
-}
-
-/* --- Start of NVOSAPI interface --- */
-
-/* Allocate DMA enabled general use memory for API */
-static NV_API_CALL NV_SINT32
-nve_osalloc(PNV_VOID ctx, PMEMORY_BLOCK mem)
-{
- struct nve_softc *sc;
- bus_addr_t mem_physical;
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osalloc - %d\n", mem->uiLength);
-
- sc =3D (struct nve_softc *)ctx;
-
- mem->pLogical =3D (PVOID)contigmalloc(mem->uiLength, M_DEVBUF,
- M_NOWAIT | M_ZERO, 0, 0xffffffff, PAGE_SIZE, 0);
-
- if (!mem->pLogical) {
- device_printf(sc->dev, "memory allocation failed\n");
- return (0);
- }
- memset(mem->pLogical, 0, (ulong)mem->uiLength);
- mem_physical =3D vtophys(mem->pLogical);
- mem->pPhysical =3D (PVOID)mem_physical;
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osalloc 0x%x/0x%x - %d\n",
- (uint)mem->pLogical, (uint)mem->pPhysical, (uint)mem->uiLength);
-
- return (1);
-}
-
-/* Free allocated memory */
-static NV_API_CALL NV_SINT32
-nve_osfree(PNV_VOID ctx, PMEMORY_BLOCK mem)
-{
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osfree - 0x%x - %d\n",
- (uint)mem->pLogical, (uint) mem->uiLength);
-
- contigfree(mem->pLogical, PAGE_SIZE, M_DEVBUF);
- return (1);
-}
-
-/* Copied directly from nvnet.c */
-static NV_API_CALL NV_SINT32
-nve_osallocex(PNV_VOID ctx, PMEMORY_BLOCKEX mem_block_ex)
-{
- MEMORY_BLOCK mem_block;
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osallocex\n");
-
- mem_block_ex->pLogical =3D NULL;
- mem_block_ex->uiLengthOrig =3D mem_block_ex->uiLength;
-
- if ((mem_block_ex->AllocFlags & ALLOC_MEMORY_ALIGNED) &&
- (mem_block_ex->AlignmentSize > 1)) {
- DEBUGOUT(NVE_DEBUG_API, " aligning on %d\n",
- mem_block_ex->AlignmentSize);
- mem_block_ex->uiLengthOrig +=3D mem_block_ex->AlignmentSize;
- }
- mem_block.uiLength =3D mem_block_ex->uiLengthOrig;
-
- if (nve_osalloc(ctx, &mem_block) =3D=3D 0) {
- return (0);
- }
- mem_block_ex->pLogicalOrig =3D mem_block.pLogical;
- mem_block_ex->pPhysicalOrigLow =3D (unsigned long)mem_block.pPhysical;
- mem_block_ex->pPhysicalOrigHigh =3D 0;
-
- mem_block_ex->pPhysical =3D mem_block.pPhysical;
- mem_block_ex->pLogical =3D mem_block.pLogical;
-
- if (mem_block_ex->uiLength !=3D mem_block_ex->uiLengthOrig) {
- unsigned int offset;
- offset =3D mem_block_ex->pPhysicalOrigLow &
- (mem_block_ex->AlignmentSize - 1);
-
- if (offset) {
- mem_block_ex->pPhysical =3D
- (PVOID)((ulong)mem_block_ex->pPhysical +
- mem_block_ex->AlignmentSize - offset);
- mem_block_ex->pLogical =3D
- (PVOID)((ulong)mem_block_ex->pLogical +
- mem_block_ex->AlignmentSize - offset);
- } /* if (offset) */
- } /* if (mem_block_ex->uiLength !=3D *mem_block_ex->uiLengthOrig) */
- return (1);
-}
-
-/* Copied directly from nvnet.c */
-static NV_API_CALL NV_SINT32
-nve_osfreeex(PNV_VOID ctx, PMEMORY_BLOCKEX mem_block_ex)
-{
- MEMORY_BLOCK mem_block;
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osfreeex\n");
-
- mem_block.pLogical =3D mem_block_ex->pLogicalOrig;
- mem_block.pPhysical =3D (PVOID)((ulong)mem_block_ex->pPhysicalOrigLow);=
- mem_block.uiLength =3D mem_block_ex->uiLengthOrig;
-
- return (nve_osfree(ctx, &mem_block));
-}
-
-/* Clear memory region */
-static NV_API_CALL NV_SINT32
-nve_osclear(PNV_VOID ctx, PNV_VOID mem, NV_SINT32 length)
-{
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osclear\n");
- memset(mem, 0, length);
- return (1);
-}
-
-/* Sleep for a tick */
-static NV_API_CALL NV_SINT32
-nve_osdelay(PNV_VOID ctx, NV_UINT32 usec)
-{
- DELAY(usec);
- return (1);
-}
-
-/* Allocate memory for rx buffer */
-static NV_API_CALL NV_SINT32
-nve_osallocrxbuf(PNV_VOID ctx, PMEMORY_BLOCK mem, PNV_VOID *id)
-{
- struct nve_softc *sc =3D ctx;
- struct nve_rx_desc *desc;
- struct nve_map_buffer *buf;
- int error;
-
- if (device_is_attached(sc->dev))
- NVE_LOCK_ASSERT(sc);
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osallocrxbuf\n");
-
- if (sc->pending_rxs =3D=3D RX_RING_SIZE) {
- device_printf(sc->dev, "rx ring buffer is full\n");
- goto fail;
- }
- desc =3D sc->rx_desc + sc->cur_rx;
- buf =3D &desc->buf;
-
- if (buf->mbuf =3D=3D NULL) {
- buf->mbuf =3D m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR);
- if (buf->mbuf =3D=3D NULL) {
- device_printf(sc->dev, "failed to allocate memory\n");
- goto fail;
- }
- buf->mbuf->m_len =3D buf->mbuf->m_pkthdr.len =3D MCLBYTES;
- m_adj(buf->mbuf, ETHER_ALIGN);
-
- error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, buf->mbuf,
- nve_dmamap_rx_cb, &desc->paddr, 0);
- if (error) {
- device_printf(sc->dev, "failed to dmamap mbuf\n");
- m_freem(buf->mbuf);
- buf->mbuf =3D NULL;
- goto fail;
- }
- bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_PREREAD);
- desc->buflength =3D buf->mbuf->m_len;
- desc->vaddr =3D mtod(buf->mbuf, caddr_t);
- }
- sc->pending_rxs++;
- sc->cur_rx =3D (sc->cur_rx + 1) % RX_RING_SIZE;
-
- mem->pLogical =3D (void *)desc->vaddr;
- mem->pPhysical =3D (void *)desc->paddr;
- mem->uiLength =3D desc->buflength;
- *id =3D (void *)desc;
-
- return (1);
-=09
-fail:
- return (0);
-}
-
-/* Free the rx buffer */
-static NV_API_CALL NV_SINT32
-nve_osfreerxbuf(PNV_VOID ctx, PMEMORY_BLOCK mem, PNV_VOID id)
-{
- struct nve_softc *sc =3D ctx;
- struct nve_rx_desc *desc;
- struct nve_map_buffer *buf;
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_osfreerxbuf\n");
-
- desc =3D (struct nve_rx_desc *) id;
- buf =3D &desc->buf;
-
- if (buf->mbuf) {
- bus_dmamap_unload(sc->mtag, buf->map);
- bus_dmamap_destroy(sc->mtag, buf->map);
- m_freem(buf->mbuf);
- }
- sc->pending_rxs--;
- buf->mbuf =3D NULL;
-
- return (1);
-}
-
-/* This gets called by the Nvidia API after our TX packet has been sent =
*/
-static NV_API_CALL NV_SINT32
-nve_ospackettx(PNV_VOID ctx, PNV_VOID id, NV_UINT32 success)
-{
- struct nve_softc *sc =3D ctx;
- struct nve_map_buffer *buf;
- struct nve_tx_desc *desc =3D (struct nve_tx_desc *) id;
- struct ifnet *ifp;
-
- NVE_LOCK_ASSERT(sc);
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_ospackettx\n");
-
- ifp =3D sc->ifp;
- buf =3D &desc->buf;
- sc->pending_txs--;
-
- /* Unload and free mbuf cluster */
- if (buf->mbuf =3D=3D NULL)
- goto fail;
-
- bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTWRITE);
- bus_dmamap_unload(sc->mtag, buf->map);
- m_freem(buf->mbuf);
- buf->mbuf =3D NULL;
-
- /* Send more packets if we have them */
- if (sc->pending_txs < TX_RING_SIZE)
- sc->ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE;
-
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd) && sc->pending_txs < TX_RING_SIZE)
- nve_ifstart_locked(ifp);
-
-fail:
-
- return (1);
-}
-
-/* This gets called by the Nvidia API when a new packet has been receive=
d */
-/* XXX What is newbuf used for? XXX */
-static NV_API_CALL NV_SINT32
-nve_ospacketrx(PNV_VOID ctx, PNV_VOID data, NV_UINT32 success, NV_UINT8 =
*newbuf,
- NV_UINT8 priority)
-{
- struct nve_softc *sc =3D ctx;
- struct ifnet *ifp;
- struct nve_rx_desc *desc;
- struct nve_map_buffer *buf;
- ADAPTER_READ_DATA *readdata;
- struct mbuf *m;
-
- NVE_LOCK_ASSERT(sc);
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_ospacketrx\n");
-
- ifp =3D sc->ifp;
-
- readdata =3D (ADAPTER_READ_DATA *) data;
- desc =3D readdata->pvID;
- buf =3D &desc->buf;
- bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTREAD);
-
- if (success) {
- /* Sync DMA bounce buffer. */
- bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTREAD);
-
- /* First mbuf in packet holds the ethernet and packet headers */
- buf->mbuf->m_pkthdr.rcvif =3D ifp;
- buf->mbuf->m_pkthdr.len =3D buf->mbuf->m_len =3D
- readdata->ulTotalLength;
-
- bus_dmamap_unload(sc->mtag, buf->map);
-
- /* Blat the mbuf pointer, kernel will free the mbuf cluster */
- m =3D buf->mbuf;
- buf->mbuf =3D NULL;
-
- /* Give mbuf to OS. */
- NVE_UNLOCK(sc);
- (*ifp->if_input)(ifp, m);
- NVE_LOCK(sc);
- if (readdata->ulFilterMatch & ADREADFL_MULTICAST_MATCH)
- ifp->if_imcasts++;
-
- } else {
- bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTREAD);
- bus_dmamap_unload(sc->mtag, buf->map);
- m_freem(buf->mbuf);
- buf->mbuf =3D NULL;
- }
-
- sc->cur_rx =3D desc - sc->rx_desc;
- sc->pending_rxs--;
-
- return (1);
-}
-
-/* This gets called by NVIDIA API when the PHY link state changes */
-static NV_API_CALL NV_SINT32
-nve_oslinkchg(PNV_VOID ctx, NV_SINT32 enabled)
-{
-
- DEBUGOUT(NVE_DEBUG_API, "nve: nve_oslinkchg\n");
-
- return (1);
-}
-
-/* Setup a watchdog timer */
-static NV_API_CALL NV_SINT32
-nve_osalloctimer(PNV_VOID ctx, PNV_VOID *timer)
-{
- struct nve_softc *sc =3D (struct nve_softc *)ctx;
-
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osalloctimer\n");
-
- callout_init(&sc->ostimer, CALLOUT_MPSAFE);
- *timer =3D &sc->ostimer;
-
- return (1);
-}
-
-/* Free the timer */
-static NV_API_CALL NV_SINT32
-nve_osfreetimer(PNV_VOID ctx, PNV_VOID timer)
-{
-
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osfreetimer\n");
-
- callout_drain((struct callout *)timer);
-
- return (1);
-}
-
-/* Setup timer parameters */
-static NV_API_CALL NV_SINT32
-nve_osinittimer(PNV_VOID ctx, PNV_VOID timer, PTIMER_FUNC func, PNV_VOID=
parameters)
-{
- struct nve_softc *sc =3D (struct nve_softc *)ctx;
-
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osinittimer\n");
-
- sc->ostimer_func =3D func;
- sc->ostimer_params =3D parameters;
-
- return (1);
-}
-
-/* Set the timer to go off */
-static NV_API_CALL NV_SINT32
-nve_ossettimer(PNV_VOID ctx, PNV_VOID timer, NV_UINT32 delay)
-{
- struct nve_softc *sc =3D ctx;
-
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_ossettimer\n");
-
- callout_reset((struct callout *)timer, delay, sc->ostimer_func,
- sc->ostimer_params);
-
- return (1);
-}
-
-/* Cancel the timer */
-static NV_API_CALL NV_SINT32
-nve_oscanceltimer(PNV_VOID ctx, PNV_VOID timer)
-{
-
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_oscanceltimer\n");
-
- callout_stop((struct callout *)timer);
-
- return (1);
-}
-
-static NV_API_CALL NV_SINT32
-nve_ospreprocpkt(PNV_VOID ctx, PNV_VOID readdata, PNV_VOID *id,
- NV_UINT8 *newbuffer, NV_UINT8 priority)
-{
-
- /* Not implemented */
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_ospreprocpkt\n");
-
- return (1);
-}
-
-static NV_API_CALL PNV_VOID
-nve_ospreprocpktnopq(PNV_VOID ctx, PNV_VOID readdata)
-{
-
- /* Not implemented */
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_ospreprocpkt\n");
-
- return (NULL);
-}
-
-static NV_API_CALL NV_SINT32
-nve_osindicatepkt(PNV_VOID ctx, PNV_VOID *id, NV_UINT32 pktno)
-{
-
- /* Not implemented */
- DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osindicatepkt\n");
-
- return (1);
-}
-
-/* Allocate mutex context (already done in nve_attach) */
-static NV_API_CALL NV_SINT32
-nve_oslockalloc(PNV_VOID ctx, NV_SINT32 type, PNV_VOID *pLock)
-{
- struct nve_softc *sc =3D (struct nve_softc *)ctx;
-
- DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_oslockalloc\n");
-
- *pLock =3D (void **)sc;
-
- return (1);
-}
-
-/* Obtain a spin lock */
-static NV_API_CALL NV_SINT32
-nve_oslockacquire(PNV_VOID ctx, NV_SINT32 type, PNV_VOID lock)
-{
-
- DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_oslockacquire\n");
-
- return (1);
-}
-
-/* Release lock */
-static NV_API_CALL NV_SINT32
-nve_oslockrelease(PNV_VOID ctx, NV_SINT32 type, PNV_VOID lock)
-{
-
- DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_oslockrelease\n");
-
- return (1);
-}
-
-/* I have no idea what this is for */
-static NV_API_CALL PNV_VOID
-nve_osreturnbufvirt(PNV_VOID ctx, PNV_VOID readdata)
-{
-
- /* Not implemented */
- DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_osreturnbufvirt\n");
- panic("nve: nve_osreturnbufvirtual not implemented\n");
-
- return (NULL);
-}
-
-/* --- End on NVOSAPI interface --- */
Index: sys/dev/nve/if_nvereg.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/dev/nve/if_nvereg.h (revision 261434)
+++ sys/dev/nve/if_nvereg.h (working copy)
@@ -1,193 +0,0 @@
-/*
- * Copyright (c) 2005 by David E. O'Brien <obrien@FreeBSD.org>.
- * Copyright (c) 2003 by Quinton Dolan <q@onthenet.com.au>.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in th=
e
- * documentation and/or other materials provided with the distributio=
n.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS `AS IS'' AND=
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU=
RPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB=
LE=20
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE=
NTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO=
DS=20
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)=
=20
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S=
TRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY=
WAY=20
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O=
F=20
- * SUCH DAMAGE.
- *
- * $Id: if_nvreg.h,v 1.6 2004/08/12 14:00:05 q Exp $
- * $FreeBSD$
- */
-=20
-#ifndef _IF_NVEREG_H_
-#define _IF_NVEREG_H_
-
-#ifndef PCI_VENDOR_NVIDIA
-#define PCI_VENDOR_NVIDIA 0x10DE
-#endif
-
-#define PCI_PRODUCT_NVIDIA_NFORCE_LAN 0x01C3
-#define PCI_PRODUCT_NVIDIA_NFORCE2_LAN 0x0066
-#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN1 0x00D6
-#define PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN1 0x0086
-#define PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN2 0x008C
-#define PCI_PRODUCT_NVIDIA_NFORCE3_250_LAN 0x00E6
-#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN4 0x00DF
-#define PCI_PRODUCT_NVIDIA_NFORCE4_LAN1 0x0056
-#define PCI_PRODUCT_NVIDIA_NFORCE4_LAN2 0x0057
-#define PCI_PRODUCT_NVIDIA_MCP04_LAN1 0x0037
-#define PCI_PRODUCT_NVIDIA_MCP04_LAN2 0x0038
-#define PCI_PRODUCT_NVIDIA_NFORCE430_LAN1 0x0268
-#define PCI_PRODUCT_NVIDIA_NFORCE430_LAN2 0x0269
-#define PCI_PRODUCT_NVIDIA_MCP55_LAN1 0x0372
-#define PCI_PRODUCT_NVIDIA_MCP55_LAN2 0x0373
-#define PCI_PRODUCT_NVIDIA_MCP61_LAN1 0x03e5
-#define PCI_PRODUCT_NVIDIA_MCP61_LAN2 0x03e6
-#define PCI_PRODUCT_NVIDIA_MCP61_LAN3 0x03ee
-#define PCI_PRODUCT_NVIDIA_MCP61_LAN4 0x03ef
-#define PCI_PRODUCT_NVIDIA_MCP65_LAN1 0x0450
-#define PCI_PRODUCT_NVIDIA_MCP65_LAN2 0x0451
-#define PCI_PRODUCT_NVIDIA_MCP65_LAN3 0x0452
-#define PCI_PRODUCT_NVIDIA_MCP65_LAN4 0x0453
-
-#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN2 PCI_PRODUCT_NVIDIA_NFORCE2_400_L=
AN1
-#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN3 PCI_PRODUCT_NVIDIA_NFORCE2_400_L=
AN2
-#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN5 PCI_PRODUCT_NVIDIA_NFORCE3_250_L=
AN
-#define PCI_PRODUCT_NVIDIA_CK804_LAN1 PCI_PRODUCT_NVIDIA_NFORCE4_LAN1
-#define PCI_PRODUCT_NVIDIA_CK804_LAN2 PCI_PRODUCT_NVIDIA_NFORCE4_LAN2
-#define PCI_PRODUCT_NVIDIA_MCP51_LAN1 PCI_PRODUCT_NVIDIA_NFORCE430_LAN1
-#define PCI_PRODUCT_NVIDIA_MCP51_LAN2 PCI_PRODUCT_NVIDIA_NFORCE430_LAN2
-
-#define NV_RID 0x10
-
-#define TX_RING_SIZE 64
-#define RX_RING_SIZE 64
-#define NV_MAX_FRAGS 32 // match adapter.h:ADAPTER_WRITE_DATA.sElement[]=
-
-#define FCS_LEN 4
-
-#define NVE_DEBUG 0x0000
-#define NVE_DEBUG_INIT 0x0001
-#define NVE_DEBUG_RUNNING 0x0002
-#define NVE_DEBUG_DEINIT 0x0004
-#define NVE_DEBUG_IOCTL 0x0008
-#define NVE_DEBUG_INTERRUPT 0x0010
-#define NVE_DEBUG_API 0x0020
-#define NVE_DEBUG_LOCK 0x0040
-#define NVE_DEBUG_BROKEN 0x0080
-#define NVE_DEBUG_MII 0x0100
-#define NVE_DEBUG_ALL 0xFFFF
-
-#if NVE_DEBUG
-#define DEBUGOUT(level, fmt, args...) if (NVE_DEBUG & level) \
- printf(fmt, ## args)
-#else
-#define DEBUGOUT(level, fmt, args...)
-#endif
-
-typedef unsigned long ulong;
-
-struct nve_map_buffer {
- struct mbuf *mbuf; /* mbuf receiving packet */
- bus_dmamap_t map; /* DMA map */=09
-};
-
-struct nve_dma_info {
- bus_dma_tag_t tag;
- struct nve_map_buffer buf;
- u_int16_t buflength;
- caddr_t vaddr; /* Virtual memory address */
- bus_addr_t paddr; /* DMA physical address */
-};
-
-struct nve_rx_desc {
- struct nve_rx_desc *next;
- struct nve_map_buffer buf;
- u_int16_t buflength;
- caddr_t vaddr;
- bus_addr_t paddr;
-};
-
-struct nve_tx_desc {
- /* Don't add anything above this structure */
- TX_INFO_ADAP TxInfoAdap;
- struct nve_tx_desc *next;
- struct nve_map_buffer buf;
- u_int16_t buflength;
- u_int32_t numfrags;
- bus_dma_segment_t frags[NV_MAX_FRAGS];
-};
-
-struct nve_softc {
- struct ifnet *ifp; /* interface info */
- struct resource *res;
- struct resource *irq;
-
- ADAPTER_API *hwapi;
- OS_API osapi;
- =09
- device_t miibus;
- device_t dev;
- struct callout stat_callout;
- int tx_timer;
-
- void *sc_ih;
- bus_space_tag_t sc_st;
- bus_space_handle_t sc_sh;
- bus_dma_tag_t mtag;
- bus_dma_tag_t rtag;
- bus_dmamap_t rmap;
- bus_dma_tag_t ttag;
- bus_dmamap_t tmap;
-
- struct nve_rx_desc *rx_desc;
- struct nve_tx_desc *tx_desc;
- bus_addr_t rx_addr;
- bus_addr_t tx_addr;
- u_int16_t rx_ring_full;
- u_int16_t tx_ring_full;
- u_int32_t cur_rx;
- u_int32_t cur_tx;
- u_int32_t pending_rxs;
- u_int32_t pending_txs;
-
- struct mtx mtx;
-
- /* Stuff for dealing with the NVIDIA OS API */
- struct callout ostimer;
- PTIMER_FUNC ostimer_func;
- void *ostimer_params;
- int linkup;
- ulong tx_errors;
- NV_UINT32 hwmode;
- NV_UINT32 max_frame_size;
- NV_UINT32 phyaddr;
- NV_UINT32 media;
- CMNDATA_OS_ADAPTER adapterdata;
- unsigned char original_mac_addr[6];
-};
-
-struct nve_type {
- u_int16_t vid_id;
- u_int16_t dev_id;
- char *name;
-};
-
-#define NVE_LOCK(_sc) mtx_lock(&(_sc)->mtx)
-#define NVE_UNLOCK(_sc) mtx_unlock(&(_sc)->mtx)
-#define NVE_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->mtx, MA_OWNED)
-
-extern int ADAPTER_ReadPhy (PVOID pContext, ULONG ulPhyAddr, ULONG ulReg=
, ULONG *pulVal);
-extern int ADAPTER_WritePhy (PVOID pContext, ULONG ulPhyAddr, ULONG ulRe=
g, ULONG ulVal);
-extern int ADAPTER_Init (PVOID pContext, USHORT usForcedSpeed, UCHAR ucF=
orceDpx, UCHAR ucForceMode, UINT *puiLinkState);
-
-#endif /* _IF_NVEREG_H_ */
Index: sys/i386/conf/GENERIC
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/i386/conf/GENERIC (revision 261434)
+++ sys/i386/conf/GENERIC (working copy)
@@ -245,7 +245,6 @@
device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet
device nfe # nVidia nForce MCP on-board Ethernet
device nge # NatSemi DP83820 gigabit Ethernet
-#device nve # nVidia nForce MCP on-board Ethernet Networking
device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le')
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139
Index: sys/i386/conf/NOTES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/i386/conf/NOTES (revision 261434)
+++ sys/i386/conf/NOTES (working copy)
@@ -581,7 +581,6 @@
# mlxen: Mellanox ConnectX HCA Ethernet
# mthca: Mellanox HCA InfiniBand
# nfe: nVidia nForce MCP on-board Ethernet Networking (BSD open source)
-# nve: nVidia nForce MCP on-board Ethernet Networking
# sbni: Granch SBNI12-xx ISA and PCI adapters
# vmx: VMware VMXNET3 Ethernet (BSD open source)
# wl: Lucent Wavelan (ISA card only).
@@ -628,7 +627,6 @@
device mlxen # Mellanox ConnectX HCA Ethernet
device mthca # Mellanox HCA InfiniBand
device nfe # nVidia nForce MCP on-board Ethernet
-device nve # nVidia nForce MCP on-board Ethernet Networking
device sbni
hint.sbni.0.at=3D"isa"
hint.sbni.0.port=3D"0x210"
Index: sys/i386/conf/PAE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/i386/conf/PAE (revision 261434)
+++ sys/i386/conf/PAE (working copy)
@@ -54,7 +54,6 @@
nodevice txp
nodevice vx
=20
-nodevice nve
nodevice pcn
nodevice sf
nodevice sis
Index: sys/i386/conf/XEN
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/i386/conf/XEN (revision 261434)
+++ sys/i386/conf/XEN (working copy)
@@ -7,7 +7,7 @@
ident XEN
=20
makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols
-makeoptions WITHOUT_MODULES=3D"aha ahb amd ctl cxgb dpt drm drm2 hptnr h=
ptmv ida malo mps mwl nve rdma sound sym trm xfs"
+makeoptions WITHOUT_MODULES=3D"aha ahb amd ctl cxgb dpt drm drm2 hptnr h=
ptmv ida malo mps mwl rdma sound sym trm xfs"
=20
options SCHED_ULE # ULE scheduler
options PREEMPTION # Enable kernel thread preemption
Index: sys/mips/conf/OCTEON1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/mips/conf/OCTEON1 (revision 261434)
+++ sys/mips/conf/OCTEON1 (working copy)
@@ -218,7 +218,6 @@
device lge # Level 1 LXT1001 gigabit Ethernet
device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet
device nge # NatSemi DP83820 gigabit Ethernet
-#device nve # nVidia nForce MCP on-board Ethernet Networking
device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le')
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139
Index: sys/modules/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/modules/Makefile (revision 261434)
+++ sys/modules/Makefile (working copy)
@@ -251,7 +251,6 @@
nullfs \
${_ntb} \
${_nvd} \
- ${_nve} \
${_nvme} \
${_nvram} \
${_nxge} \
@@ -609,9 +608,6 @@
_mly=3D mly
_nfe=3D nfe
_nvd=3D nvd
-.if ${MK_SOURCELESS_HOST} !=3D "no"
-_nve=3D nve
-.endif
_nvme=3D nvme
_nvram=3D nvram
_nxge=3D nxge
@@ -730,9 +726,6 @@
_nfe=3D nfe
_ntb=3D ntb
_nvd=3D nvd
-.if ${MK_SOURCELESS_HOST} !=3D "no"
-_nve=3D nve
-.endif
_nvme=3D nvme
_nvram=3D nvram
_nxge=3D nxge
Index: sys/modules/nve/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/modules/nve/Makefile (revision 261434)
+++ sys/modules/nve/Makefile (working copy)
@@ -1,20 +0,0 @@
-# $FreeBSD$
-
-.PATH: ${.CURDIR}/../../dev/nve
-
-KMOD=3D if_nve
-SRCS=3D if_nve.c if_nvereg.h miidevs.h \
- device_if.h bus_if.h pci_if.h miibus_if.h \
- os+%DIKED-nve.h
-OBJS+=3D nvenetlib.o
-WERROR=3D
-
-CLEANFILES+=3D nvenetlib.o os+%DIKED-nve.h
-nvenetlib.o: ${.CURDIR}/../../contrib/dev/nve/${MACHINE}/${.TARGET}.bz2.=
uu
- uudecode < ${.CURDIR}/../../contrib/dev/nve/${MACHINE}/${.TARGET}.bz2.u=
u
- bzip2 -df ${.TARGET}.bz2
-
-os+%DIKED-nve.h: ${.CURDIR}/../../contrib/dev/nve/os.h
- sed -e 's/^.*#include.*phy\.h.*$$//' ${.OODATE} > ${.TARGET}
-
-.include <bsd.kmod.mk>
--------------040205050306080801060107--
--fiVRRWfOLp81fpU4PaJraA20cOanR3h3B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJ8BAEBCgBmBQJS8JmaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QzhCQjQ5MDgzNDUwNjkyOUM5Mjg2NDE3
OEM4MzY5ODQ3RTE2NDg3AAoJEHjINphH4WSHLxcP/0QWQJh0rgtfiolgYkvcYG+3
O2w/toyqO5SGEfVh8GP4aT9jTi6H7C/WpbkfsWSokNigoH8YAuB+Omuco4TYulf/
/gyySjmVF2NMSpakQkye1rQIv3hKidwHfRWuIYBPfRXHmwjwNZIwAxNBp/1P65Qw
U1ZbqyBkhv0kpKfqGturvCV+6GjDpfmAw6eaVN9CntNXInr+EtIwatTN3oMbpYVY
15HG4ZM4J/Vli+V/rYNMKsRWzETFpNZHHmb1m5SFLQh2qfr18GhJnW/gX+o0fP8L
UwNtntFsqEBLbuObajAwTcalUG4X1y+2QvD/HYy6ivimCd2qbi1L2YaBn7BB6A57
JBM9xsTtJRMgiFoxVNuyfgm9w5fVSgBnWzob7ovhH4m2mxvq+9ZIxy38HF2CD1B+
t2wTd5fR3wjka5fqhWVNa4Bb5b2XbklCDVK9Q2Q3fH8LZZM5AIEpdnBaptrT7K8q
aAaqWviDEL6BA3QCK0aHirumYnL8ZtbdL24Kf9M/bjojsH5KkcqDo8AU8dLCwrGN
ZxunOV4Sfw7BDLAyaHVryXz/n4x65XHjbJc7DKeYsv4xfCs4h1/RxnT/4Xv+mdZ4
ST9TEuRFMfRowkBaNrxNuDj7R+oEA/eb9Dgx3kugX0ned5fYGoJrOi1FwJewiqlk
1IZjS6BAgr6Us624pQC9
=HlBj
-----END PGP SIGNATURE-----
--fiVRRWfOLp81fpU4PaJraA20cOanR3h3B--
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 09:03:08 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 5944C1F1
for <current@freebsd.org>; Tue, 4 Feb 2014 09:03:08 +0000 (UTC)
Received: from brane.freislich.nom.za (www.freislich.nom.za [41.154.0.9])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id CA97513D3
for <current@freebsd.org>; Tue, 4 Feb 2014 09:03:06 +0000 (UTC)
Received: from 41-135-65-214.dsl.mweb.co.za ([41.135.65.214] helo=clue.co.za)
by brane.freislich.nom.za with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.82 (FreeBSD)) (envelope-from <ianf@clue.co.za>)
id 1WAbIt-000KVG-B4
for current@freebsd.org; Tue, 04 Feb 2014 10:24:23 +0200
Received: from localhost ([127.0.0.1] helo=zen)
by clue.co.za with esmtp (Exim 4.82 (FreeBSD))
(envelope-from <ianf@clue.co.za>) id 1WAbIj-000GeW-ME
for current@freebsd.org; Tue, 04 Feb 2014 10:24:13 +0200
To: current@freebsd.org
Subject: sshd sandbox failure
From: "Ian FREISLICH" <ianf@clue.co.za>
X-Attribution: BOFH
Date: Tue, 04 Feb 2014 10:24:13 +0200
Message-Id: <E1WAbIj-000GeW-ME@clue.co.za>
X-Generic-rDNS: 41.135.65.214
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 09:03:08 -0000
Hi
Since the openssh update in recent -CURRENT, I get these in my
auth.log until I disable sandbox UsePrivilegeSeparation in sshd_config.
Feb 3 10:02:14 firewall1 sshd[90062]: fatal: ssh_sandbox_child: failed to limit the network socket [preauth]
Is there something that I missed during the update?
Ian
--
Ian Freislich
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 09:09:16 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 0F31A7E1
for <current@freebsd.org>; Tue, 4 Feb 2014 09:09:16 +0000 (UTC)
Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id BEFFF1450
for <current@freebsd.org>; Tue, 4 Feb 2014 09:09:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net;
s=ffe;
h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Cc:To:Subject:From:Date;
bh=OYjjOoOLeqZt78Xo1Nvw+JH4etW2+nI5qjhg/5IZa5w=;
b=pxfvSfWhYyQLZ8h5uY+44zJ/5hSc7Vbpgc8clkFnqG0fAIKB+r54lwuGY2MzJBe0pBh7MF15t9K863Bz24xATycQCxHBJRgqA7rvKfm0rtZb67d7vRTmPpalYx0DHTTkpjey9P79ZJ38BYTQjHkH+T/odtf1IuTJzRSd+/mb7jg=;
Received: from [10.10.10.45] (helo=frv45.fwdcdn.com)
by frv199.fwdcdn.com with smtp ID 1WAc09-000D7m-02
for current@freebsd.org; Tue, 04 Feb 2014 11:09:05 +0200
Date: Tue, 04 Feb 2014 11:09:04 +0200
From: Vladimir Sharun <atz@ukr.net>
Subject: Re: sshd sandbox failure
To: Ian FREISLICH <ianf@clue.co.za>
X-Mailer: mail.ukr.net 5.0
Message-Id: <1391504944.471550214.2ympamlo@frv45.fwdcdn.com>
MIME-Version: 1.0
Received: from atz@ukr.net by frv45.fwdcdn.com; Tue, 04 Feb 2014 11:09:04 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: binary
Content-Disposition: inline
Cc: current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 09:09:16 -0000
Dear Ian,
Seems it must be in UPDATING or even in the buildworld: without capsicum framework support no ssh access to the server anymore.
I step in the same problem this weekend, thank to the IPMI on the home testebed I figured out what's the cause.
> Hi
>
> Since the openssh update in recent -CURRENT, I get these in my
> auth.log until I disable sandbox UsePrivilegeSeparation in sshd_config.
>
> Feb 3 10:02:14 firewall1 sshd[90062]: fatal: ssh_sandbox_child: failed to limit the network socket [preauth]
>
> Is there something that I missed during the update?
>
> Ian
>
> --
> Ian Freislich
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 09:17:52 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 7A664C12;
Tue, 4 Feb 2014 09:17:52 +0000 (UTC)
Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202])
by mx1.freebsd.org (Postfix) with ESMTP id 2D1F01537;
Tue, 4 Feb 2014 09:17:52 +0000 (UTC)
Received: from mail.lockless.no (mail.lockless.no [46.29.221.38])
by mta05.bitpro.no (Postfix) with ESMTPS id 32D1C17FC4F;
Tue, 4 Feb 2014 10:17:44 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by mail.lockless.no (Postfix) with ESMTP id F09358FD22E;
Tue, 4 Feb 2014 10:18:36 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no
Received: from mail.lockless.no ([127.0.0.1])
by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id LVD2G26udAZa; Tue, 4 Feb 2014 10:18:36 +0100 (CET)
Received: from laptop015.home.selasky.org
(cm-176.74.213.204.customer.telag.net [176.74.213.204])
by mail.lockless.no (Postfix) with ESMTPSA id 3232C8FD22B;
Tue, 4 Feb 2014 10:18:36 +0100 (CET)
Message-ID: <52F0B074.4020305@bitfrost.no>
Date: Tue, 04 Feb 2014 10:18:44 +0100
From: Hans Petter Selasky <hps@bitfrost.no>
Organization: Bitfrost A/S
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Danilo E. Gondolfo" <danilo@freebsd.org>,
freebsd-current@freebsd.org, =?UTF-8?B?Ium7hOaWh+i+iUBHbWFpbCI=?=
<huanghwh@gmail.com>
Subject: Re: Apple Trackpad driver
References: <CAB8uncaLEn4CaJv8+owESe_zUUK+gem_bXpEjhsOJE69m_fWAg@mail.gmail.com>
<CAJ-Vmon4Gk6bqoT+Jf-bRxE0+NJ1NjR0wjum-HjoVFDN-2e=8Q@mail.gmail.com>
<CAASDrV=pbDpZCGvEjnD8VS0D_HyC8=L3jQ7rfGszG6=PtxaE3Q@mail.gmail.com>
<CAASDrVmqijq51OEH7USLutPSgme7YWhXZZX4tGROLHVPoz2VkA@mail.gmail.com>
<52E8DDA3.3070301@bitfrost.no>
<CAB8uncZVCbFWhJrEosRtRebRip4HjArsZx9FwKE0q9EjYDncmg@mail.gmail.com>
<52E9F546.9090005@bitfrost.no>
<CAB8unca0ViSrg9ExGX+sEfQta9AAXbkKoaGr8RLX1-ksay2tog@mail.gmail.com>
<52EB4DBE.20501@bitfrost.no> <52EC07CE.70608@freebsd.org>
<52EC9D23.3030301@bitfrost.no> <52EC9FC5.4050602@bitfrost.no>
In-Reply-To: <52EC9FC5.4050602@bitfrost.no>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 09:17:52 -0000
On 02/01/14 08:18, Hans Petter Selasky wrote:
> On 02/01/14 08:07, Hans Petter Selasky wrote:
>> On 01/31/14 21:30, Danilo E. Gondolfo wrote:
>>> I noticed that your driver is based on the Linux driver [1] and some
>>> pieces of code are copied, are you sure that we won't have any problems
>>> with license?
>>
> Hi,
>
> If the Linux guys think this is a big problem, we can support this
> hardware through /usr/ports/multimedia/webcamd, quite easily. Although a
> kernel driver would be best for this type of device.
>
> Thank you!
FYI
Feedback from Greg: "That's great to hear, nice job!"
--HPS
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 10:08:33 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id B7F70D2B
for <freebsd-current@freebsd.org>; Tue, 4 Feb 2014 10:08:33 +0000 (UTC)
Received: from hell.ukr.net (hell.ukr.net [212.42.67.68])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 5B7561976
for <freebsd-current@freebsd.org>; Tue, 4 Feb 2014 10:08:33 +0000 (UTC)
Received: from satan by hell.ukr.net with local ID 1WAcvX-000Ow3-Gu
; Tue, 04 Feb 2014 12:08:23 +0200
Date: Tue, 4 Feb 2014 12:08:23 +0200
From: Vitalij Satanivskij <satan@ukr.net>
To: Vitalij Satanivskij <satan@ukr.net>
Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to
text/plain)
Message-ID: <20140204100823.GA95709@hell.ukr.net>
References: <1389005433.815055146.2dcjke36@frv45.ukr.net>
<52CA9963.1050507@FreeBSD.org>
<1389676958.516993176.oq4lbgg7@frv45.ukr.net>
<52D59E36.9040405@FreeBSD.org>
<20140115102837.GA98983@hell.ukr.net>
<52D66DB6.7030807@FreeBSD.org>
<1390900795.258244476.v35k1338@frv45.ukr.net>
<52EA3459.3070300@FreeBSD.org>
<1391083826.948700370.cmzf8475@frv45.ukr.net>
<20140131182637.GA82526@hell.ukr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140131182637.GA82526@hell.ukr.net>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: Vladimir Sharun <atz@ukr.net>,
Current FreeBSD <freebsd-current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 10:08:33 -0000
Dear Andriy and FreeBSD community,
With patch system panic on boot.
After remove cache device from pool system boot without problem.
After this cache added again and sone kernel panic happened
Screen shot of panic here http://i61.tinypic.com/30sbx2g.jpg
Vitalij Satanivskij wrote:
VS> Dear Andriy and FreeBSD community,
VS>
VS> Build world with path failed with error
VS>
VS> /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4642:13: error: use of
VS> undeclared identifier 'l2hdr'
VS> ASSERT3P(l2hdr->b_tmp_cdata, ==, NULL);
VS> ^
VS> /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys/debug.h:125:40: note: expanded from
VS> macro 'ASSERT3P'
VS> #define ASSERT3P(x, y, z) VERIFY3_IMPL(x, y, z, uintptr_t)
VS> ^
VS> /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys/debug.h:109:29: note: expanded from
VS> macro 'VERIFY3_IMPL'
VS> const TYPE __left = (TYPE)(LEFT); \
VS> ^
VS> 1 error generated.
VS> *** Error code 1
VS>
VS>
VS>
VS> Vladimir Sharun wrote:
VS> VS> Dear Andriy and FreeBSD community,
VS> VS>
VS> VS> L2ARC temporarily turned off by setting secondarycache=none everywhere it was enabled,
VS> VS> so no more leak for one particular day.
VS> VS>
VS> VS> Here's the top header:
VS> VS> last pid: 89916; load averages: 2.49, 2.91, 2.89 up 5+19:21:42 14:09:12
VS> VS> 561 processes: 2 running, 559 sleeping
VS> VS> CPU: 5.7% user, 0.0% nice, 14.0% system, 1.0% interrupt, 79.3% idle
VS> VS> Mem: 23G Active, 1017M Inact, 98G Wired, 1294M Cache, 3285M Buf, 1997M Free
VS> VS> ARC: 69G Total, 3498M MFU, 59G MRU, 53M Anon, 1651M Header, 4696M Other
VS> VS> Swap:
VS> VS>
VS> VS> Here's the calculated vmstat -z (mean all of the allocations, which exceeds 100*1024^2 printed):
VS> VS> UMA Slabs: 199,915M
VS> VS> VM OBJECT: 207,354M
VS> VS> 32: 205,558M
VS> VS> 64: 901,122M
VS> VS> 128: 215,211M
VS> VS> 256: 242,262M
VS> VS> 4096: 2316,01M
VS> VS> range_seg_cache: 205,396M
VS> VS> zio_buf_512: 1103,31M
VS> VS> zio_buf_16384: 15697,9M
VS> VS> zio_data_buf_16384: 348,297M
VS> VS> zio_data_buf_24576: 129,352M
VS> VS> zio_data_buf_32768: 104,375M
VS> VS> zio_data_buf_36864: 163,371M
VS> VS> zio_data_buf_53248: 100,496M
VS> VS> zio_data_buf_57344: 105,93M
VS> VS> zio_data_buf_65536: 101,75M
VS> VS> zio_data_buf_73728: 111,938M
VS> VS> zio_data_buf_90112: 104,414M
VS> VS> zio_data_buf_106496: 100,242M
VS> VS> zio_data_buf_131072: 61652,5M
VS> VS> dnode_t: 3203,98M
VS> VS> dmu_buf_impl_t: 797,695M
VS> VS> arc_buf_hdr_t: 1498,76M
VS> VS> arc_buf_t: 105,802M
VS> VS> zfs_znode_cache: 352,61M
VS> VS>
VS> VS> zio_data_buf_131072 (61652M) + zio_buf_16384 (15698M) = 77350M
VS> VS> easily exceeds ARC total (70G)
VS> VS>
VS> VS>
VS> VS> Here's the same calculations from exact the same system where L2 was disabled before reboot:
VS> VS> last pid: 63407; load averages: 2.35, 2.71, 2.73 up 8+19:42:54 14:17:33
VS> VS> 527 processes: 1 running, 526 sleeping
VS> VS> CPU: 4.8% user, 0.0% nice, 6.6% system, 1.1% interrupt, 87.4% idle
VS> VS> Mem: 21G Active, 1460M Inact, 99G Wired, 1748M Cache, 3308M Buf, 952M Free
VS> VS> ARC: 87G Total, 4046M MFU, 76G MRU, 37M Anon, 2026M Header, 4991M Other
VS> VS> Swap:
VS> VS>
VS> VS> and the vmstat -z filtered:
VS> VS> UMA Slabs: 208,004M
VS> VS> VM OBJECT: 207,392M
VS> VS> 32: 172,831M
VS> VS> 64: 752,226M
VS> VS> 128: 210,024M
VS> VS> 256: 244,204M
VS> VS> 4096: 2249,02M
VS> VS> range_seg_cache: 245,711M
VS> VS> zio_buf_512: 1145,25M
VS> VS> zio_buf_16384: 15170,1M
VS> VS> zio_data_buf_16384: 422,766M
VS> VS> zio_data_buf_20480: 120,742M
VS> VS> zio_data_buf_24576: 148,641M
VS> VS> zio_data_buf_28672: 112,848M
VS> VS> zio_data_buf_32768: 117,375M
VS> VS> zio_data_buf_36864: 185,379M
VS> VS> zio_data_buf_45056: 103,168M
VS> VS> zio_data_buf_53248: 105,32M
VS> VS> zio_data_buf_57344: 122,828M
VS> VS> zio_data_buf_65536: 109,25M
VS> VS> zio_data_buf_69632: 100,406M
VS> VS> zio_data_buf_73728: 126,844M
VS> VS> zio_data_buf_77824: 101,086M
VS> VS> zio_data_buf_81920: 100,391M
VS> VS> zio_data_buf_86016: 101,391M
VS> VS> zio_data_buf_90112: 112,836M
VS> VS> zio_data_buf_98304: 100,688M
VS> VS> zio_data_buf_102400: 106,543M
VS> VS> zio_data_buf_106496: 108,875M
VS> VS> zio_data_buf_131072: 63190,5M
VS> VS> dnode_t: 3437,36M
VS> VS> dmu_buf_impl_t: 840,62M
VS> VS> arc_buf_hdr_t: 1870,88M
VS> VS> arc_buf_t: 114,942M
VS> VS> zfs_znode_cache: 353,055M
VS> VS>
VS> VS> Everything seems within ARC total range.
VS> VS>
VS> VS> We will try patch attached within few days and will come back with the result.
VS> VS>
VS> VS> Thank you for your help.
VS> VS>
VS> VS> > on 28/01/2014 11:28 Vladimir Sharun said the following:
VS> VS> > > Dear Andriy and FreeBSD community,
VS> VS> > >
VS> VS> > > After applying this path one of the systems runs fine (disk subsystem load low to moderate
VS> VS> > > - 10-20% busy sustained),
VS> VS> > >
VS> VS> > > Then I saw this patch was merged to the HEAD and we apply it to the one of the systems
VS> VS> > > with moderate to high disk load: 30-60% busy (11.0-CURRENT #7 r261118: Fri Jan 24 17:25:08 EET 2014)
VS> VS> > >
VS> VS> > > Within 4 days we experiencing the same leak(?) as without patch:
VS> VS> > >
VS> VS> > > last pid: 53841; load averages: 4.47, 4.18, 3.78 up 3+16:37:09 11:24:39
VS> VS> > > 543 processes: 6 running, 537 sleeping
VS> VS> > > CPU: 8.7% user, 0.0% nice, 14.6% system, 1.4% interrupt, 75.3% idle
VS> VS> > > Mem: 22G Active, 1045M Inact, 98G Wired, 1288M Cache, 3284M Buf, 2246M Free
VS> VS> > > ARC: 73G Total, 3763M MFU, 62G MRU, 56M Anon, 1887M Header, 4969M Other
VS> VS> > > Swap:
VS> VS> > >
VS> VS> > > The ARC is populated within 30mins under load to the max (90Gb) then start decreasing.
VS> VS> > >
VS> VS> > > The delta between Wiread and ARC total start growing from typical 10-12Gb without L2 enabled
VS> VS> > > to the 25Gb with L2 enabled and counting (4 hours ago was 22Gb delta).
VS> VS> >
VS> VS> > First, have you checked that vmstat -z output contains the same anomaly as for
VS> VS> > in your original report?
VS> VS> >
VS> VS> > If yes, the please try to reproduce the problem with the following debugging patch:
VS> VS> > http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.patch
VS> VS> > Please make sure to compile your kernel (and modules) with INVARIANTS.
VS> VS> >
VS> VS> > --
VS> VS> > Andriy Gapon
VS> VS> > _______________________________________________
VS> VS> > freebsd-current@freebsd.org mailing list
VS> VS> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> VS> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
VS> VS> _______________________________________________
VS> VS> freebsd-current@freebsd.org mailing list
VS> VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> VS> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
VS> _______________________________________________
VS> freebsd-current@freebsd.org mailing list
VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 11:28:38 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id D6FD34E4;
Tue, 4 Feb 2014 11:28:38 +0000 (UTC)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de
[130.133.4.66])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 909D31149;
Tue, 4 Feb 2014 11:28:38 +0000 (UTC)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69])
by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp
(envelope-from <ohartman@zedat.fu-berlin.de>)
id <1WAeB3-003t5I-Vx>; Tue, 04 Feb 2014 12:28:30 +0100
Received: from e179135167.adsl.alicedsl.de ([85.179.135.167]
helo=thor.walstatt.dyndns.org)
by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa
(envelope-from <ohartman@zedat.fu-berlin.de>)
id <1WAeB3-003oyo-RE>; Tue, 04 Feb 2014 12:28:29 +0100
Date: Tue, 4 Feb 2014 12:28:25 +0100
From: "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To: FreeBSD CURRENT <freebsd-current@freebsd.org>, FreeBSD Ports
<freebsd-ports@freebsd.org>
Subject: x11/nvidia-driver: make -B clean all ===> Cleaning for
nvidia-driver-331.38 *** [all] Stopped -- signal 22
Message-ID: <20140204122825.7a55de43@thor.walstatt.dyndns.org>
Organization: FU Berlin
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
boundary="Sig_/YRVJopfmpmu8Fg5.9K3Ew//"; protocol="application/pgp-signature"
X-Originating-IP: 85.179.135.167
X-ZEDAT-Hint: A
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 11:28:38 -0000
--Sig_/YRVJopfmpmu8Fg5.9K3Ew//
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Since the last Update of the ports tree buidling the nvidia GPU driver
from port x11/nvidia-driver doesn't work properly anymore, when the
build is done via
/etc/src.conf:
PORTS_MODULES=3D
PORTS_MODULES+=3D x11/nvidia-driver
PORTS_MODULES+=3D emulators/virtualbox-ose-kmod
this happens with the version nvidia-driver-331.38 as well as with
nvidia-driver-331.20. See error below. It allways ends with=20
WRKDIRPREFIX=3D/usr/obj/usr/src/sys/THOR make -B clean all =3D=3D=3D> Clea=
ning
for nvidia-driver-331.38 *** [all] Stopped -- signal 22
The SIGNAL 22 ( SIGTTOU) sounds strange to me.
Building the port x11/nvidia-driver via portmaster works well, but I
receive two times the option box and once options selected, I'm getting
asked all the time again, twice. this strange behaviour occured on all
11.0-CURRENT machines I have the same time (with nVidia cards).
Performing=20
make rmconfig
in ports main directory at x11/nvidia-driver doesn't resolve the
problem.
Regards,
Oliver
=3D=3D=3D> Ports module x11/nvidia-driver (all)
cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver;
PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr=
/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:=
/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src=
/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SRC_BASE=3D/usr/src OSVERSION=3D1100007
WRKDIRPREFIX=3D/usr/obj/usr/src/sys/THOR make -B clean all =3D=3D=3D> Clea=
ning
for nvidia-driver-331.38 *** [all] Stopped -- signal 22
--Sig_/YRVJopfmpmu8Fg5.9K3Ew//
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJS8M7dAAoJEOgBcD7A/5N8TvwIAKfXRnHZmM7L8TLEmB6r85ln
tSwFkOyP0AWkO8nqETh2j3s0bpPwqviSGvbpqmCENPKYRw91aAcFqEIVEjJmPDuW
dZ+/ySSJaYmvJSZYEIopu+wEO2awLLgn2sdyXyAZDRsrQGJ2xrZ1MA+7YKfHFRZc
Xu7kKRX0k1wPZ24wFp+yWMxIgizMHkw9PMXXl1gaznVLBNqcLCdA7NQUZfUcwxQn
SFBsVjIeB8tBr6TaYdgjB0YbYv2n6aiom04EqsiSmqgR5V+3A2Oqrz3vr4pwJL9H
rxeT0bcPbytPePWnhWxUVny6io51thWy21xtn+yCuztKUDk9d918xrBfscrkQsg=
=hr0j
-----END PGP SIGNATURE-----
--Sig_/YRVJopfmpmu8Fg5.9K3Ew//--
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 09:09:02 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 3C6746F3
for <current@freebsd.org>; Tue, 4 Feb 2014 09:09:02 +0000 (UTC)
Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id E798B144B
for <current@freebsd.org>; Tue, 4 Feb 2014 09:09:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net;
s=ffe;
h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date;
bh=OYjjOoOLeqZt78Xo1Nvw+JH4etW2+nI5qjhg/5IZa5w=;
b=YHkkw28hxv0u3TxmTNyy5/bLDknGoeaY9C5bklNY13d6OHokc2jY5L7T0vLR8f/5EOa9F/yEF7Go8IjziR+dzyXtu4Vk8FJNc+LGs/6Y+ilWw2uEKdfaTrk4dbj1aNyEoGUNX6askVPXUWOEwoNoY5lPJE+MyTjp56rRXfWG0sA=;
Received: from [10.10.10.45] (helo=frv45.fwdcdn.com)
by frv196.fwdcdn.com with smtp ID 1WAbzs-0002m8-Jq
for current@freebsd.org; Tue, 04 Feb 2014 11:08:48 +0200
Date: Tue, 04 Feb 2014 11:08:48 +0200
From: Vladimir Sharun <sharun@ukr.net>
Subject: Re: sshd sandbox failure
To: Ian FREISLICH <ianf@clue.co.za>
X-Mailer: mail.ukr.net 5.0
Message-Id: <1391504775.87254301.zmbcoto6@frv45.fwdcdn.com>
In-Reply-To: <E1WAbIj-000GeW-ME@clue.co.za>
References: <E1WAbIj-000GeW-ME@clue.co.za>
MIME-Version: 1.0
Received: from atz@ukr.net by frv45.fwdcdn.com; Tue, 04 Feb 2014 11:08:48 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: binary
Content-Disposition: inline
X-Mailman-Approved-At: Tue, 04 Feb 2014 12:30:31 +0000
Cc: current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 09:09:02 -0000
Dear Ian,
Seems it must be in UPDATING or even in the buildworld: without capsicum framework support no ssh access to the server anymore.
I step in the same problem this weekend, thank to the IPMI on the home testebed I figured out what's the cause.
> Hi
>
> Since the openssh update in recent -CURRENT, I get these in my
> auth.log until I disable sandbox UsePrivilegeSeparation in sshd_config.
>
> Feb 3 10:02:14 firewall1 sshd[90062]: fatal: ssh_sandbox_child: failed to limit the network socket [preauth]
>
> Is there something that I missed during the update?
>
> Ian
>
> --
> Ian Freislich
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 14:01:45 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 3576BD28;
Tue, 4 Feb 2014 14:01:45 +0000 (UTC)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
by mx1.freebsd.org (Postfix) with ESMTP id 19B5F10C2;
Tue, 4 Feb 2014 14:01:43 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
[212.40.38.100])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA03750;
Tue, 04 Feb 2014 15:55:10 +0200 (EET) (envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
id 1WAgSz-0004jt-Tj; Tue, 04 Feb 2014 15:55:09 +0200
Message-ID: <52F0F0EC.5090902@FreeBSD.org>
Date: Tue, 04 Feb 2014 15:53:48 +0200
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: freebsd-fs <fs@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org>,
freebsd-doc@FreeBSD.org
Subject: zfs boot manual pages
References: <201301251633.r0PGX15j040754@svn.freebsd.org>
<5102B7A5.7030105@FreeBSD.org>
<alpine.BSF.2.00.1307022125160.58832@wonkity.com>
<51F0F0FE.6030208@FreeBSD.org>
<alpine.BSF.2.00.1307281800200.12706@wonkity.com>
<51F60897.1020005@FreeBSD.org>
<alpine.BSF.2.00.1307291401500.46556@wonkity.com>
<52E22240.5050501@FreeBSD.org>
<alpine.BSF.2.00.1401241845360.92265@wonkity.com>
<alpine.BSF.2.00.1401241856260.93615@wonkity.com>
<alpine.BSF.2.00.1401241901580.93615@wonkity.com>
In-Reply-To: <alpine.BSF.2.00.1401241901580.93615@wonkity.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 14:01:45 -0000
I've started working on manual pages for the zfs boot chain.
Please [p]review my work in progress here:
https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages
Any additions, corrections, suggestions and other kinds of reviewing are
welcome. Patches and pull requests are very welcome!
Many thanks to Warren Block for the initial review and many fixes.
--
Andriy Gapon
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 14:19:06 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id C8A4263A
for <freebsd-current@FreeBSD.org>; Tue, 4 Feb 2014 14:19:06 +0000 (UTC)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
by mx1.freebsd.org (Postfix) with ESMTP id 1BF6C1224
for <freebsd-current@FreeBSD.org>; Tue, 4 Feb 2014 14:19:05 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
[212.40.38.100])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA04487;
Tue, 04 Feb 2014 16:19:04 +0200 (EET) (envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
id 1WAgq7-0004lw-Nb; Tue, 04 Feb 2014 16:19:03 +0200
Message-ID: <52F0F687.6050307@FreeBSD.org>
Date: Tue, 04 Feb 2014 16:17:43 +0200
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Vitalij Satanivskij <satan@ukr.net>
Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted
to text/plain)
References: <1389005433.815055146.2dcjke36@frv45.ukr.net>
<52CA9963.1050507@FreeBSD.org> <1389676958.516993176.oq4lbgg7@frv45.ukr.net>
<52D59E36.9040405@FreeBSD.org> <20140115102837.GA98983@hell.ukr.net>
<52D66DB6.7030807@FreeBSD.org> <1390900795.258244476.v35k1338@frv45.ukr.net>
<52EA3459.3070300@FreeBSD.org> <1391083826.948700370.cmzf8475@frv45.ukr.net>
<20140131182637.GA82526@hell.ukr.net> <20140204100823.GA95709@hell.ukr.net>
In-Reply-To: <20140204100823.GA95709@hell.ukr.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Vladimir Sharun <atz@ukr.net>,
Current FreeBSD <freebsd-current@FreeBSD.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 14:19:06 -0000
on 04/02/2014 12:08 Vitalij Satanivskij said the following:
>
> Dear Andriy and FreeBSD community,
>
> With patch system panic on boot.
>
> After remove cache device from pool system boot without problem.
>
> After this cache added again and sone kernel panic happened
>
> Screen shot of panic here http://i61.tinypic.com/30sbx2g.jpg
I think that my previous patch was wrong.
I've updated it in place:
http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.patch
--
Andriy Gapon
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 17:10:46 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 08A2CA65;
Tue, 4 Feb 2014 17:10:46 +0000 (UTC)
Received: from hell.ukr.net (hell.ukr.net [212.42.67.68])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id B71E71377;
Tue, 4 Feb 2014 17:10:45 +0000 (UTC)
Received: from satan by hell.ukr.net with local ID 1WAjWC-000Lb5-Cc
; Tue, 04 Feb 2014 19:10:40 +0200
Date: Tue, 4 Feb 2014 19:10:40 +0200
From: Vitalij Satanivskij <satan@ukr.net>
To: Andriy Gapon <avg@FreeBSD.org>
Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to
text/plain)
Message-ID: <20140204171040.GA82996@hell.ukr.net>
References: <1389676958.516993176.oq4lbgg7@frv45.ukr.net>
<52D59E36.9040405@FreeBSD.org>
<20140115102837.GA98983@hell.ukr.net>
<52D66DB6.7030807@FreeBSD.org>
<1390900795.258244476.v35k1338@frv45.ukr.net>
<52EA3459.3070300@FreeBSD.org>
<1391083826.948700370.cmzf8475@frv45.ukr.net>
<20140131182637.GA82526@hell.ukr.net>
<20140204100823.GA95709@hell.ukr.net>
<52F0F687.6050307@FreeBSD.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52F0F687.6050307@FreeBSD.org>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: Vitalij Satanivskij <satan@ukr.net>,
Current FreeBSD <freebsd-current@FreeBSD.org>, Vladimir Sharun <atz@ukr.net>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 17:10:46 -0000
Dear Andriy and FreeBSD community,
I'm aply patch and ofter few minutes of work get new panic
screen shot on picture.
http://i59.tinypic.com/sfctvc.jpg
Andriy Gapon wrote:
AG> on 04/02/2014 12:08 Vitalij Satanivskij said the following:
AG> >
AG> > Dear Andriy and FreeBSD community,
AG> >
AG> > With patch system panic on boot.
AG> >
AG> > After remove cache device from pool system boot without problem.
AG> >
AG> > After this cache added again and sone kernel panic happened
AG> >
AG> > Screen shot of panic here http://i61.tinypic.com/30sbx2g.jpg
AG>
AG> I think that my previous patch was wrong.
AG> I've updated it in place:
AG> http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.patch
AG>
AG>
AG> --
AG> Andriy Gapon
AG> _______________________________________________
AG> freebsd-current@freebsd.org mailing list
AG> http://lists.freebsd.org/mailman/listinfo/freebsd-current
AG> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 17:23:49 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id B699DD9
for <freebsd-current@FreeBSD.org>; Tue, 4 Feb 2014 17:23:49 +0000 (UTC)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
by mx1.freebsd.org (Postfix) with ESMTP id 0802C14E3
for <freebsd-current@FreeBSD.org>; Tue, 4 Feb 2014 17:23:48 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
[212.40.38.100])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07430;
Tue, 04 Feb 2014 19:23:46 +0200 (EET) (envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
id 1WAjir-0004wz-Ud; Tue, 04 Feb 2014 19:23:45 +0200
Message-ID: <52F12210.10604@FreeBSD.org>
Date: Tue, 04 Feb 2014 19:23:28 +0200
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Vitalij Satanivskij <satan@ukr.net>
Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted
to text/plain)
References: <1389676958.516993176.oq4lbgg7@frv45.ukr.net>
<52D59E36.9040405@FreeBSD.org> <20140115102837.GA98983@hell.ukr.net>
<52D66DB6.7030807@FreeBSD.org> <1390900795.258244476.v35k1338@frv45.ukr.net>
<52EA3459.3070300@FreeBSD.org> <1391083826.948700370.cmzf8475@frv45.ukr.net>
<20140131182637.GA82526@hell.ukr.net> <20140204100823.GA95709@hell.ukr.net>
<52F0F687.6050307@FreeBSD.org> <20140204171040.GA82996@hell.ukr.net>
In-Reply-To: <20140204171040.GA82996@hell.ukr.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Vladimir Sharun <atz@ukr.net>,
Current FreeBSD <freebsd-current@FreeBSD.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 17:23:49 -0000
on 04/02/2014 19:10 Vitalij Satanivskij said the following:
> Dear Andriy and FreeBSD community,
>
> I'm aply patch and ofter few minutes of work get new panic
>
> screen shot on picture.
>
> http://i59.tinypic.com/sfctvc.jpg
Does this happen too early to get a crashdump?
Do you have a chance to attach with remote kgdb?
> Andriy Gapon wrote:
> AG> on 04/02/2014 12:08 Vitalij Satanivskij said the following:
> AG> >
> AG> > Dear Andriy and FreeBSD community,
> AG> >
> AG> > With patch system panic on boot.
> AG> >
> AG> > After remove cache device from pool system boot without problem.
> AG> >
> AG> > After this cache added again and sone kernel panic happened
> AG> >
> AG> > Screen shot of panic here http://i61.tinypic.com/30sbx2g.jpg
> AG>
> AG> I think that my previous patch was wrong.
> AG> I've updated it in place:
> AG> http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.patch
--
Andriy Gapon
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 19:13:04 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 9C259A55;
Tue, 4 Feb 2014 19:13:04 +0000 (UTC)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com
[IPv6:2607:f8b0:4001:c05::233])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 4872F1FC2;
Tue, 4 Feb 2014 19:13:04 +0000 (UTC)
Received: by mail-ig0-f179.google.com with SMTP id c10so9205301igq.0
for <multiple recipients>; Tue, 04 Feb 2014 11:13:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=jxA2bY1Kpi3xjHQUGA8tb8mHeSTMQmaQA83DVpTHars=;
b=XWIEIxQFhANDb5bxw7HhBfyr8hI6/xMpcUo/FFN7A1WJqpD6ZErBiEkN6Ir9cL1vm/
+gWWdn5PwKtWKjpemlcnMcOY9QMXsaKwOmayUSJVxoZI8oq8TBR0rk1p67CRPgoSu2UJ
HylrIsNbXxeQpt2Km6Q2COLj0wKtH3qehQiV1JRAq7If4o8yh+cNCxNSsfa2SKDL6XTY
0hBbvzE+uO3IkTSeeRm23yT6yRm2l2UM/jyoTwi4cpZ9H4zqwbD7eI7m88rFgxtVLNOD
AnyfHKenfl/4sKKukfe730aeSyQval0mrfAUzC+n1qDfEi8Ak+HtFzvUYIb9H2QFz9M0
KGsQ==
MIME-Version: 1.0
X-Received: by 10.42.52.209 with SMTP id k17mr31302452icg.1.1391541183684;
Tue, 04 Feb 2014 11:13:03 -0800 (PST)
Received: by 10.50.67.84 with HTTP; Tue, 4 Feb 2014 11:13:03 -0800 (PST)
In-Reply-To: <52F0F0EC.5090902@FreeBSD.org>
References: <201301251633.r0PGX15j040754@svn.freebsd.org>
<5102B7A5.7030105@FreeBSD.org>
<alpine.BSF.2.00.1307022125160.58832@wonkity.com>
<51F0F0FE.6030208@FreeBSD.org>
<alpine.BSF.2.00.1307281800200.12706@wonkity.com>
<51F60897.1020005@FreeBSD.org>
<alpine.BSF.2.00.1307291401500.46556@wonkity.com>
<52E22240.5050501@FreeBSD.org>
<alpine.BSF.2.00.1401241845360.92265@wonkity.com>
<alpine.BSF.2.00.1401241856260.93615@wonkity.com>
<alpine.BSF.2.00.1401241901580.93615@wonkity.com>
<52F0F0EC.5090902@FreeBSD.org>
Date: Tue, 4 Feb 2014 13:13:03 -0600
Message-ID: <CACdU+f-mjkLTJj2TChspvs+TSGgbYo48+7c4n+OYy6ERzj-46g@mail.gmail.com>
Subject: Re: zfs boot manual pages
From: Scot Hetzel <swhetzel@gmail.com>
To: Andriy Gapon <avg@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: freebsd-doc@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>,
freebsd-fs <fs@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 19:13:04 -0000
On Tue, Feb 4, 2014 at 7:53 AM, Andriy Gapon <avg@freebsd.org> wrote:
>
> I've started working on manual pages for the zfs boot chain.
>
> Please [p]review my work in progress here:
> https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages
>
> Any additions, corrections, suggestions and other kinds of reviewing are
> welcome. Patches and pull requests are very welcome!
>
> Many thanks to Warren Block for the initial review and many fixes.
One fix for the gptzfsboot man page would be to mention that
gptzfsboot is installed into a GPT partition of type freebsd-boot, and
that the -i 1 refers to the GPT index for this partition.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 20:13:56 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id BC7367AD;
Tue, 4 Feb 2014 20:13:56 +0000 (UTC)
Received: from wonkity.com (wonkity.com [67.158.26.137])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 66C1A1601;
Tue, 4 Feb 2014 20:13:56 +0000 (UTC)
Received: from wonkity.com (localhost [127.0.0.1])
by wonkity.com (8.14.7/8.14.7) with ESMTP id s14KDsoL039959;
Tue, 4 Feb 2014 13:13:54 -0700 (MST)
(envelope-from wblock@wonkity.com)
Received: from localhost (wblock@localhost)
by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s14KDseU039956;
Tue, 4 Feb 2014 13:13:54 -0700 (MST)
(envelope-from wblock@wonkity.com)
Date: Tue, 4 Feb 2014 13:13:54 -0700 (MST)
From: Warren Block <wblock@wonkity.com>
To: Scot Hetzel <swhetzel@gmail.com>
Subject: Re: zfs boot manual pages
In-Reply-To: <CACdU+f-mjkLTJj2TChspvs+TSGgbYo48+7c4n+OYy6ERzj-46g@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1402041301220.38916@wonkity.com>
References: <201301251633.r0PGX15j040754@svn.freebsd.org>
<5102B7A5.7030105@FreeBSD.org>
<alpine.BSF.2.00.1307022125160.58832@wonkity.com>
<51F0F0FE.6030208@FreeBSD.org>
<alpine.BSF.2.00.1307281800200.12706@wonkity.com>
<51F60897.1020005@FreeBSD.org>
<alpine.BSF.2.00.1307291401500.46556@wonkity.com>
<52E22240.5050501@FreeBSD.org>
<alpine.BSF.2.00.1401241845360.92265@wonkity.com>
<alpine.BSF.2.00.1401241856260.93615@wonkity.com>
<alpine.BSF.2.00.1401241901580.93615@wonkity.com>
<52F0F0EC.5090902@FreeBSD.org>
<CACdU+f-mjkLTJj2TChspvs+TSGgbYo48+7c4n+OYy6ERzj-46g@mail.gmail.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
(wonkity.com [127.0.0.1]); Tue, 04 Feb 2014 13:13:54 -0700 (MST)
Cc: freebsd-doc@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>,
freebsd-fs <fs@freebsd.org>, Andriy Gapon <avg@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 20:13:56 -0000
On Tue, 4 Feb 2014, Scot Hetzel wrote:
> On Tue, Feb 4, 2014 at 7:53 AM, Andriy Gapon <avg@freebsd.org> wrote:
>>
>> I've started working on manual pages for the zfs boot chain.
>>
>> Please [p]review my work in progress here:
>> https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages
>>
>> Any additions, corrections, suggestions and other kinds of reviewing are
>> welcome. Patches and pull requests are very welcome!
>>
>> Many thanks to Warren Block for the initial review and many fixes.
>
> One fix for the gptzfsboot man page would be to mention that
> gptzfsboot is installed into a GPT partition of type freebsd-boot, and
> that the -i 1 refers to the GPT index for this partition.
We are missing that from the gptboot.8 page also.
gptzfsboot is installed in a freebsd-boot partition, usually the
first partition on the disk. A ``protective MBR'' (see gpart(8)) is
typically used in combination with gptzfsboot.
To install gptzfsboot on the ada0 drive:
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 02:08:14 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id A944CEAD;
Wed, 5 Feb 2014 02:08:14 +0000 (UTC)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu
[128.95.76.21])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 85F5F1A70;
Wed, 5 Feb 2014 02:08:14 +0000 (UTC)
Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu
[127.0.0.1])
by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id s152846x054127
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Tue, 4 Feb 2014 18:08:04 -0800 (PST)
(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id s15284XP054126;
Tue, 4 Feb 2014 18:08:04 -0800 (PST) (envelope-from sgk)
Date: Tue, 4 Feb 2014 18:08:04 -0800
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Alexander Motin <mav@FreeBSD.org>
Subject: Re: Instant panic CAM or USB subsystem
Message-ID: <20140205020804.GA54095@troutmask.apl.washington.edu>
References: <20140125172106.GA67590@troutmask.apl.washington.edu>
<201401281232.21958.jhb@freebsd.org>
<20140128195842.GA83173@troutmask.apl.washington.edu>
<52F09914.5040202@FreeBSD.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52F09914.5040202@FreeBSD.org>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: freebsd-current@freebsd.org, scsi@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 02:08:14 -0000
On Tue, Feb 04, 2014 at 09:39:00AM +0200, Alexander Motin wrote:
>
> I guess problem may be not that phone is reported as CD, but that it is
> reported as several CDs on one target. Note that you already see cd1
> reported, but another one was still trying to allocate when system panicked.
Good guess see below.
> I think that CAM CD driver incorrectly assumes that your device is CD
> changer. I've pulled real 5-disk SCSI CD changer from my depths of my
> table and got panic very much like yours just on boot. It seems that
> respective changer code was not properly re-locked during recent CAM
> locking project.
If you come up with a patch, I can test it for you.
> I am going to analyze this case deeper to fix in properly, while for
> your case I can propose such quick quirk:
>
> --- scsi_cd.c (revision 261448)
> +++ scsi_cd.c (working copy)
> @@ -223,6 +223,10 @@ static struct cd_quirk_entry cd_quirk_table[] =
> {
> { T_CDROM, SIP_MEDIA_REMOVABLE, "CHINON", "CD-ROM
> CDS-535","*"},
> /* quirks */ CD_Q_BCD_TRACKS
> + },
> + {
> + { T_CDROM, SIP_MEDIA_REMOVABLE, "SAMSUNG", "CD-ROM","1.00"},
> + /* quirks */ CD_Q_NO_CHANGER
> }
> };
>
With your quirk, the laptop booted and plugging in the cellphone
does not cause a panic. :-)
dmesg shows
ugen3.2: <Qualcomm, Incorporated> at usbus3
umass1: <Qualcomm, Incorporated USB MMC Storage, class 0/0, rev 1.10/0.00,\
addr 2> on usbus3
cd1 at umass-sim1 bus 1 scbus5 target 0 lun 0
cd1: <SAMSUNG CD-ROM 1.00> Removable CD-ROM SCSI-2 device
cd1: Serial Number 000000000002
cd1: 1.000MB/s transfers
cd1: cd present [3840000 x 512 byte records]
cd1: quirks=0x14<NO_CHANGER,10_BYTE_ONLY>
cd2 at umass-sim1 bus 1 scbus5 target 0 lun 1
cd2: <SAMSUNG CD-ROM 1.00> Removable CD-ROM SCSI-2 device
cd2: Serial Number 000000000002
cd2: 1.000MB/s transfers
cd2: cd present [1084 x 512 byte records]
cd2: quirks=0x14<NO_CHANGER,10_BYTE_ONLY>
After a few seconds, the cellphone display shows
> Sync Music to Phone
> Sync Music to Card
> Copy/Move Files
and the following appears in dmesg
ugen3.2: <Qualcomm, Incorporated> at usbus3 (disconnected)
umass1: at uhub3, port 2, addr 2 (disconnected)
cd1 at umass-sim1 bus 1 scbus5 target 0 lun 0
cd1: <SAMSUNG CD-ROM 1.00> s/n 000000000002 detached
cd2 at umass-sim1 bus 1 scbus5 target 0 lun 1
cd2: <SAMSUNG CD-ROM 1.00> s/n 000000000002 detached
(cd2:umass-sim1:1:0:1): Periph destroyed
(cd1:umass-sim1:1:0:0): Periph destroyed
ugen3.2: <SAMSUNG Electronics Bo.,Ltd.> at usbus3
This is fine with me as I only use the laptop as a charging station.
--
Steve
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 06:58:38 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 511B7D93;
Wed, 5 Feb 2014 06:58:38 +0000 (UTC)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com
[IPv6:2607:f8b0:4001:c05::230])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id EBEAB1623;
Wed, 5 Feb 2014 06:58:37 +0000 (UTC)
Received: by mail-ig0-f176.google.com with SMTP id j1so11126109iga.3
for <multiple recipients>; Tue, 04 Feb 2014 22:58:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=vyvrRww4nGQGaYg/GLCHLbNBwxc+66kWq9YkVAH/P68=;
b=QyrENvtp/TVsPhh2hq8n2AOBdzI0fue9ZBdtdFsDCV6AAlQu1i6sqwQ5pGZ3jBS1p6
rkWqR/OJVWbXt0+/zz1Yi/2FhkM+3JqNLSojD1slYkF2dF82h9/EaD4mpquKLyrMfvoN
gdni1fWHBm0Yh1mSEZj4fCMqjSDmXjyb9+A6LdpcfeOSn5yu6M+kVjbe5scXA6JcEgNz
ILbG7jgiauQCO8o3PrQX6st7o1kQj7RO8H2QCLCX7YgQO8TS+WjYlf77MxM/kEqS5MmV
WqvDNlNDnu91RKbXWzaE5h09Jazm+IaA51jvW4k9Ke6saeTqHZNt6a/J6s9JRQwYtBIB
6jDQ==
MIME-Version: 1.0
X-Received: by 10.43.153.138 with SMTP id la10mr34833806icc.10.1391583517372;
Tue, 04 Feb 2014 22:58:37 -0800 (PST)
Received: by 10.50.67.84 with HTTP; Tue, 4 Feb 2014 22:58:37 -0800 (PST)
In-Reply-To: <alpine.BSF.2.00.1402041301220.38916@wonkity.com>
References: <201301251633.r0PGX15j040754@svn.freebsd.org>
<5102B7A5.7030105@FreeBSD.org>
<alpine.BSF.2.00.1307022125160.58832@wonkity.com>
<51F0F0FE.6030208@FreeBSD.org>
<alpine.BSF.2.00.1307281800200.12706@wonkity.com>
<51F60897.1020005@FreeBSD.org>
<alpine.BSF.2.00.1307291401500.46556@wonkity.com>
<52E22240.5050501@FreeBSD.org>
<alpine.BSF.2.00.1401241845360.92265@wonkity.com>
<alpine.BSF.2.00.1401241856260.93615@wonkity.com>
<alpine.BSF.2.00.1401241901580.93615@wonkity.com>
<52F0F0EC.5090902@FreeBSD.org>
<CACdU+f-mjkLTJj2TChspvs+TSGgbYo48+7c4n+OYy6ERzj-46g@mail.gmail.com>
<alpine.BSF.2.00.1402041301220.38916@wonkity.com>
Date: Wed, 5 Feb 2014 00:58:37 -0600
Message-ID: <CACdU+f_PYfOfZssYueKpU=benrdvXCk37HftMR-1Ty2wEHoZ2w@mail.gmail.com>
Subject: Re: zfs boot manual pages
From: Scot Hetzel <swhetzel@gmail.com>
To: Warren Block <wblock@wonkity.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: freebsd-doc@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>,
freebsd-fs <fs@freebsd.org>, Andriy Gapon <avg@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 06:58:38 -0000
On Tue, Feb 4, 2014 at 2:13 PM, Warren Block <wblock@wonkity.com> wrote:
> On Tue, 4 Feb 2014, Scot Hetzel wrote:
>
>> On Tue, Feb 4, 2014 at 7:53 AM, Andriy Gapon <avg@freebsd.org> wrote:
>>>
>>>
>>> I've started working on manual pages for the zfs boot chain.
>>>
>>> Please [p]review my work in progress here:
>>> https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages
>>>
>>> Any additions, corrections, suggestions and other kinds of reviewing are
>>> welcome. Patches and pull requests are very welcome!
>>>
>>> Many thanks to Warren Block for the initial review and many fixes.
>>
>>
>> One fix for the gptzfsboot man page would be to mention that
>> gptzfsboot is installed into a GPT partition of type freebsd-boot, and
>> that the -i 1 refers to the GPT index for this partition.
>
>
> We are missing that from the gptboot.8 page also.
>
> gptzfsboot is installed in a freebsd-boot partition, usually the
> first partition on the disk. A ``protective MBR'' (see gpart(8)) is
> typically used in combination with gptzfsboot.
>
> To install gptzfsboot on the ada0 drive:
>
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
That sounds perfect for both man pages.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 07:52:07 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 49508ED;
Wed, 5 Feb 2014 07:52:07 +0000 (UTC)
Received: from tensor.andric.com (tensor.andric.com [87.251.56.140])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id F18161A10;
Wed, 5 Feb 2014 07:52:06 +0000 (UTC)
Received: from [IPv6:2001:7b8:3a7::b47f:4e8f:d41c:5726] (unknown
[IPv6:2001:7b8:3a7:0:b47f:4e8f:d41c:5726])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by tensor.andric.com (Postfix) with ESMTPSA id E30D95C44;
Wed, 5 Feb 2014 08:51:57 +0100 (CET)
Subject: Re: sshd sandbox failure
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_722A8017-1271-4AF7-97C1-44FB5B3AC044";
protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.1 (6062eb4)
From: Dimitry Andric <dim@FreeBSD.org>
In-Reply-To: <1391504775.87254301.zmbcoto6@frv45.fwdcdn.com>
Date: Wed, 5 Feb 2014 08:51:51 +0100
Message-Id: <843FE764-A432-497D-AAC7-D06FB71AF57D@FreeBSD.org>
References: <E1WAbIj-000GeW-ME@clue.co.za>
<1391504775.87254301.zmbcoto6@frv45.fwdcdn.com>
To: Vladimir Sharun <sharun@ukr.net>
X-Mailer: Apple Mail (2.1827)
Cc: Ian FREISLICH <ianf@clue.co.za>, current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 07:52:07 -0000
--Apple-Mail=_722A8017-1271-4AF7-97C1-44FB5B3AC044
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 04 Feb 2014, at 10:08, Vladimir Sharun <sharun@ukr.net> wrote:
> Seems it must be in UPDATING or even in the buildworld: without =
capsicum framework support no ssh access to the server anymore.
>=20
> I step in the same problem this weekend, thank to the IPMI on the home =
testebed I figured out what's the cause.
>>=20
>> Since the openssh update in recent -CURRENT, I get these in my
>> auth.log until I disable sandbox UsePrivilegeSeparation in =
sshd_config.
>>=20
>> Feb 3 10:02:14 firewall1 sshd[90062]: fatal: ssh_sandbox_child: =
failed to limit the network socket [preauth]
>>=20
>> Is there something that I missed during the update?
This was an oversight fixed by Pawel in r261499. Pawel, maybe you can
add a special note to UPDATING for it?
-Dimitry
--Apple-Mail=_722A8017-1271-4AF7-97C1-44FB5B3AC044
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlLx7ZsACgkQsF6jCi4glqNOPACePpTuFY9O1GaQtRuIxTN1bnNG
Ix4AnjPWAmnoaCTL0VywMnR/EL++2xrE
=QA82
-----END PGP SIGNATURE-----
--Apple-Mail=_722A8017-1271-4AF7-97C1-44FB5B3AC044--
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 09:04:53 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 627E8D74;
Wed, 5 Feb 2014 09:04:53 +0000 (UTC)
Received: from hell.ukr.net (hell.ukr.net [212.42.67.68])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 1C585114F;
Wed, 5 Feb 2014 09:04:52 +0000 (UTC)
Received: from satan by hell.ukr.net with local ID 1WAyPZ-0007A6-7G
; Wed, 05 Feb 2014 11:04:49 +0200
Date: Wed, 5 Feb 2014 11:04:49 +0200
From: Vitalij Satanivskij <satan@ukr.net>
To: Andriy Gapon <avg@FreeBSD.org>
Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to
text/plain)
Message-ID: <20140205090449.GA9341@hell.ukr.net>
References: <20140115102837.GA98983@hell.ukr.net>
<52D66DB6.7030807@FreeBSD.org>
<1390900795.258244476.v35k1338@frv45.ukr.net>
<52EA3459.3070300@FreeBSD.org>
<1391083826.948700370.cmzf8475@frv45.ukr.net>
<20140131182637.GA82526@hell.ukr.net>
<20140204100823.GA95709@hell.ukr.net>
<52F0F687.6050307@FreeBSD.org>
<20140204171040.GA82996@hell.ukr.net> <52F12210.10604@FreeBSD.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52F12210.10604@FreeBSD.org>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: Vitalij Satanivskij <satan@ukr.net>,
Current FreeBSD <freebsd-current@FreeBSD.org>, Vladimir Sharun <atz@ukr.net>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 09:04:53 -0000
Dear Andriy and FreeBSD community,
Andriy Gapon wrote:
AG> on 04/02/2014 19:10 Vitalij Satanivskij said the following:
AG> > Dear Andriy and FreeBSD community,
AG> >
AG> > I'm aply patch and ofter few minutes of work get new panic
AG> >
AG> > screen shot on picture.
AG> >
AG> > http://i59.tinypic.com/sfctvc.jpg
AG>
AG> Does this happen too early to get a crashdump?
AG> Do you have a chance to attach with remote kgdb?
How I reproduce crash - simply attach cache device (zpool add pool cache /dev/gpt/cache0 ) and
run ls -R -la /pool
I repeat eksperimet and try to get core.
About kgdb - server on which we test path is no very critical so I can connect via remove ipmi (acceptibly from local network)
and run some comands at any time and of course I try to get kernel core dump
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 12:22:51 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 22FDFBB0;
Wed, 5 Feb 2014 12:22:51 +0000 (UTC)
Received: from hell.ukr.net (hell.ukr.net [212.42.67.68])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id D05751245;
Wed, 5 Feb 2014 12:22:50 +0000 (UTC)
Received: from satan by hell.ukr.net with local ID 1WB1V3-0009wi-3X
; Wed, 05 Feb 2014 14:22:41 +0200
Date: Wed, 5 Feb 2014 14:22:41 +0200
From: Vitalij Satanivskij <satan@ukr.net>
To: Vitalij Satanivskij <satan@ukr.net>
Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to
text/plain)
Message-ID: <20140205122241.GA38114@hell.ukr.net>
References: <52D66DB6.7030807@FreeBSD.org>
<1390900795.258244476.v35k1338@frv45.ukr.net>
<52EA3459.3070300@FreeBSD.org>
<1391083826.948700370.cmzf8475@frv45.ukr.net>
<20140131182637.GA82526@hell.ukr.net>
<20140204100823.GA95709@hell.ukr.net>
<52F0F687.6050307@FreeBSD.org>
<20140204171040.GA82996@hell.ukr.net> <52F12210.10604@FreeBSD.org>
<20140205090449.GA9341@hell.ukr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140205090449.GA9341@hell.ukr.net>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: Vladimir Sharun <atz@ukr.net>,
Current FreeBSD <freebsd-current@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 12:22:51 -0000
Dear Andriy and FreeBSD community,
Ok. I'm get coredump on panic.
What else i need to do?
Vitalij Satanivskij wrote:
VS> Dear Andriy and FreeBSD community,
VS>
VS> Andriy Gapon wrote:
VS> AG> on 04/02/2014 19:10 Vitalij Satanivskij said the following:
VS> AG> > Dear Andriy and FreeBSD community,
VS> AG> >
VS> AG> > I'm aply patch and ofter few minutes of work get new panic
VS> AG> >
VS> AG> > screen shot on picture.
VS> AG> >
VS> AG> > http://i59.tinypic.com/sfctvc.jpg
VS> AG>
VS> AG> Does this happen too early to get a crashdump?
VS> AG> Do you have a chance to attach with remote kgdb?
VS>
VS> How I reproduce crash - simply attach cache device (zpool add pool cache /dev/gpt/cache0 ) and
VS> run ls -R -la /pool
VS>
VS> I repeat eksperimet and try to get core.
VS>
VS> About kgdb - server on which we test path is no very critical so I can connect via remove ipmi (acceptibly from local network)
VS> and run some comands at any time and of course I try to get kernel core dump
VS>
VS>
VS>
VS> _______________________________________________
VS> freebsd-current@freebsd.org mailing list
VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 15:45:48 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 34DF6FE6
for <freebsd-current@freebsd.org>; Wed, 5 Feb 2014 15:45:48 +0000 (UTC)
Received: from nm22-vm2.bullet.mail.ne1.yahoo.com
(nm22-vm2.bullet.mail.ne1.yahoo.com [98.138.91.210])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id D0A1B1756
for <freebsd-current@freebsd.org>; Wed, 5 Feb 2014 15:45:47 +0000 (UTC)
Received: from [98.138.100.114] by nm22.bullet.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 15:45:41 -0000
Received: from [98.138.84.39] by tm105.bullet.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 15:45:40 -0000
Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 15:45:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
t=1391615140; bh=eNc0Wbpw0GqjJ2oIdQr3yguX+vhEPPYKw8kbFjw65Pw=;
h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding;
b=4wWRfUuhUXpyuGahqSpVq3Sr3hhovg1Sfz9xh5GBzPWANHcbYZwbnLlezp68J9l/3ht5TvKaVGllhQPPxGIo8vEgRwz8ouZF6NSD/M4OCDH8AddWXaDAu904remzClbIB8/KBxlmxX0/Jx8DoeTHNSJESRTcsHpsh0oySU8yjp4=
X-Yahoo-Newman-Id: 956751.86436.bm@smtp107.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: UAXMqskVM1lY.ClC4u5qLg0a_lEATY.xuFVGXmFA.Gp0F26
J8_0hqv5FyNBuTSIoWTnPfq4vsDcckLpAdprD0akpGQJLkPA1RCPNAAeGPHj
wWv4c25EJZdZiKEkQKp2rIAuXJNQRK873ujA_ye7AE5aiE2fjJEHjbUZ7unl
44zJ5UiI6JZk1cUbNu9NRf5eQ7a89kJjh6Jx.4NA1h_ytlZrtb3yk0cmdfWN
Kl3KfYksqv.7GSFj7HpxFraw.vOylf.ekPICA3GaYLNmSQVape7rlqJfZrUX
PYtuxsyN1V4z7rfr_h7KZInIfPdEFAJe1gmry1vDD4JcoX1HQCgZMMdhAucN
APUisDmFh6Qzjw1hfXWTEnmegVyJ3n9ulQajugVqHp2A3oqxUXB90deQvvOP
UP_M3rxcrqFZG76Roa07zvEXRdorSXKkWJ.m3BdLteYcfhRjPqZ_HKUKIL.M
4A0625HMkG.kydQZadIjcZaYmGjtYPlU8iwCScs7tRxkXZOtSAfNbre.B5fj
K8b1HxWntqHszxJmdqSbWcA2UqjBrbhKHOdgMZ0TNKII_rhXcKDY._ojVD9X
isVEx8zo-
X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4-
X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with plain
[98.139.211.125])
by smtp107.mail.ne1.yahoo.com with SMTP; 05 Feb 2014 07:45:40 -0800 PST
Subject: fonts and characters
From: Sean Bruno <sean_bruno@yahoo.com>
To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 05 Feb 2014 07:42:03 -0800
Message-ID: <1391614923.1481.3.camel@powernoodle.corp.yahoo.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: sbruno@freebsd.org
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 15:45:48 -0000
I note that I have somehow failed to install or configure my system so
that my terminal does not render characters outside of my alphabet at
all.
Typically, I run my IRC sessions in tmux inside a xfce-terminal, but I'm
not sure how to get proper rendering of characters for other alphabets
(cyrillic, kanji, etc). Is this a trivial mistake on my part or is
something slightly more interesting going on?
sean
p.s. firefox renders other alphabets (for the most part) just fine.
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 17:03:08 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id A85D423A
for <freebsd-current@freebsd.org>; Wed, 5 Feb 2014 17:03:08 +0000 (UTC)
Received: from nm3-vm6.bullet.mail.ne1.yahoo.com
(nm3-vm6.bullet.mail.ne1.yahoo.com [98.138.91.96])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 3849E1025
for <freebsd-current@freebsd.org>; Wed, 5 Feb 2014 17:03:07 +0000 (UTC)
Received: from [98.138.101.130] by nm3.bullet.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 17:03:01 -0000
Received: from [98.138.226.59] by tm18.bullet.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 17:03:01 -0000
Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 17:03:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
t=1391619781; bh=If3YfLQeL/CqrMZ1++tiNMpTTRoniYfbPfZRe9nKPqE=;
h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding;
b=sVUdDh/RzzlP9Glp+txZsNAOadtlsOsR1h+Rxl4xbl+ZwXA+sFeA9y3GZMkwQaTQPb6EK0ZG9+jKc5HK7XztPirV6RNWy92dr4+uNf1vnG0i01DQvdzgAR9E8Ok+hv3nKB5zELnmVVR8YJvq50zVcIntz344ZCEV6hBB2S0oTFQ=
X-Yahoo-Newman-Id: 800395.664.bm@smtp210.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: CQHnsXQVM1nAGP4aM7XHL6bgh4CxnA3ypRKoDbWvvlm8Lzx
6IKiNcNSWzOeNDJVQJVdXLFlmjkrRV.T1s8jXsrtYyrsfGQH6MQ0l8zc_2xJ
vnIKRJmMcHWWLyNiB2FkVx1WesgyQnfew_h0zQLmStMp7ALCBRhxEmq5aBIk
VE1kwhmCvLUMM2LanlmQHgxdMzVd9Rr9iJJOZNqJM8qFYvgtGvv9aLC5L1Ji
FEUdXAnV2X.AMHr3Y51mFD8.U64fi86IshQ84_aWJ332CbWP9oAkmVMnHDzR
SCy.5dhdNn6Asx96fqlW2.yyYYvb6bqyUNQKUPSPofxODqiSFY6sLRonZy7T
iaoCwh2Eyw6ZOqI1RtCL_vxVsvT43bix4dIirougm9ixMRN16ZI97n8H_CXE
924WhvNaK2Hf3cx1MbxFT5u1OqqXUW1ZEOA.G12ymcUYfe97YQkvrS6.qQsb
wVZZI54sSC3pnXjGG5bvZFXQKmuYCk50OC..UMawH8buwvHjBemlCW.CTE1D
UXHUOzM7fdnEx6GCSE3Yc.wpQ32uraEQnMcHGcA65wWZtwCQGD_mWPnJ37X7
UKujk164-
X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4-
X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with plain
[98.139.211.125])
by smtp210.mail.ne1.yahoo.com with SMTP; 05 Feb 2014 09:03:01 -0800 PST
Subject: Re: fonts and characters
From: Sean Bruno <sean_bruno@yahoo.com>
To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
In-Reply-To: <1391614923.1481.3.camel@powernoodle.corp.yahoo.com>
References: <1391614923.1481.3.camel@powernoodle.corp.yahoo.com>
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 05 Feb 2014 09:02:59 -0800
Message-ID: <1391619779.1481.9.camel@powernoodle.corp.yahoo.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: sbruno@freebsd.org
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 17:03:08 -0000
On Wed, 2014-02-05 at 07:42 -0800, Sean Bruno wrote:
> I note that I have somehow failed to install or configure my system so
> that my terminal does not render characters outside of my alphabet at
> all.
>
> Typically, I run my IRC sessions in tmux inside a xfce-terminal, but I'm
> not sure how to get proper rendering of characters for other alphabets
> (cyrillic, kanji, etc). Is this a trivial mistake on my part or is
> something slightly more interesting going on?
>
> sean
>
> p.s. firefox renders other alphabets (for the most part) just fine.
Huh ... setting LANG=en_US.UTF-8 totally fixes this. No idea why its
not set but default though.
sean
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 17:06:51 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id B2663631
for <freebsd-current@freebsd.org>; Wed, 5 Feb 2014 17:06:51 +0000 (UTC)
Received: from nm20-vm0.bullet.mail.ne1.yahoo.com
(nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 2BCF910A6
for <freebsd-current@freebsd.org>; Wed, 5 Feb 2014 17:06:50 +0000 (UTC)
Received: from [98.138.100.116] by nm20.bullet.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 17:06:44 -0000
Received: from [98.138.226.132] by tm107.bullet.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 17:06:44 -0000
Received: from [127.0.0.1] by smtp219.mail.ne1.yahoo.com with NNFMP;
05 Feb 2014 17:06:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
t=1391620004; bh=335wCFx7WVXf9Kp3RkuX2/OdjrMFoHzvhP2JMKLJsb4=;
h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding;
b=0jqLmCwQPAUBSjYHgXrE1efEhsqB2r63swLFRvn+0g3LDjGhO2OgefkgbwrCrF6ye2glll4HxYxLWuZtsh24UMLbsVLQ3VtAWr2z+6zzQIdzphYYq01jDBvT5BQx69siK1TaFGcZ0tV5JxFu/cMBvp5G+805t704K2PBsuSPkM8=
X-Yahoo-Newman-Id: 233531.56151.bm@smtp219.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: NJA5kS8VM1lz8RHfI2Z966NIRrfogvtTCs.dJYcHnLWUvq_
_X2NmijsaMbvd5.KSLO5AYtmo2J1vFfN0ce0ygBx_WNn2tK_RkkoalJv9cde
X.td8VTyZp4mOzNBQrcE_IL3nZstbq7Z1b314kCVjnwpHSpr0qQUq4BXjwyR
l1Uf5t32422sJmkq56JZVILf_D4eRtQHOnc6npPWUtclx8r2rBflgVfOKNbl
nKQHvgZ44CkmT7Y1ee6acWOvzECoHLaHeQQimng3X1zqKWf_Pf5bqG8s11Tj
aMtO33rytnjgtTQanuBvf.Dde3dRedpzLR9v0neiJ3K.6NEQ_9mNLmB28cIE
.tpcbWE7oxOLvN7V4pB6x7M.Z2oaMS5Si4oLWJUA8b3XxmwJcnuj3CW6zQv5
fEP1jUxEQ2XdfvU5MYBYafTzD3oHlISjcaL9SNfSQS45HJlEsdKVSjMiFNJS
Fm06wDeZps1Ysavnd_2nfiQmUEDEEb4Yp9jelm1Fw.RKMV69eS2Rc6wxeKUR
07nHIVyFI1zCaoEUO6QhN8a2RZinHSsndv9daniLtTSk_Bou1C.JKMNE42ph x4A--
X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4-
X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with plain
[63.250.193.228])
by smtp219.mail.ne1.yahoo.com with SMTP; 05 Feb 2014 09:06:44 -0800 PST
Subject: Re: fonts and characters
From: Sean Bruno <sean_bruno@yahoo.com>
To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
In-Reply-To: <1391619779.1481.9.camel@powernoodle.corp.yahoo.com>
References: <1391614923.1481.3.camel@powernoodle.corp.yahoo.com>
<1391619779.1481.9.camel@powernoodle.corp.yahoo.com>
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 05 Feb 2014 09:06:42 -0800
Message-ID: <1391620002.1481.10.camel@powernoodle.corp.yahoo.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: sbruno@freebsd.org
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 17:06:51 -0000
On Wed, 2014-02-05 at 09:02 -0800, Sean Bruno wrote:
> On Wed, 2014-02-05 at 07:42 -0800, Sean Bruno wrote:
> > I note that I have somehow failed to install or configure my system so
> > that my terminal does not render characters outside of my alphabet at
> > all.
> >
> > Typically, I run my IRC sessions in tmux inside a xfce-terminal, but I'm
> > not sure how to get proper rendering of characters for other alphabets
> > (cyrillic, kanji, etc). Is this a trivial mistake on my part or is
> > something slightly more interesting going on?
> >
> > sean
> >
> > p.s. firefox renders other alphabets (for the most part) just fine.
>
> Huh ... setting LANG=en_US.UTF-8 totally fixes this. No idea why its
> not set but default though.
>
> sean
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Oh gross. Now the ncurses rendering in net-im/finch is screwed up. :-)
More debugging required I guess.
sean
From owner-freebsd-current@FreeBSD.ORG Wed Feb 5 19:28:27 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 7F5B82EE;
Wed, 5 Feb 2014 19:28:27 +0000 (UTC)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 540E31E26;
Wed, 5 Feb 2014 19:28:27 +0000 (UTC)
Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net
[173.70.85.31])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6A32BB99B;
Wed, 5 Feb 2014 14:28:26 -0500 (EST)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-current@freebsd.org, stable@freebsd.org
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
Date: Wed, 05 Feb 2014 09:13:50 -0500
Message-ID: <2695447.5Tzp0JqtFD@ralph.baldwin.cx>
User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; )
In-Reply-To: <52EFA015.5070601@FreeBSD.org>
References: <52EFA015.5070601@FreeBSD.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
(bigwig.baldwin.cx); Wed, 05 Feb 2014 14:28:26 -0500 (EST)
Cc: Christian Brueffer <brueffer@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 19:28:27 -0000
On Monday, February 03, 2014 02:56:37 PM Christian Brueffer wrote:
> Hi,
>
> for some time now we have had two drivers for NVIDIA NForce/MCP network
> chips, namely nve(4) and nfe(4).
>
> The former came first and is based on a binary blob. The latter was
> later ported from OpenBSD and is blob-free.
>
> nfe(4) supports all chips nve(4) supports, in addition to all the newer
> hardware. In essence, nfe(4) has been the de-facto standard driver for
> a long time. nve(4) has been commented out in GENERIC since 2007.
>
> For this reason I propose deprecating nve(4) in 10-STABLE and removing
> it from HEAD.
>
> Does anyone see a reason not to do this?
Go for it!
--
John Baldwin
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 00:58:39 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 27C10302;
Thu, 6 Feb 2014 00:58:39 +0000 (UTC)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com
[IPv6:2607:f8b0:400e:c01::233])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id E2A3C1DF9;
Thu, 6 Feb 2014 00:58:38 +0000 (UTC)
Received: by mail-pb0-f51.google.com with SMTP id un15so1078334pbc.24
for <multiple recipients>; Wed, 05 Feb 2014 16:58:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:date:to:cc:subject:message-id:reply-to:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=QraZkOCPbFClcH7/OAW2L4nuyI21quCn8bNc7xjukFg=;
b=ydKbYLQGY6kwXXFPaIMt9z1yXJEAuSX/GTa3wSCRKVzDnJ/MkaVrLGzNk4f3MCNFnA
93+WoVb4nlDLQr3zzbgEOZloiKI/c5tejBNM0JGuY2OChUvs8Mtucfi+vEkB0p5t/IPb
bAtEzmqOhgvAuEuL4o4LjqayzTTAMiqiLQMXo6Pwm6Pqa0PmlI5M1BjSk4z0JInCYNHX
whepnQ5/qiYYcybNCCwehkUHGc5108CFsEYQ6j6C40qoqpUvSqaFezt7DmZWvwSVpewT
asm3BH7RYjL4nrIefDLFxMF7ki9sTOnrtTQ75G2IuJsQdOEja9UTt6oeJTGv5ulb1xWr
93rA==
X-Received: by 10.68.143.231 with SMTP id sh7mr7121300pbb.7.1391648318579;
Wed, 05 Feb 2014 16:58:38 -0800 (PST)
Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249])
by mx.google.com with ESMTPSA id iq10sm80840568pbc.14.2014.02.05.16.58.35
for <multiple recipients>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Wed, 05 Feb 2014 16:58:37 -0800 (PST)
Received: by pyunyh@gmail.com (sSMTP sendmail emulation);
Thu, 06 Feb 2014 09:58:32 +0900
From: Yonghyeon PYUN <pyunyh@gmail.com>
Date: Thu, 6 Feb 2014 09:58:32 +0900
To: Christian Brueffer <brueffer@FreeBSD.org>
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
Message-ID: <20140206005832.GB2810@michelle.cdnetworks.com>
References: <52EFA015.5070601@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52EFA015.5070601@FreeBSD.org>
User-Agent: Mutt/1.4.2.3i
Cc: stable@freebsd.org, current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: pyunyh@gmail.com
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 00:58:39 -0000
On Mon, Feb 03, 2014 at 02:56:37PM +0100, Christian Brueffer wrote:
> Hi,
>
> for some time now we have had two drivers for NVIDIA NForce/MCP network
> chips, namely nve(4) and nfe(4).
>
> The former came first and is based on a binary blob. The latter was
> later ported from OpenBSD and is blob-free.
>
> nfe(4) supports all chips nve(4) supports, in addition to all the newer
> hardware. In essence, nfe(4) has been the de-facto standard driver for
> a long time. nve(4) has been commented out in GENERIC since 2007.
>
> For this reason I propose deprecating nve(4) in 10-STABLE and removing
> it from HEAD.
>
> Does anyone see a reason not to do this?
A couple of users were still using nve(4) in the past. I guess
the issue might be lack of code for waking up MAC/PHY from
powerdown. nfe(4) already has the needed code and should support
all known NVIDIA ethernet controllers with full offloading support.
So no objection from me.
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 02:00:10 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 18780DE3
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 02:00:10 +0000 (UTC)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com
[IPv6:2607:f8b0:400e:c02::231])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id DC9A21320
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 02:00:09 +0000 (UTC)
Received: by mail-pd0-f177.google.com with SMTP id x10so1077120pdj.8
for <freebsd-current@freebsd.org>; Wed, 05 Feb 2014 18:00:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:date:to:cc:subject:message-id:reply-to:references:mime-version
:content-type:content-disposition:content-transfer-encoding
:in-reply-to:user-agent;
bh=/RFqjDL9GP/5R9jHQ0C4qwtiIjgXYcJ3QjAq13hnSdw=;
b=nw3qv/tkIl0cw5ZZV469Wtue2Gmbl2TfpWpHCzXj2PVPEUtNtj6ZZOEGf17vgsmi/a
+cPvdZFrYmeFe5Gy7YHSW5q44vo8aZ77riMU7jPiNAyZp+Y+R/NrJgIVeJqGqLCVnzKQ
oxWLVk3Ub7fLkWNQHofYR1gsReL/p/i3lsnWgsS97Q213Okp64l6rO2Ov0qlwO38VQwy
dHlduFeMlar5U8ruFLPL9r8Hh3WAwmVpTfprIzaoIc1shMsSxfYUwFrFehmLurXZfAmP
MAvjtyfT5x7kdCti4mZFNywqjdSwB2iw75Iqg/y7JVU1yQDPygIntCgVwMDcriqx6m2y
s2OA==
X-Received: by 10.68.240.36 with SMTP id vx4mr7628132pbc.140.1391652009345;
Wed, 05 Feb 2014 18:00:09 -0800 (PST)
Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249])
by mx.google.com with ESMTPSA id j3sm81181852pbh.38.2014.02.05.18.00.06
for <multiple recipients>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Wed, 05 Feb 2014 18:00:08 -0800 (PST)
Received: by pyunyh@gmail.com (sSMTP sendmail emulation);
Thu, 06 Feb 2014 11:00:03 +0900
From: Yonghyeon PYUN <pyunyh@gmail.com>
Date: Thu, 6 Feb 2014 11:00:03 +0900
To: Boris Samorodov <bsam@passap.ru>
Subject: Re: regression: msk0 watchdog timeout and interrupt storm
Message-ID: <20140206020003.GC2810@michelle.cdnetworks.com>
References: <526FBA53.9000208@passap.ru>
<20131030021650.GA3106@michelle.cdnetworks.com> <52725C3D.2030602@passap.ru>
<52ECADF3.4020909@passap.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <52ECADF3.4020909@passap.ru>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: pyunyh@gmail.com
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 02:00:10 -0000
On Sat, Feb 01, 2014 at 12:18:59PM +0400, Boris Samorodov wrote:
> Hi Yonghyeon and All,
>
> (this time it's a CURRENT issue)
>
> 31.10.2013 17:33, Boris Samorodov пишет:
> > 30.10.2013 06:16, Yonghyeon PYUN пишет:
> >> On Tue, Oct 29, 2013 at 05:38:27PM +0400, Boris Samorodov wrote:
> >
> >>> >From time to time I use a notebook and boot FreeBSD from USB
> >>> stick. FreeBSD 9.2-i386 works OK. So I tried to use
> >>> FreeBSD 10.0-i386 BETA2 and the network adapter works for
> >>> some 10-15 seconds and then stops with diagnostic message
> >>> "msk0:watchdog timeout". I've found similar case at
> >>> freebsd-current@ with no workaround. Yes, there is an
> >>> interrupt storm as well.
> >>
> >> There had been no functional changes for very long time so I'm not
> >> sure what's going on here. I've attached local change I have at
> >> this moment but I'm afraid it wouldn't address the issue above.
> >>
> >> I recall jhb also reported interrupt storm in the past but the root
> >> cause was not identified yet. Could you change msk_intr() and let
> >> me know which interrupt is firing?
> >
> > I've yet to organize a build.
> >
> >>> Here is some additional info:
> >>> -----
> >>> mskc0@pci0:3:0:0: class=0x020000 card=0xff501179 chip=0x435511ab
> >>> rev=0x12 hdr=0x00
> >>> vendor = 'Marvell Technology Group Ltd.'
> >>> device = '88E8040T PCI-E Fast Ethernet Controller'
> >>> class = network
> >>> subclass = ethernet
> >>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0
> >>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message
> >>> cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1)
> >>> speed 2.5(2.5) ASPM disabled(L0s/L1)
> >>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
> >>> ecap 0003[130] = Serial 1 b8b063ffff681e00
> >>> -----
> >
> > Meanwhile some more investigations, "vmstat -i" for calm and storm:
> > -----
> > interrupt total rate
> > irq1: atkbd0 1025 2
> > irq9: acpi0 204 0
> > irq14: ata0 327 0
> > irq16: uhci0+ 246 0
> > irq20: hpet0 22472 52
> > irq23: uhci2 ehci1 10341 24
> > irq256: hdac0 52 0
> > irq257: mskc0 258 0
> > irq258: ahci0 221 0
> > Total 35146 81
> > -----
> > interrupt total rate
> > irq1: atkbd0 1508 2
> > irq9: acpi0 234 0
> > irq14: ata0 409 0
> > irq16: uhci0+ 246 0
> > irq20: hpet0 72288 131
> > irq23: uhci2 ehci1 10846 19
> > irq256: hdac0 52 0
> > irq257: mskc0 4419760 8021
> > irq258: ahci0 221 0
> > Total 4505564 8177
> > -----
> >
> > And "vmstat -w1" for calm and storm:
> > -----
> > procs memory page disks faults cpu
> > r b w avm fre flt re pi po fr sr mm0 ad0 in sy cs
> > us sy id
> > 0 0 0 206928 956040 277 0 2 0 330 4 0 0 117 476
> > 454 0 1 99
> > 0 0 0 206928 956036 0 0 0 0 8 4 0 0 50 123
> > 137 0 0 100
> > 0 0 0 206928 956036 0 0 0 0 0 4 0 0 47 120
> > 92 0 1 99
> > 0 0 0 206928 956036 0 0 0 0 0 4 0 0 43 123
> > 119 0 1 99
> > 0 0 0 206928 956036 0 0 0 0 0 4 0 0 55 132
> > 123 0 1 99
> > 0 0 0 206928 956004 0 0 0 0 0 4 0 0 68 123
> > 185 0 1 99
> > 0 0 0 206928 956036 0 0 0 0 8 4 0 0 86 123
> > 266 0 1 99
> > 0 0 0 206928 956036 0 0 0 0 0 4 0 0 44 125
> > 124 0 0 100
> > 0 0 0 206928 956036 0 0 0 0 0 4 0 0 64 128
> > 164 0 1 99
> > 0 0 0 206928 956036 0 0 0 0 0 4 0 0 42 131
> > 101 0 1 99
> > -----
> > procs memory page disks faults cpu
> > r b w avm fre flt re pi po fr sr mm0 ad0 in sy cs
> > us sy id
> > 0 0 0 213648 954676 104 0 1 0 121 4 0 0 22299 204
> > 44262 0 10 90
> > 0 0 0 213648 954672 0 0 0 0 8 4 0 0 112259 123
> > 222379 0 44 56
> > 0 0 0 213648 954672 0 0 0 0 0 4 0 0 111792 123
> > 221489 0 43 57
> > 0 0 0 213648 954672 1 0 0 0 0 4 0 0 109887 183
> > 217754 0 43 57
> > 0 0 0 213648 954668 2 0 0 0 0 4 0 0 109543 146
> > 216963 0 44 56
> > 0 0 0 213648 954668 0 0 0 0 0 4 0 0 110142 123
> > 218187 0 45 55
> > 0 0 0 213648 954660 472 0 0 0 474 4 0 0 109340 717
> > 216674 0 42 57
> > 0 0 0 213648 954656 2 0 0 0 0 4 0 0 109459 147
> > 216831 0 43 57
> > 0 0 0 213648 954656 0 0 0 0 0 4 0 0 109462 131
> > 216827 0 43 57
> > 0 0 0 213648 954656 0 0 0 0 0 4 0 0 109454 123
> > 216803 0 42 58
> > -----
> >
> > Dmesg is here: ftp://ftp.wart.ru/pub/misc/tos.dmesg.boot.txt .
> >
> > BTW, some more observations. While downloading a file the system
> > goto watchdog timeout rather quickly, but the system works. If I
> > try to upload files the system works much longer (for a couple of
> > minutes) but then freeses. No ctrl-alt-esc. Only cold restart works.
>
> I've successfully upgraded to 10.0-RELEASE. Then I tried CURRENT
> (verbose dmesg is here: ftp://ftp.wart.ru/pub/misc/dmesg.boot.a300.txt )
> and I've got watchdog timeouts. The situation is very much alike
> (see previous diagnostics). Just uploads happens very quickly and
> the machine is not freezed and operates well.
>
> This time I have sources and can test patches (if any) rather
> quickly.
>
There is no driver code difference between CURRENT and
10.0-RELEASE. If you don't encounter watchdog timeouts on
10.0-RELEASE I have no idea what's going on there.
I recall a couple of users are seeing msk(4) watchdog timeouts on
10.0-RELEASE/CURRENT so I started to think about r234666 which was
not merged to stable/9 and stable/8.
Could you back out r234666 and let me know whether it makes any
difference for you?
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 09:08:20 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 2CAF0CF
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 09:08:20 +0000 (UTC)
Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com
[207.126.144.131])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 7822917DC
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 09:08:19 +0000 (UTC)
Received: from mail-wg0-f42.google.com ([74.125.82.42]) (using TLSv1) by
eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP
ID DSNKUvNQ6FUDWfn1rI2Vd0kpDJec/viYC/dk@postini.com;
Thu, 06 Feb 2014 09:08:19 UTC
Received: by mail-wg0-f42.google.com with SMTP id l18so6122984wgh.3
for <freebsd-current@freebsd.org>; Thu, 06 Feb 2014 01:07:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to;
bh=Tkh6jIWTqKNylujOClTcU7cMoXE9WnqcQEJCozi7fKg=;
b=ig6uzn5SoJY5oDyUmzxp4XL218WJMXJ4GoUv1FUFF9GwnEoY72hGDkcdBjxEnS8wKh
xXQ3mVYJ5zSlJCLz0kZjL0QEEYAEBlkP3kxXLBZNhQofKg5EUOspXquVBCeF7lJjJP55
vBArzCe70DGZIG4WcdZHQGu+62reUSzjZ/hRIIRk+I1SSCIaYA0UFurM5cSEOl3wKff4
d30tQy/jFKsQ3zxQJEIsbe3fq+WQCPCovVRchf1knn+47VrwVBHtkoBEofqU8LGQc1sR
m5Wm42EhzxC88HIRyxI9VfWrF2ShnBudSVEbXztiMaWOKN3hgx2O9xNau8dvQN4rclU3
bxsg==
X-Gm-Message-State: ALoCoQlGPltMYEwiUoZZzxHi5sT6RHby5GWyytu2ILoCq6l9LAI0iXyjpKYt73X+X0d6Jghxee71HVov84zTGizDqZwWc3t/lS3x6PiZYQ+dYLufE3LmKK9SN+qlMqpWwBzDayudPz/BUfDVBrKgIHi8yuwRvYh//P8cfBQRfcm+S3R0/qZ784E=
X-Received: by 10.180.92.169 with SMTP id cn9mr5806548wib.35.1391677672112;
Thu, 06 Feb 2014 01:07:52 -0800 (PST)
X-Received: by 10.180.92.169 with SMTP id cn9mr5806542wib.35.1391677672033;
Thu, 06 Feb 2014 01:07:52 -0800 (PST)
Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk.
[137.222.187.241])
by mx.google.com with ESMTPSA id ff9sm53532184wib.11.2014.02.06.01.07.50
for <freebsd-current@freebsd.org>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 06 Feb 2014 01:07:50 -0800 (PST)
Sender: Anton Shterenlikht <mexas@bristol.ac.uk>
Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1])
by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id s1697nYS004555
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 09:07:49 GMT
(envelope-from mexas@mech-cluster241.men.bris.ac.uk)
Received: (from mexas@localhost)
by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id s1697nvv004554
for freebsd-current@freebsd.org; Thu, 6 Feb 2014 09:07:49 GMT
(envelope-from mexas)
Date: Thu, 06 Feb 2014 01:07:50 -0800 (PST)
From: Anton Shterenlikht <mexas@bris.ac.uk>
Message-Id: <201402060907.s1697nvv004554@mech-cluster241.men.bris.ac.uk>
To: freebsd-current@freebsd.org
Subject: svn0.eu.freebsd.org timed out - temporary problems?
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mexas@bris.ac.uk
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 09:08:20 -0000
Something wrong with the svn0.eu.freebsd.org mirror:
svn: E000060: Unable to connect to a repository at URL 'https://svn0.eu.freebsd.org/base/head'
svn: E000060: Error running context: Operation timed out
I hope it's temprorary problem, but
please advise if the mirror address has
changed.
Thanks
Anton
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 10:51:51 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id D04ED417;
Thu, 6 Feb 2014 10:51:51 +0000 (UTC)
Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca
[64.7.128.98])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 8839C1344;
Thu, 6 Feb 2014 10:51:51 +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 s16Api9Y041611;
Thu, 6 Feb 2014 05:51:44 -0500 (EST)
(envelope-from tinderbox@freebsd.org)
Received: (from tinderbox@localhost)
by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s16ApiVJ041610;
Thu, 6 Feb 2014 10:51:44 GMT (envelope-from tinderbox@freebsd.org)
Date: Thu, 6 Feb 2014 10:51:44 GMT
Message-Id: <201402061051.s16ApiVJ041610@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>,
<amd64@freebsd.org>
Subject: [head tinderbox] failure on amd64/amd64
Precedence: bulk
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 10:51:51 -0000
TB --- 2014-02-06 10:10:18 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-06 10:10:18 - 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 --- 2014-02-06 10:10:18 - starting HEAD tinderbox run for amd64/amd64
TB --- 2014-02-06 10:10:18 - cleaning the object tree
TB --- 2014-02-06 10:10:18 - /usr/local/bin/svn stat /src
TB --- 2014-02-06 10:10:23 - At svn revision 261542
TB --- 2014-02-06 10:10:24 - building world
TB --- 2014-02-06 10:10:24 - CROSS_BUILD_TESTING=YES
TB --- 2014-02-06 10:10:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-02-06 10:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-02-06 10:10:24 - SRCCONF=/dev/null
TB --- 2014-02-06 10:10:24 - TARGET=amd64
TB --- 2014-02-06 10:10:24 - TARGET_ARCH=amd64
TB --- 2014-02-06 10:10:24 - TZ=UTC
TB --- 2014-02-06 10:10:24 - __MAKE_CONF=/dev/null
TB --- 2014-02-06 10:10:24 - cd /src
TB --- 2014-02-06 10:10:24 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Feb 6 10:10:30 UTC 2014
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
[...]
c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp -o DwarfCFIException.o
c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp -o DwarfCompileUnit.o
c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp -o DwarfDebug.o
/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp: In destructor 'llvm::DwarfDebug::~DwarfDebug()':
/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:212: internal compiler error: in var_ann, at tree-flow-inline.h:127
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1
Stop.
bmake[3]: stopped in /src/lib/clang/libllvmasmprinter
*** Error code 1
Stop.
bmake[2]: stopped in /src/lib/clang
*** Error code 1
Stop.
bmake[1]: stopped in /src
*** Error code 1
Stop.
bmake: stopped in /src
*** Error code 1
Stop in /src.
TB --- 2014-02-06 10:51:44 - WARNING: /usr/bin/make returned exit code 1
TB --- 2014-02-06 10:51:44 - ERROR: failed to build world
TB --- 2014-02-06 10:51:44 - 2213.46 user 210.65 system 2485.23 real
http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 15:30:53 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 9FFD7C37;
Thu, 6 Feb 2014 15:30:53 +0000 (UTC)
Received: from mail0.glenbarber.us (mail0.glenbarber.us
[IPv6:2607:fc50:1:2300:1001:1001:1001:face])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 7062F1307;
Thu, 6 Feb 2014 15:30:53 +0000 (UTC)
Received: from glenbarber.us (1.sub-70-192-128.myvzw.com [70.192.128.1])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate) (Authenticated sender: gjb)
by mail0.glenbarber.us (Postfix) with ESMTPSA id C961F1F5C5;
Thu, 6 Feb 2014 15:30:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us C961F1F5C5
Authentication-Results: mail0.glenbarber.us; dkim=none
reason="no signature"; dkim-adsp=none
Date: Thu, 6 Feb 2014 10:30:50 -0500
From: Glen Barber <gjb@FreeBSD.org>
To: Anton Shterenlikht <mexas@bris.ac.uk>
Subject: Re: svn0.eu.freebsd.org timed out - temporary problems?
Message-ID: <20140206153050.GD1514@glenbarber.us>
References: <201402060907.s1697nvv004554@mech-cluster241.men.bris.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="RYJh/3oyKhIjGcML"
Content-Disposition: inline
In-Reply-To: <201402060907.s1697nvv004554@mech-cluster241.men.bris.ac.uk>
X-Operating-System: FreeBSD 11.0-CURRENT amd64
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: freebsd-current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 15:30:53 -0000
--RYJh/3oyKhIjGcML
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Feb 06, 2014 at 01:07:50AM -0800, Anton Shterenlikht wrote:
> Something wrong with the svn0.eu.freebsd.org mirror:
>=20
> svn: E000060: Unable to connect to a repository at URL 'https://svn0.eu.f=
reebsd.org/base/head'
> svn: E000060: Error running context: Operation timed out
>=20
This should be fixed now.
> I hope it's temprorary problem, but
> please advise if the mirror address has
> changed.
>=20
Glen
--RYJh/3oyKhIjGcML
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBCAAGBQJS86qqAAoJELls3eqvi17QS1cP/0M7EFMBS7X8f9VIEBI/y5Uw
p87o/tmvZQZu++77mcEe/EiDTXJ//XzVyprrUXL2dfJUrCW93+tn9ys+YrpI0Xbd
igdQwcB7ZHOg8KgzMjkhVyJ1aJu9rXnkQbEP2wPdno+Nysce/pkKPuAkFwyYQsmE
jC9xEvwpgJbx7Mcs5EvrRY/4ignWCOZxfnGaJ9wtKQqTwPkJ/zpu5UF6DdvKHVVm
eJp+HTBsvMdyoVAR/WmWPLhnKEvfCdA9TOoCgk9hyWcXsdsurU/glX4XtnD9AR3/
23Ue1JwzTwmIQuZcKwfxZh5gvTgjL0on+xmMuWfw7oFzRGb4WdnO9dM39nulWuUz
IYUmCf72lCWkp3J2io+TQgoNRTpOKAK+gqCfCvE8M89gbdxBfi39bnz/1f0EvKl5
/HlMsTCaTB2Ir85E7YO+8jls09U3zhrGLVgkdhPk5c/9S448rapnR2s8b87jaRBs
vTm9GwpsxUy+ufOOQWPvGhFFOEKLJHRHeEPZ+lzCn0upLzX5JD54Z1KphfaZ2AM0
hSaipz0vKssU01qsbUW3GfypksJpSNAB7LxgsuttxgF5vRxbgmWGvypsZ3qhR9KX
TWD0ZdJCvRjfiyoQ2UahfyDZpVNFtkEsbK65sSvIOMc+wVa8VQhXkgQzTQcSM2Cx
8DcsJy5j5RXsT1wZpBWN
=gK8H
-----END PGP SIGNATURE-----
--RYJh/3oyKhIjGcML--
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 15:35:21 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id B4088F67
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 15:35:21 +0000 (UTC)
Received: from eu1sys200aog124.obsmtp.com (eu1sys200aog124.obsmtp.com
[207.126.144.157])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id B7FB8136A
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 15:35:20 +0000 (UTC)
Received: from mail-wi0-f174.google.com ([209.85.212.174]) (using TLSv1) by
eu1sys200aob124.postini.com ([207.126.147.11]) with SMTP
ID DSNKUvOrnYBOywgqiJpr5UNAGMIjTcD7FzKY@postini.com;
Thu, 06 Feb 2014 15:35:20 UTC
Received: by mail-wi0-f174.google.com with SMTP id f8so1731601wiw.7
for <freebsd-current@freebsd.org>; Thu, 06 Feb 2014 07:34:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:sender:date:from:message-id:to:subject:cc
:reply-to:in-reply-to;
bh=kL8pFvhv8A1RwIti3Bizr1w21CY4jHV+MNyAfA4mqMw=;
b=CpSoMA0s71Nb1FHvw2YBZeX4WOsnZQKvUmD8bnNln0HQjujT52ftXXnsgGfaivg7pd
MgGEeBqrThp1mZwvaBE30djk94/DXAiccq/2fZraPNp36los5+NdMimpf6wns3u/bpvp
3MBAIXkt5cJ/V2ThfRpbD6aqNc/WqzhGe3HyFsjOsKZvq+BVbibEP9Op96EP8ilkwHzo
K8ZIOofJ+2DZjgSxxQTbXnH4+nwKDdIXVR1UYS5sxanyc+edfTU0NiDyF4Qisq9DsWFA
7cnBR0zgmp2Ty0ci4oyLPpbXCg8ibDPS9O0DV16qyQ3Vr0SyUCJ2r5p/aNZCBcW8Teen
lYcQ==
X-Gm-Message-State: ALoCoQm3R+QnYmEV1f8SA/929luhplto+O7+SoMIUCaeG5d7qonw15KNLBgE2FcVn2n+k+u0kFL+44G1OHEJ7HQahdRrhdaw5n0T4v1Dlq8TLjyc03ICDcjJMW6+JfAUCReVI77hbCaaiWhSZ+k812iTigMOS7ANK3Hm+u/OTpLYKG0FyheSiS4=
X-Received: by 10.180.96.228 with SMTP id dv4mr7418673wib.24.1391700892988;
Thu, 06 Feb 2014 07:34:52 -0800 (PST)
X-Received: by 10.180.96.228 with SMTP id dv4mr7418660wib.24.1391700892833;
Thu, 06 Feb 2014 07:34:52 -0800 (PST)
Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk.
[137.222.187.241])
by mx.google.com with ESMTPSA id ea4sm56405874wib.7.2014.02.06.07.34.51
for <multiple recipients>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 06 Feb 2014 07:34:51 -0800 (PST)
Sender: Anton Shterenlikht <mexas@bristol.ac.uk>
Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1])
by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id s16FYnHg005743
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Thu, 6 Feb 2014 15:34:49 GMT
(envelope-from mexas@mech-cluster241.men.bris.ac.uk)
Received: (from mexas@localhost)
by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id s16FYnVb005742;
Thu, 6 Feb 2014 15:34:49 GMT (envelope-from mexas)
Date: Thu, 06 Feb 2014 07:34:51 -0800 (PST)
From: Anton Shterenlikht <mexas@bris.ac.uk>
Message-Id: <201402061534.s16FYnVb005742@mech-cluster241.men.bris.ac.uk>
To: gjb@FreeBSD.org, mexas@bris.ac.uk
Subject: Re: svn0.eu.freebsd.org timed out - temporary problems?
In-Reply-To: <20140206153050.GD1514@glenbarber.us>
Cc: freebsd-current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mexas@bris.ac.uk
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 15:35:21 -0000
>From gjb@freebsd.org Thu Feb 6 15:34:12 2014
>
>On Thu, Feb 06, 2014 at 01:07:50AM -0800, Anton Shterenlikht wrote:
>> Something wrong with the svn0.eu.freebsd.org mirror:
>>=20
>> svn: E000060: Unable to connect to a repository at URL 'https://svn0.eu.f=
>reebsd.org/base/head'
>> svn: E000060: Error running context: Operation timed out
>>=20
>
>This should be fixed now.
it is
Thanks
Anton
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 17:12:26 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id BB0B7CF8
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 17:12:26 +0000 (UTC)
Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net
[IPv6:2a02:6b8:0:1819::4])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 656691D3D
for <freebsd-current@freebsd.org>; Thu, 6 Feb 2014 17:12:26 +0000 (UTC)
Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67])
by forward4l.mail.yandex.net (Yandex) with ESMTP id B62AD14410A4;
Thu, 6 Feb 2014 21:12:22 +0400 (MSK)
Received: from smtp11.mail.yandex.net (localhost [127.0.0.1])
by smtp11.mail.yandex.net (Yandex) with ESMTP id 602D27E0061;
Thu, 6 Feb 2014 21:12:22 +0400 (MSK)
Received: from 78.108.206.159.tel.ru (78.108.206.159.tel.ru [78.108.206.159])
by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id
FEzRRiNgo6-CMhqJqdp; Thu, 6 Feb 2014 21:12:22 +0400
(using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits))
(Client certificate not present)
X-Yandex-Uniq: 71f8ddf0-9bf6-4421-b342-c1aeba3ee3da
Message-ID: <52F3C275.6000106@passap.ru>
Date: Thu, 06 Feb 2014 21:12:21 +0400
From: Boris Samorodov <bsam@passap.ru>
Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?=
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: pyunyh@gmail.com
Subject: Re: regression: msk0 watchdog timeout and interrupt storm
References: <526FBA53.9000208@passap.ru>
<20131030021650.GA3106@michelle.cdnetworks.com> <52725C3D.2030602@passap.ru>
<52ECADF3.4020909@passap.ru> <20140206020003.GC2810@michelle.cdnetworks.com>
In-Reply-To: <20140206020003.GC2810@michelle.cdnetworks.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 17:12:26 -0000
06.02.2014 06:00, Yonghyeon PYUN пишет:
> On Sat, Feb 01, 2014 at 12:18:59PM +0400, Boris Samorodov wrote:
>> Hi Yonghyeon and All,
>>
>> (this time it's a CURRENT issue)
>>
>> 31.10.2013 17:33, Boris Samorodov пишет:
>>> 30.10.2013 06:16, Yonghyeon PYUN пишет:
>>>> On Tue, Oct 29, 2013 at 05:38:27PM +0400, Boris Samorodov wrote:
>>>
>>>>> >From time to time I use a notebook and boot FreeBSD from USB
>>>>> stick. FreeBSD 9.2-i386 works OK. So I tried to use
>>>>> FreeBSD 10.0-i386 BETA2 and the network adapter works for
>>>>> some 10-15 seconds and then stops with diagnostic message
>>>>> "msk0:watchdog timeout". I've found similar case at
>>>>> freebsd-current@ with no workaround. Yes, there is an
>>>>> interrupt storm as well.
>>>>
>>>> There had been no functional changes for very long time so I'm not
>>>> sure what's going on here. I've attached local change I have at
>>>> this moment but I'm afraid it wouldn't address the issue above.
>>>>
>>>> I recall jhb also reported interrupt storm in the past but the root
>>>> cause was not identified yet. Could you change msk_intr() and let
>>>> me know which interrupt is firing?
>>>
>>> I've yet to organize a build.
>>>
>>>>> Here is some additional info:
>>>>> -----
>>>>> mskc0@pci0:3:0:0: class=0x020000 card=0xff501179 chip=0x435511ab
>>>>> rev=0x12 hdr=0x00
>>>>> vendor = 'Marvell Technology Group Ltd.'
>>>>> device = '88E8040T PCI-E Fast Ethernet Controller'
>>>>> class = network
>>>>> subclass = ethernet
>>>>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0
>>>>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message
>>>>> cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1)
>>>>> speed 2.5(2.5) ASPM disabled(L0s/L1)
>>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
>>>>> ecap 0003[130] = Serial 1 b8b063ffff681e00
>>>>> -----
>>>
>>> Meanwhile some more investigations, "vmstat -i" for calm and storm:
>>> -----
>>> interrupt total rate
>>> irq1: atkbd0 1025 2
>>> irq9: acpi0 204 0
>>> irq14: ata0 327 0
>>> irq16: uhci0+ 246 0
>>> irq20: hpet0 22472 52
>>> irq23: uhci2 ehci1 10341 24
>>> irq256: hdac0 52 0
>>> irq257: mskc0 258 0
>>> irq258: ahci0 221 0
>>> Total 35146 81
>>> -----
>>> interrupt total rate
>>> irq1: atkbd0 1508 2
>>> irq9: acpi0 234 0
>>> irq14: ata0 409 0
>>> irq16: uhci0+ 246 0
>>> irq20: hpet0 72288 131
>>> irq23: uhci2 ehci1 10846 19
>>> irq256: hdac0 52 0
>>> irq257: mskc0 4419760 8021
>>> irq258: ahci0 221 0
>>> Total 4505564 8177
>>> -----
>>>
>>> And "vmstat -w1" for calm and storm:
>>> -----
>>> procs memory page disks faults cpu
>>> r b w avm fre flt re pi po fr sr mm0 ad0 in sy cs
>>> us sy id
>>> 0 0 0 206928 956040 277 0 2 0 330 4 0 0 117 476
>>> 454 0 1 99
>>> 0 0 0 206928 956036 0 0 0 0 8 4 0 0 50 123
>>> 137 0 0 100
>>> 0 0 0 206928 956036 0 0 0 0 0 4 0 0 47 120
>>> 92 0 1 99
>>> 0 0 0 206928 956036 0 0 0 0 0 4 0 0 43 123
>>> 119 0 1 99
>>> 0 0 0 206928 956036 0 0 0 0 0 4 0 0 55 132
>>> 123 0 1 99
>>> 0 0 0 206928 956004 0 0 0 0 0 4 0 0 68 123
>>> 185 0 1 99
>>> 0 0 0 206928 956036 0 0 0 0 8 4 0 0 86 123
>>> 266 0 1 99
>>> 0 0 0 206928 956036 0 0 0 0 0 4 0 0 44 125
>>> 124 0 0 100
>>> 0 0 0 206928 956036 0 0 0 0 0 4 0 0 64 128
>>> 164 0 1 99
>>> 0 0 0 206928 956036 0 0 0 0 0 4 0 0 42 131
>>> 101 0 1 99
>>> -----
>>> procs memory page disks faults cpu
>>> r b w avm fre flt re pi po fr sr mm0 ad0 in sy cs
>>> us sy id
>>> 0 0 0 213648 954676 104 0 1 0 121 4 0 0 22299 204
>>> 44262 0 10 90
>>> 0 0 0 213648 954672 0 0 0 0 8 4 0 0 112259 123
>>> 222379 0 44 56
>>> 0 0 0 213648 954672 0 0 0 0 0 4 0 0 111792 123
>>> 221489 0 43 57
>>> 0 0 0 213648 954672 1 0 0 0 0 4 0 0 109887 183
>>> 217754 0 43 57
>>> 0 0 0 213648 954668 2 0 0 0 0 4 0 0 109543 146
>>> 216963 0 44 56
>>> 0 0 0 213648 954668 0 0 0 0 0 4 0 0 110142 123
>>> 218187 0 45 55
>>> 0 0 0 213648 954660 472 0 0 0 474 4 0 0 109340 717
>>> 216674 0 42 57
>>> 0 0 0 213648 954656 2 0 0 0 0 4 0 0 109459 147
>>> 216831 0 43 57
>>> 0 0 0 213648 954656 0 0 0 0 0 4 0 0 109462 131
>>> 216827 0 43 57
>>> 0 0 0 213648 954656 0 0 0 0 0 4 0 0 109454 123
>>> 216803 0 42 58
>>> -----
>>>
>>> Dmesg is here: ftp://ftp.wart.ru/pub/misc/tos.dmesg.boot.txt .
>>>
>>> BTW, some more observations. While downloading a file the system
>>> goto watchdog timeout rather quickly, but the system works. If I
>>> try to upload files the system works much longer (for a couple of
>>> minutes) but then freeses. No ctrl-alt-esc. Only cold restart works.
>>
>> I've successfully upgraded to 10.0-RELEASE. Then I tried CURRENT
>> (verbose dmesg is here: ftp://ftp.wart.ru/pub/misc/dmesg.boot.a300.txt )
>> and I've got watchdog timeouts. The situation is very much alike
>> (see previous diagnostics). Just uploads happens very quickly and
>> the machine is not freezed and operates well.
>>
>> This time I have sources and can test patches (if any) rather
>> quickly.
>>
>
> There is no driver code difference between CURRENT and
> 10.0-RELEASE. If you don't encounter watchdog timeouts on
> 10.0-RELEASE I have no idea what's going on there.
> I recall a couple of users are seeing msk(4) watchdog timeouts on
> 10.0-RELEASE/CURRENT so I started to think about r234666 which was
> not merged to stable/9 and stable/8.
>
> Could you back out r234666 and let me know whether it makes any
> difference for you?
Thank you!
That was it. The system survived svn up of /usr/src, rebuild/reinstall
and almost 25000 patches were downloaded by portsnap.
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 18:35:09 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 7981FB57;
Thu, 6 Feb 2014 18:35:09 +0000 (UTC)
Received: from land.berklix.org (land.berklix.org [144.76.10.75])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 15A2A1695;
Thu, 6 Feb 2014 18:35:08 +0000 (UTC)
Received: from park.js.berklix.net (pD9FBF118.dip0.t-ipconnect.de
[217.251.241.24]) (authenticated bits=128)
by land.berklix.org (8.14.5/8.14.5) with ESMTP id s16IYcUe017054;
Thu, 6 Feb 2014 18:34:38 GMT (envelope-from jhs@berklix.com)
Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41])
by park.js.berklix.net (8.14.3/8.14.3) with ESMTP id s16IZ0B2097161;
Thu, 6 Feb 2014 19:35:01 +0100 (CET) (envelope-from jhs@berklix.com)
Received: from fire.js.berklix.net (localhost [127.0.0.1])
by fire.js.berklix.net (8.14.5/8.14.5) with ESMTP id s16IYgDK044802;
Thu, 6 Feb 2014 19:34:54 +0100 (CET) (envelope-from jhs@berklix.com)
Message-Id: <201402061834.s16IYgDK044802@fire.js.berklix.net>
To: stable@freebsd.org, current@freebsd.org
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
From: "Julian H. Stacey" <jhs@berklix.com>
Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany
User-agent: EXMH on FreeBSD http://berklix.com/free/
X-URL: http://www.berklix.com
In-reply-to: Your message "Thu, 06 Feb 2014 09:58:32 +0900."
<20140206005832.GB2810@michelle.cdnetworks.com>
Date: Thu, 06 Feb 2014 19:34:42 +0100
Cc: pyunyh@gmail.com, Christian Brueffer <brueffer@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 18:35:09 -0000
Yonghyeon PYUN wrote:
> On Mon, Feb 03, 2014 at 02:56:37PM +0100, Christian Brueffer wrote:
> > Hi,
> >
> > for some time now we have had two drivers for NVIDIA NForce/MCP network
> > chips, namely nve(4) and nfe(4).
> >
> > The former came first and is based on a binary blob. The latter was
> > later ported from OpenBSD and is blob-free.
> >
> > nfe(4) supports all chips nve(4) supports, in addition to all the newer
> > hardware. In essence, nfe(4) has been the de-facto standard driver for
> > a long time. nve(4) has been commented out in GENERIC since 2007.
> >
> > For this reason I propose deprecating nve(4) in 10-STABLE and removing
> > it from HEAD.
> >
> > Does anyone see a reason not to do this?
>
> A couple of users were still using nve(4) in the past. I guess
> the issue might be lack of code for waking up MAC/PHY from
> powerdown. nfe(4) already has the needed code and should support
> all known NVIDIA ethernet controllers with full offloading support.
> So no objection from me.
It seems a good case to remove nve, no objection.
Please remove at a leisurely managed pace:
(unless code conflicts press for urgency), ie at least one minor
release on each major branch should contain a code revocation
warning in the manual & preferably in a src/[A-Z]*, before the
next minor release in same major release sequence might no longer
contain old code.
( Not to suggest it wasn't planned similarly anyway, but some
changes in other areas of FreeBSD have been rushed, & it's
good to set an example of planning maturity. )
Some FreeBSD end users inc. customers barely (if even) read
announce@, let alone other lists such as these, but some do read
manuals, & notice code withdrawal warnings.
I informed one old customer who was maybe still using nve, others
might take a similar opportunity, a subtle way to also invite people
to look at FreeBSD [again] ;-) , referring to eg:
http://lists.freebsd.org/pipermail/freebsd-current/2014-February/048211.html
http://svnweb.freebsd.org/base/release/10.0.0/share/man/man4/nve.4?view=markup
http://svnweb.freebsd.org/base/release/10.0.0/share/man/man4/nfe.4?view=markup
It seems safe to add a removal warning in
http://svnweb.freebsd.org/base/head/share/man/man4/nve.4?view=markup
( there is not one yet at Rev 217468, I just checked. )
Best avoid the obscure word `Deprecated' in manuals:
It's not common/ plain English. Maybe a geek import, or USA
dialect ? It's not easily internationaly understood English.
Best make manuals easier for non native English speakers (& native
English too ;-). I am British born & bred, whether in English
speaking circles in UK or Germany I never hear or read 'deprecated'
unless its in BSD context. Few native English speakers I know will be
immediately sure of the meaning, it's too obscure.
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
Interleave replies below like a play script. Indent old text with "> ".
Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 18:50:32 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 3A9E6741;
Thu, 6 Feb 2014 18:50:32 +0000 (UTC)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com
[IPv6:2a00:1450:4010:c04::229])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 89DF91844;
Thu, 6 Feb 2014 18:50:31 +0000 (UTC)
Received: by mail-lb0-f169.google.com with SMTP id q8so1818134lbi.14
for <multiple recipients>; Thu, 06 Feb 2014 10:50:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=7htCA706ZJLAR3KMAdzmXpv2CugY00OAlFX9Sz+uCoE=;
b=qFnPo46CBc31BGhsU1t6IY34aoz7ehOeD4X7Ux5bqebkSHxUge2vKJTggLnpCsCbKO
vqmJjzs36WeutMShB5UZLGlhjKFn2grF8GI2xqVolmzdgS2aSKvRUwZkJu7W3u/LU9u+
BIDp7xNHRa8Z1tqI7snPZ/WDXZpbbQKMENwme75hKzruxxfUU8l2M/xHffcNfDIilY2K
F6A9ItKT+NKy6EIyRXe5L4DwehdFI0zfulJgLNG21RY/8SWGqwhFKTRPJ2nNMfcARsSs
5z2MUCtAuUm4RRXmaSGByvSohR/fvOzGHJRvgyZ0zUw5HxgngX4YNbhDpasSuo3uLwZd
TWwA==
MIME-Version: 1.0
X-Received: by 10.153.0.33 with SMTP id av1mr6824449lad.14.1391712629567; Thu,
06 Feb 2014 10:50:29 -0800 (PST)
Received: by 10.112.0.205 with HTTP; Thu, 6 Feb 2014 10:50:29 -0800 (PST)
In-Reply-To: <201402061834.s16IYgDK044802@fire.js.berklix.net>
References: <20140206005832.GB2810@michelle.cdnetworks.com>
<201402061834.s16IYgDK044802@fire.js.berklix.net>
Date: Thu, 6 Feb 2014 18:50:29 +0000
Message-ID: <CAFHbX1KUwq66BXn7pU3AQ3pQmnmq+VwygSWQEK2Npu=AcVcOxw@mail.gmail.com>
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
From: Tom Evans <tevans.uk@googlemail.com>
To: "Julian H. Stacey" <jhs@berklix.com>
Content-Type: text/plain; charset=UTF-8
Cc: FreeBSD Stable <stable@freebsd.org>, current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 18:50:32 -0000
On Thu, Feb 6, 2014 at 6:34 PM, Julian H. Stacey <jhs@berklix.com> wrote:
> Best avoid the obscure word `Deprecated' in manuals:
> It's not common/ plain English. Maybe a geek import, or USA
> dialect ? It's not easily internationaly understood English.
> Best make manuals easier for non native English speakers (& native
> English too ;-). I am British born & bred, whether in English
> speaking circles in UK or Germany I never hear or read 'deprecated'
> unless its in BSD context. Few native English speakers I know will be
> immediately sure of the meaning, it's too obscure.
As another Briton this surprises me:
The word "deprecate" has a clear and specific meaning in all
computing, especially in standards, release notes and documentation.
It is from latin and is the same base word in all romance languages.
It is definitely in common usage in the UK, I would not hesitate to
use it any conversation with anyone and expect them to understand its
meaning.
To my ear there is no clearer word to use for this purpose.
Cheers
Tom
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 18:53:02 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 30863A64;
Thu, 6 Feb 2014 18:53:02 +0000 (UTC)
Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id EC4A5187B;
Thu, 6 Feb 2014 18:53:01 +0000 (UTC)
Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net
[86.27.189.65]) (authenticated bits=0)
by theravensnest.org (8.14.7/8.14.5) with ESMTP id s16IqnQB070545
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Thu, 6 Feb 2014 18:52:51 GMT (envelope-from theraven@FreeBSD.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
From: David Chisnall <theraven@FreeBSD.org>
In-Reply-To: <201402061834.s16IYgDK044802@fire.js.berklix.net>
Date: Thu, 6 Feb 2014 18:52:43 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <E18F3A8E-C7F1-4DDB-BE4D-17CE869619B6@FreeBSD.org>
References: <201402061834.s16IYgDK044802@fire.js.berklix.net>
To: "Julian H. Stacey" <jhs@berklix.com>
X-Mailer: Apple Mail (2.1822)
Cc: pyunyh@gmail.com, stable@freebsd.org,
"current@freebsd.org Current" <current@freebsd.org>,
Christian Brueffer <brueffer@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 18:53:02 -0000
On 6 Feb 2014, at 18:34, Julian H. Stacey <jhs@berklix.com> wrote:
> Best avoid the obscure word `Deprecated' in manuals:
> It's not common/ plain English. Maybe a geek import, or USA
> dialect ? It's not easily internationaly understood English.
> Best make manuals easier for non native English speakers (& native
> English too ;-). I am British born & bred, whether in English
> speaking circles in UK or Germany I never hear or read 'deprecated'
> unless its in BSD context. Few native English speakers I know will =
be
> immediately sure of the meaning, it's too obscure.
I'd strongly disagree with this. Deprecated is, perhaps, only in common =
use as jargon, but it's very widespread within the tech field. I don't =
think I've ever read an API reference that doesn't include the word, for =
example, and it's even a keyword in many code documentation tools. For =
example, JavaDoc supports @deprecated and gcc / clang include an =
__attribute__((deprecated)) that generates a compile-time warning =
whenever anyone tries to call a deprecated function. =20
I've not come across the word outside of tech uses, but I've also not =
come across the term network interface outside of tech circles. =
Deprecated, in this use, may be jargon, but it's very widespread jargon, =
and requesting it not be used sounds like asking for words like driver =
or processor also be avoided.
David
(Also a native English speaker, although familiar with the unofficial =
fork from Leftpondia)=
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 19:39:45 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 3A0B61C2
for <current@freebsd.org>; Thu, 6 Feb 2014 19:39:45 +0000 (UTC)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 131E61C87
for <current@freebsd.org>; Thu, 6 Feb 2014 19:39:45 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id 143CDB926
for <current@freebsd.org>; Thu, 6 Feb 2014 14:39:44 -0500 (EST)
From: John Baldwin <jhb@freebsd.org>
To: current@freebsd.org
Subject: [PATCH] PCI bus number management
Date: Thu, 6 Feb 2014 14:37:53 -0500
User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; )
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201402061437.53355.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
(bigwig.baldwin.cx); Thu, 06 Feb 2014 14:39:44 -0500 (EST)
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 19:39:45 -0000
I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage
PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O
windows for briges. Each bridge creates an rman to manage the bus numbers for
all buses and bridges that live below it. Each bus allocates a bus resource
from its parent bridge, and child bridges allocate their ranges from their
parent devices. At the "top" of the PCI tree, the Host-PCI bridges allocate
their respective bus ranges from their PCI domain/segment. There isn't really
a device node for PCI domains, so I created a helper API that basically auto-
creates a PCI bus rman for each domain on first use and then sub-allocates
from that for Host-PCI bridges.
The current patch (with some extra debugging) is at
http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
I would like to commit this to HEAD soon but thought I would post it for some
pre-commit testing for the brave. :) If you are really brave, try booting
with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses
in the system. If you are really, really brave, try booting with
'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My
laptop survives with all those set)
Note that the patch only enables bus number management on amd64 and i386. I
believe ia64 just needs to define PCI_RES_BUS for this to work since it
mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS
rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(),
and bus_release_resource().
--
John Baldwin
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 19:47:10 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id BCDAE423;
Thu, 6 Feb 2014 19:47:10 +0000 (UTC)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com
[IPv6:2607:f8b0:400c:c01::22b])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 5F9521D3C;
Thu, 6 Feb 2014 19:47:10 +0000 (UTC)
Received: by mail-ve0-f171.google.com with SMTP id pa12so1904932veb.16
for <multiple recipients>; Thu, 06 Feb 2014 11:47:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=nFEIo8s3qI9tyQVsfxfzZGdfECpuSDpDs3NFgb4+OMQ=;
b=MJ0c2BL8tIJ5Xm7D64yUYTDiDpKhpyRc9TC0wqtBUQ9571irX9RIaXFNNyl48jDaim
4E3A5Y+G068cf7eCVawH34IGmIXP/t3MQ2jhgllBaEp6Fj5+BJg2oMhpiwmYI6xW8PfY
oJ//rMIp8Lu6rBWw/nplSMvsS1aww9CaEXQ66Vq2an9JigmgaRUvDANJvMVr25hxZiyt
oDAT6nmoheXlaMkRvDLsWL8zHIGusgsPEK9KdPq2bEJiinoNXUcmpf8ruaLkjz9dOYJF
BB/EbgBjbjXBnKTAeyOeN1mdwExKeptoz3VM8bFolDGKrAEWTfl32w3E5CSboaZwYn2E
1irQ==
MIME-Version: 1.0
X-Received: by 10.58.37.232 with SMTP id b8mr2673762vek.27.1391716029361; Thu,
06 Feb 2014 11:47:09 -0800 (PST)
Received: by 10.220.168.135 with HTTP; Thu, 6 Feb 2014 11:47:09 -0800 (PST)
In-Reply-To: <201402061437.53355.jhb@freebsd.org>
References: <201402061437.53355.jhb@freebsd.org>
Date: Thu, 6 Feb 2014 14:47:09 -0500
Message-ID: <CAB7-odksA_N2smB-s+bWYGjNVU_c3CFRbJ3scBw94Dm-sSy5xQ@mail.gmail.com>
Subject: Re: [PATCH] PCI bus number management
From: Thomas Hoffmann <trh411@gmail.com>
To: current@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.17
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 19:47:10 -0000
On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin <jhb@freebsd.org> wrote:
> I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
> manage
> PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages
> I/O
> windows for briges. Each bridge creates an rman to manage the bus numbers
> for
> all buses and bridges that live below it. Each bus allocates a bus
> resource
> from its parent bridge, and child bridges allocate their ranges from their
> parent devices. At the "top" of the PCI tree, the Host-PCI bridges
> allocate
> their respective bus ranges from their PCI domain/segment. There isn't
> really
> a device node for PCI domains, so I created a helper API that basically
> auto-
> creates a PCI bus rman for each domain on first use and then sub-allocates
> from that for Host-PCI bridges.
>
> The current patch (with some extra debugging) is at
> http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
>
> I would like to commit this to HEAD soon but thought I would post it for
> some
> pre-commit testing for the brave. :) If you are really brave, try booting
> with 'hw.pci.clear_buses=1' which will force the kernel to renumber all
> buses
> in the system. If you are really, really brave, try booting with
> 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'.
> (My
> laptop survives with all those set)
>
> Note that the patch only enables bus number management on amd64 and i386.
> I
> believe ia64 just needs to define PCI_RES_BUS for this to work since it
> mandates ACPI. Porting this to other platforms requires handling
> PCI_RES_BUS
> rseources for Host-PCI bridges in bus_alloc_resource(),
> bus_adjust_resource(),
> and bus_release_resource().
>
> --
> John Baldwin
>
I get a "404 - Not Found" trying to follow the link.
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 19:54:06 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 94332A87;
Thu, 6 Feb 2014 19:54:06 +0000 (UTC)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com
[IPv6:2607:f8b0:400c:c03::235])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 388731DFE;
Thu, 6 Feb 2014 19:54:06 +0000 (UTC)
Received: by mail-vc0-f181.google.com with SMTP id ie18so1813453vcb.40
for <multiple recipients>; Thu, 06 Feb 2014 11:54:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=c7UnbTUKkGRNKTA3kyROU8N7URLcT2UxFy3fChwzXMw=;
b=QCw85RsV4r5kKRt31SsaaaBPPPYJqXFyz88aA20D2BvHCUf2rySx57PfFum7YDZCPP
ImOXPWSmtNZK3aWyISgBu37mWDqihkr8/bQ+UQaBevBC232bFd1c4p8YiAV1mRjODRvK
0KS2cyhFdiH+8ePQ3yJ6CNK4FAdg08lreN/T4yarSsfwxy5LKoekJ2dRXVLeoTvb0lPk
OV1ob/SdHhg7GUTSzvWpSYNyzIncKBH1Z5ztjJzhPMtSQPtyhwi8mg6K5Lg2p7WoHP8A
IplAnHEWvjER6cusJcuY03QX6MviSsqKP3yb/xkcK9DB2ZYs5z4E1v/nLpySlIYK3R/a
2goA==
MIME-Version: 1.0
X-Received: by 10.53.0.230 with SMTP id bb6mr1595372vdd.39.1391716445396; Thu,
06 Feb 2014 11:54:05 -0800 (PST)
Received: by 10.220.168.135 with HTTP; Thu, 6 Feb 2014 11:54:05 -0800 (PST)
In-Reply-To: <CAB7-odksA_N2smB-s+bWYGjNVU_c3CFRbJ3scBw94Dm-sSy5xQ@mail.gmail.com>
References: <201402061437.53355.jhb@freebsd.org>
<CAB7-odksA_N2smB-s+bWYGjNVU_c3CFRbJ3scBw94Dm-sSy5xQ@mail.gmail.com>
Date: Thu, 6 Feb 2014 14:54:05 -0500
Message-ID: <CAB7-odk2U_5zUhoGqiQYvn6Yrd_+cQKy053qeONEeNHtbQ0jHQ@mail.gmail.com>
Subject: Re: [PATCH] PCI bus number management
From: Thomas Hoffmann <trh411@gmail.com>
To: current@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.17
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 19:54:06 -0000
On Thu, Feb 6, 2014 at 2:47 PM, Thomas Hoffmann <trh411@gmail.com> wrote:
> On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin <jhb@freebsd.org> wrote:
>
>> I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
>> manage
>> PCI bus numbers. The approach is somewhat similar to how NEW_PCIB
>> manages I/O
>> windows for briges. Each bridge creates an rman to manage the bus
>> numbers for
>> all buses and bridges that live below it. Each bus allocates a bus
>> resource
>> from its parent bridge, and child bridges allocate their ranges from their
>> parent devices. At the "top" of the PCI tree, the Host-PCI bridges
>> allocate
>> their respective bus ranges from their PCI domain/segment. There isn't
>> really
>> a device node for PCI domains, so I created a helper API that basically
>> auto-
>> creates a PCI bus rman for each domain on first use and then sub-allocates
>> from that for Host-PCI bridges.
>>
>> The current patch (with some extra debugging) is at
>> http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
>>
>> I would like to commit this to HEAD soon but thought I would post it for
>> some
>> pre-commit testing for the brave. :) If you are really brave, try booting
>> with 'hw.pci.clear_buses=1' which will force the kernel to renumber all
>> buses
>> in the system. If you are really, really brave, try booting with
>> 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'.
>> (My
>> laptop survives with all those set)
>>
>> Note that the patch only enables bus number management on amd64 and i386.
>> I
>> believe ia64 just needs to define PCI_RES_BUS for this to work since it
>> mandates ACPI. Porting this to other platforms requires handling
>> PCI_RES_BUS
>> rseources for Host-PCI bridges in bus_alloc_resource(),
>> bus_adjust_resource(),
>> and bus_release_resource().
>>
>> --
>> John Baldwin
>>
>
> I get a "404 - Not Found" trying to follow the link.
>
Got it by backing up one level on the link and selecting form the list.
From owner-freebsd-current@FreeBSD.ORG Thu Feb 6 22:39:12 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 11BC23AE
for <current@freebsd.org>; Thu, 6 Feb 2014 22:39:12 +0000 (UTC)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id DB0781CAC
for <current@freebsd.org>; Thu, 6 Feb 2014 22:39:11 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id C50C3B93B;
Thu, 6 Feb 2014 17:39:10 -0500 (EST)
From: John Baldwin <jhb@freebsd.org>
To: Thomas Hoffmann <trh411@gmail.com>
Subject: Re: [PATCH] PCI bus number management
Date: Thu, 6 Feb 2014 16:43:37 -0500
User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; )
References: <201402061437.53355.jhb@freebsd.org>
<CAB7-odksA_N2smB-s+bWYGjNVU_c3CFRbJ3scBw94Dm-sSy5xQ@mail.gmail.com>
In-Reply-To: <CAB7-odksA_N2smB-s+bWYGjNVU_c3CFRbJ3scBw94Dm-sSy5xQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201402061643.37058.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
(bigwig.baldwin.cx); Thu, 06 Feb 2014 17:39:10 -0500 (EST)
Cc: current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 22:39:12 -0000
On Thursday, February 06, 2014 2:47:09 pm Thomas Hoffmann wrote:
> On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin <jhb@freebsd.org> wrote:
>
> > I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
> > manage
> > PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages
> > I/O
> > windows for briges. Each bridge creates an rman to manage the bus numbers
> > for
> > all buses and bridges that live below it. Each bus allocates a bus
> > resource
> > from its parent bridge, and child bridges allocate their ranges from their
> > parent devices. At the "top" of the PCI tree, the Host-PCI bridges
> > allocate
> > their respective bus ranges from their PCI domain/segment. There isn't
> > really
> > a device node for PCI domains, so I created a helper API that basically
> > auto-
> > creates a PCI bus rman for each domain on first use and then sub-allocates
> > from that for Host-PCI bridges.
> >
> > The current patch (with some extra debugging) is at
> > http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
> >
> > I would like to commit this to HEAD soon but thought I would post it for
> > some
> > pre-commit testing for the brave. :) If you are really brave, try booting
> > with 'hw.pci.clear_buses=1' which will force the kernel to renumber all
> > buses
> > in the system. If you are really, really brave, try booting with
> > 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'.
> > (My
> > laptop survives with all those set)
> >
> > Note that the patch only enables bus number management on amd64 and i386.
> > I
> > believe ia64 just needs to define PCI_RES_BUS for this to work since it
> > mandates ACPI. Porting this to other platforms requires handling
> > PCI_RES_BUS
> > rseources for Host-PCI bridges in bus_alloc_resource(),
> > bus_adjust_resource(),
> > and bus_release_resource().
> >
> > --
> > John Baldwin
> >
>
> I get a "404 - Not Found" trying to follow the link.
Oops, it is:
http://people.freebsd.org/~jhb/patches/pci_bus_rman3.patch
--
John Baldwin
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 02:10:08 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 8C355E9
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 02:10:08 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 472FC1DFB
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 02:10:08 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <freebsd-current@m.gmane.org>) id 1WBatH-0000fC-6A
for freebsd-current@freebsd.org; Fri, 07 Feb 2014 03:10:03 +0100
Received: from 97.96.39.205 ([97.96.39.205])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-current@freebsd.org>; Fri, 07 Feb 2014 03:10:03 +0100
Received: from dpejesh by 97.96.39.205 with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-current@freebsd.org>; Fri, 07 Feb 2014 03:10:03 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-current@freebsd.org
From: David Shane Holden <dpejesh@yahoo.com>
Subject: Re: [PATCH] PCI bus number management
Date: Thu, 06 Feb 2014 20:58:42 -0500
Lines: 49
Message-ID: <ld1ekh$4pe$1@ger.gmane.org>
References: <201402061437.53355.jhb@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 97.96.39.205
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To: <201402061437.53355.jhb@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 02:10:08 -0000
On 02/06/14 14:37, John Baldwin wrote:
> I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
> manage PCI bus numbers. The approach is somewhat similar to how
> NEW_PCIB manages I/O windows for briges. Each bridge creates an rman
> to manage the bus numbers for all buses and bridges that live below
> it. Each bus allocates a bus resource from its parent bridge, and
> child bridges allocate their ranges from their parent devices. At the
> "top" of the PCI tree, the Host-PCI bridges allocate their respective
> bus ranges from their PCI domain/segment. There isn't really a
> device node for PCI domains, so I created a helper API that basically
> auto- creates a PCI bus rman for each domain on first use and then
> sub-allocates from that for Host-PCI bridges.
>
> The current patch (with some extra debugging) is at
> http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
>
> I would like to commit this to HEAD soon but thought I would post it
> for some pre-commit testing for the brave. :) If you are really
> brave, try booting with 'hw.pci.clear_buses=1' which will force the
> kernel to renumber all buses in the system. If you are really,
> really brave, try booting with 'hw.pci.clear_bars=1',
> 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop
> survives with all those set)
>
> Note that the patch only enables bus number management on amd64 and
> i386. I believe ia64 just needs to define PCI_RES_BUS for this to
> work since it mandates ACPI. Porting this to other platforms
> requires handling PCI_RES_BUS rseources for Host-PCI bridges in
> bus_alloc_resource(), bus_adjust_resource(), and
> bus_release_resource().
>
Setting all 3 on an Atom D510MO works fine. On a Lenovo W520 though
hw.pci.clear_bars=1 causes a lockup during boot. The last few lines
with a normal boot are:
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pcib0: decoding 5 range 0-0xfe
pci0: <ACPI PCI bus> on pcib0
secbus=1, subbus=1
pci0:0:1:0: allocated initial secbus range
While a verbose boot produces:
pcib0: allocated type 3 (0xc0000400-0xc00007ff) for rid 10 of pci:0:0:26:0
pcib0: matched entry for 0x26.INTA
pcib0: slot 26 INTA hardwired to IRQ 26
And it ends there. Setting the other 2 are fine though.
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 03:19:11 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id B2BC5EB5;
Fri, 7 Feb 2014 03:19:11 +0000 (UTC)
Received: from land.berklix.org (land.berklix.org [144.76.10.75])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 4E0281764;
Fri, 7 Feb 2014 03:19:10 +0000 (UTC)
Received: from park.js.berklix.net (pD9FBF118.dip0.t-ipconnect.de
[217.251.241.24]) (authenticated bits=128)
by land.berklix.org (8.14.5/8.14.5) with ESMTP id s173Idwf040295;
Fri, 7 Feb 2014 03:18:40 GMT (envelope-from jhs@berklix.com)
Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41])
by park.js.berklix.net (8.14.3/8.14.3) with ESMTP id s173J4Z2099587;
Fri, 7 Feb 2014 04:19:04 +0100 (CET) (envelope-from jhs@berklix.com)
Received: from fire.js.berklix.net (localhost [127.0.0.1])
by fire.js.berklix.net (8.14.5/8.14.5) with ESMTP id s173Ijvb048532;
Fri, 7 Feb 2014 04:18:57 +0100 (CET) (envelope-from jhs@berklix.com)
Message-Id: <201402070318.s173Ijvb048532@fire.js.berklix.net>
To: stable@freebsd.org, current@freebsd.org
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
From: "Julian H. Stacey" <jhs@berklix.com>
Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany
User-agent: EXMH on FreeBSD http://berklix.com/free/
X-URL: http://www.berklix.com
In-reply-to: Your message "Thu, 06 Feb 2014 18:52:43 GMT."
<E18F3A8E-C7F1-4DDB-BE4D-17CE869619B6@FreeBSD.org>
Date: Fri, 07 Feb 2014 04:18:45 +0100
Cc: pyunyh@gmail.com, David Chisnall <theraven@freebsd.org>,
Christian Brueffer <brueffer@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 03:19:11 -0000
Hi, Reference:
> From: David Chisnall <theraven@freebsd.org>
> Date: Thu, 6 Feb 2014 18:52:43 +0000
David Chisnall wrote:
> On 6 Feb 2014, at 18:34, Julian H. Stacey <jhs@berklix.com> wrote:
>
> > Best avoid the obscure word `Deprecated' in manuals:
> > It's not common/ plain English. Maybe a geek import, or USA
> > dialect ? It's not easily internationaly understood English.
> > Best make manuals easier for non native English speakers (& native
> > English too ;-). I am British born & bred, whether in English
> > speaking circles in UK or Germany I never hear or read 'deprecated'
> > unless its in BSD context. Few native English speakers I know will be
> > immediately sure of the meaning, it's too obscure.
>
> I'd strongly disagree with this. Deprecated is, perhaps, only in common use as jargon, but it's very widespread within the tech field. I don't think I've ever read an API reference that doesn't include the word, for example, and it's even a keyword in many code documentation tools. For example, JavaDoc supports @deprecated and gcc / clang include an __attribute__((deprecated)) that generates a compile-time warning whenever anyone tries to call a deprecated function.
>
> I've not come across the word outside of tech uses, but I've also not come across the term network interface outside of tech circles. Deprecated, in this use, may be jargon, but it's very widespread jargon, and requesting it not be used sounds like asking for words like driver or processor also be avoided.
>
> David
> (Also a native English speaker, although familiar with the unofficial fork from Leftpondia)
Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia
American 1620 fork of English deduced.
1620: When a Mayflower butter maid Deprecated a milk maid giving 20 ounces
to a pint, & confused USA liquids down to 16 ounces. (Beware man units).
Amerian is not always best international English. It's a big early
variant of English, but other native English speakers round the
globe well outnumber American I believe. (Start with a map of the
Commonwealth), & many 2nd language people too will help define
international English, (as José Manuel Barroso, EU commission
president, said), not just natives, eg British or Americans etc,
will get to shape international English.
Americans often seem to find it harder to grasp what's internationaly
portable English, as opposed to American, perhaps because a large
country makes a higher percentage of language experience internal
national usage.
FreeBSD's manual writers, especially non native English manual
writers, should not copy Americanisms &/or bad nomenclature from
one manual to another, but ask themselves if they know better words,
to make it easier also for other non native English to read. eg
Deprecated is not common English.
PS Light relief: http://www.bbc.com/future/story/20140206-can-drones-be-hacked
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
Interleave replies below like a play script. Indent old text with "> ".
Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 05:00:45 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 84EB6770
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 05:00:45 +0000 (UTC)
Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net
[142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 596491FB4
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 05:00:44 +0000 (UTC)
Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73])
(Authenticated sender: allan.jude@scaleengine.com)
by mx1.scaleengine.net (Postfix) with ESMTPSA id 84E585A584
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 05:00:36 +0000 (UTC)
Message-ID: <52F46877.8020504@allanjude.com>
Date: Fri, 07 Feb 2014 00:00:39 -0500
From: Allan Jude <freebsd@allanjude.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from
11-CURRENT
References: <201402070318.s173Ijvb048532@fire.js.berklix.net>
In-Reply-To: <201402070318.s173Ijvb048532@fire.js.berklix.net>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="eMcxplvG1vijLvOeqU3l76FDhEmXC5ou6"
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 05:00:45 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eMcxplvG1vijLvOeqU3l76FDhEmXC5ou6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 2014-02-06 22:18, Julian H. Stacey wrote:
> Hi, Reference:
>> From: David Chisnall <theraven@freebsd.org>
>> Date: Thu, 6 Feb 2014 18:52:43 +0000
>=20
> David Chisnall wrote:
>> On 6 Feb 2014, at 18:34, Julian H. Stacey <jhs@berklix.com> wrote:
>>
>>> Best avoid the obscure word `Deprecated' in manuals:
>>> It's not common/ plain English. Maybe a geek import, or USA
>>> dialect ? It's not easily internationaly understood English.
>>> Best make manuals easier for non native English speakers (& native
>>> English too ;-). I am British born & bred, whether in English
>>> speaking circles in UK or Germany I never hear or read 'deprecated'
>>> unless its in BSD context. Few native English speakers I know will =
be
>>> immediately sure of the meaning, it's too obscure.
>>
>> I'd strongly disagree with this. Deprecated is, perhaps, only in comm=
on use as jargon, but it's very widespread within the tech field. I don'=
t think I've ever read an API reference that doesn't include the word, fo=
r example, and it's even a keyword in many code documentation tools. For=
example, JavaDoc supports @deprecated and gcc / clang include an __attri=
bute__((deprecated)) that generates a compile-time warning whenever anyon=
e tries to call a deprecated function. =20
>>
>> I've not come across the word outside of tech uses, but I've also not =
come across the term network interface outside of tech circles. Deprecat=
ed, in this use, may be jargon, but it's very widespread jargon, and requ=
esting it not be used sounds like asking for words like driver or process=
or also be avoided.
>>
>> David
>> (Also a native English speaker, although familiar with the unofficial =
fork from Leftpondia)
>=20
> Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia
> American 1620 fork of English deduced.
> 1620: When a Mayflower butter maid Deprecated a milk maid giving 20 o=
unces
> to a pint, & confused USA liquids down to 16 ounces. (Beware man uni=
ts).
>=20
> Amerian is not always best international English. It's a big early
> variant of English, but other native English speakers round the
> globe well outnumber American I believe. (Start with a map of the
> Commonwealth), & many 2nd language people too will help define
> international English, (as Jos=E9 Manuel Barroso, EU commission
> president, said), not just natives, eg British or Americans etc,
> will get to shape international English.
>=20
> Americans often seem to find it harder to grasp what's internationaly
> portable English, as opposed to American, perhaps because a large
> country makes a higher percentage of language experience internal
> national usage.
>=20
> FreeBSD's manual writers, especially non native English manual
> writers, should not copy Americanisms &/or bad nomenclature from
> one manual to another, but ask themselves if they know better words,
> to make it easier also for other non native English to read. eg
> Deprecated is not common English.
>=20
> PS Light relief: http://www.bbc.com/future/story/20140206-can-drones-be=
-hacked
>=20
> Cheers,
> Julian
>=20
>=20
>=20
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o=
rg"
>=20
The problem with 'deprecated' is that it often means 'this is no longer
the suggested way to do it', not necessarily 'this method of doing it
will soon cease working'.
For example, in /etc/rc.conf ifconfig_em0_aliasX is deprecated
But it still works, and as far as I am aware, there are no plans to stop
supporting it, it is just 'recommended', that you use ipv4_addrs_em0
I think the word deprecated is fine, but it should also be made clear
that nve is going away and that you should switch to nfe immediately.
--=20
Allan Jude
--eMcxplvG1vijLvOeqU3l76FDhEmXC5ou6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS9Gh6AAoJEJrBFpNRJZKfiWYQAJbBZdbFwgKa6U1slTNWnBOs
Q3flC4cYlq1BYEOb2RSye35ETBbyz2oUrqcZ2ey7/xzQ0rmjGLjBj7kWz5MIxFDN
TWKN8+6KIbmzj2894QciDh7mAOJKHCGi2o2+IJUo3jP1dVTHj0iwTp5sUipwBzpY
KEXNESN73pGfbnkxtOk+cOxROkHRkH5mQe3WHOjvVkeJa09di/5CFVAqaA6WKLVd
Vo9L1Hl1/GjzEExs+H3J3aPvvm1c92iyPsgM8RckBt+2I48a8HOpgesJSzZ8NVMV
eNQapGeGsZv07dlIf4TxtbhWbHm/wLs+tGoODYUauHdJSjRRMFaqCwR5/bS4w+Bw
Npc1wN2KkztX+vaS07as4rpt4to9Dg3cX65o6tK8Sf9DRtXcE8A4a2zvf5g6gkno
feSJAJXvk19pFfX4CXNNuefSR+Ka+55Q/sfJYepKMECLG+IL/t9obqDZETvs3t66
RjFYsC+51ET7PjhtmNpDpBXdmLNkPdXcj8uV8RPk+Focvi2mSDH7rAI7hQ5s6Ank
H90xiUT7d3NblWmSy6al4ra9+lgY5azNSNHbz9RGEYTsq6wpz48tyDearE0l9OAz
+vc5ttK8ncex9fvX214RWtIA0IEUIMbtxxNpPn6iKttL5+6p316gYDG+n5NNOeRM
9P0XjnrduYTQs2R6PH2v
=uwJT
-----END PGP SIGNATURE-----
--eMcxplvG1vijLvOeqU3l76FDhEmXC5ou6--
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 08:29:03 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 9FF17691;
Fri, 7 Feb 2014 08:29:03 +0000 (UTC)
Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202])
by mx1.freebsd.org (Postfix) with ESMTP id 56C63105C;
Fri, 7 Feb 2014 08:29:03 +0000 (UTC)
Received: from mail.lockless.no (mail.lockless.no [46.29.221.38])
by mta05.bitpro.no (Postfix) with ESMTPS id 6D3AA17FC36;
Fri, 7 Feb 2014 09:28:59 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by mail.lockless.no (Postfix) with ESMTP id 193FC161168;
Fri, 7 Feb 2014 09:29:54 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no
Received: from mail.lockless.no ([127.0.0.1])
by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kyvTYpiCGSup; Fri, 7 Feb 2014 09:29:52 +0100 (CET)
Received: from laptop015.home.selasky.org
(cm-176.74.213.204.customer.telag.net [176.74.213.204])
by mail.lockless.no (Postfix) with ESMTPSA id 8658B161167;
Fri, 7 Feb 2014 09:29:52 +0100 (CET)
Message-ID: <52F49986.4050702@bitfrost.no>
Date: Fri, 07 Feb 2014 09:29:58 +0100
From: Hans Petter Selasky <hps@bitfrost.no>
Organization: Bitfrost A/S
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: FreeBSD Stable <freebsd-stable@freebsd.org>,
FreeBSD Current <freebsd-current@freebsd.org>,
freebsd-questions@freebsd.org,
"freebsd-usb@FreeBSD.org" <freebsd-usb@FreeBSD.org>
Subject: [HEADS UP] MacBooks and Apple Trackpads
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 08:29:03 -0000
Hi,
A new driver for the Apple Trackpad named "wsp" has been committed and
MFC'ed to 9-stable and 10-stable from -current.
The trackpad will appear non-working in X.org until HAL is recompiled
with support for "wsp" devices. This happens when I MFC "etc/usb.conf"
to 9-stable and 10-stable which then automatically loads the "wsp"
kernel module when "devd" is started. This has not yet been done.
As an alternative workaround:
rm /boot/kernel/wsp.ko
kldunload wsp
Thank you for the attention!
--HPS
Reference: http://www.freshports.org/sysutils/hal/
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 09:12:58 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 0917BD09
for <freebsd-current@FreeBSD.org>; Fri, 7 Feb 2014 09:12:58 +0000 (UTC)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
by mx1.freebsd.org (Postfix) with ESMTP id 4DC821465
for <freebsd-current@FreeBSD.org>; Fri, 7 Feb 2014 09:12:56 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
[212.40.38.100])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA14913;
Fri, 07 Feb 2014 11:12:55 +0200 (EET) (envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
id 1WBhUU-000Hye-OA; Fri, 07 Feb 2014 11:12:54 +0200
Message-ID: <52F4A35E.1080902@FreeBSD.org>
Date: Fri, 07 Feb 2014 11:11:58 +0200
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Vitalij Satanivskij <satan@ukr.net>
Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted
to text/plain)
References: <52D66DB6.7030807@FreeBSD.org>
<1390900795.258244476.v35k1338@frv45.ukr.net> <52EA3459.3070300@FreeBSD.org>
<1391083826.948700370.cmzf8475@frv45.ukr.net>
<20140131182637.GA82526@hell.ukr.net> <20140204100823.GA95709@hell.ukr.net>
<52F0F687.6050307@FreeBSD.org> <20140204171040.GA82996@hell.ukr.net>
<52F12210.10604@FreeBSD.org> <20140205090449.GA9341@hell.ukr.net>
<20140205122241.GA38114@hell.ukr.net>
In-Reply-To: <20140205122241.GA38114@hell.ukr.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Vladimir Sharun <atz@ukr.net>,
Current FreeBSD <freebsd-current@FreeBSD.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 09:12:58 -0000
on 05/02/2014 14:22 Vitalij Satanivskij said the following:
> Dear Andriy and FreeBSD community,
>
> Ok. I'm get coredump on panic.
>
> What else i need to do?
Vitalij, Vladimir,
I have been able to reproduce the leak at work, so now I have full access to all
debugging information that I need. Thank you for your testing and reports.
I have reported my observations to OpenZFS developers. It looks like the author
of L2ARC compression code is too busy right now to produce a fix.
Unfortunately, I am not very familiar with the L2ARC code, so I can not promise
to produce a patch soon.
My recommendation would be to completely disable L2ARC _compression_ (not L2ARC
itself) on your production systems for time being.
The following patch should do that:
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
@@ -5080,20 +5080,22 @@ l2arc_write_buffers
* ab->b_buf may be invalid by now due to ARC eviction.
*/
l2hdr = ab->b_l2hdr;
l2hdr->b_daddr = dev->l2ad_hand;
+#if 0
if ((ab->b_flags & ARC_L2COMPRESS) &&
l2hdr->b_asize >= buf_compress_minsz) {
if (l2arc_compress_buf(l2hdr)) {
/*
* If compression succeeded, enable headroom
* boost on the next scan cycle.
*/
*headroom_boost = B_TRUE;
}
}
+#endif
/*
* Pick up the buffer data we had previously stashed away
* (and now potentially also compressed).
*/
--
Andriy Gapon
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 12:44:05 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 944A8712
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 12:44:05 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 49F371783
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 12:44:04 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <freebsd-current@m.gmane.org>) id 1WBkmn-0004Gh-Lg
for freebsd-current@freebsd.org; Fri, 07 Feb 2014 13:44:01 +0100
Received: from august.inf.tu-dresden.de ([141.76.48.124])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-current@freebsd.org>; Fri, 07 Feb 2014 13:44:01 +0100
Received: from jsteckli by august.inf.tu-dresden.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <freebsd-current@freebsd.org>; Fri, 07 Feb 2014 13:44:01 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-current@freebsd.org
From: Julian Stecklina <jsteckli@os.inf.tu-dresden.de>
Subject: Re: [PATCH] PCI bus number management
Date: Fri, 07 Feb 2014 13:43:51 +0100
Lines: 34
Message-ID: <ld2kdq$srr$1@ger.gmane.org>
References: <201402061437.53355.jhb@freebsd.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="w48EsOC4TJROBCR1URCeQPoBqBbOkFsw7"
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: august.inf.tu-dresden.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <201402061437.53355.jhb@freebsd.org>
X-Enigmail-Version: 1.7a1pre
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 12:44:05 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--w48EsOC4TJROBCR1URCeQPoBqBbOkFsw7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 02/06/2014 08:37 PM, John Baldwin wrote:
> I would like to commit this to HEAD soon but thought I would post it fo=
r some=20
> pre-commit testing for the brave. :) If you are really brave, try boot=
ing=20
> with 'hw.pci.clear_buses=3D1' which will force the kernel to renumber a=
ll buses=20
> in the system.
This is a really bad idea, because BIOS/SMM tends to have those
hardcoded. Or am I misunderstanding the purpose of this patch?
Julian
--w48EsOC4TJROBCR1URCeQPoBqBbOkFsw7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlL01QcACgkQ2EtjUdW3H9mcDwCgqd+nn247wW1QyXvFfajFeHP2
ZgwAoKYcp07KYm51Ad+brBGFWpsGmrpi
=yBcj
-----END PGP SIGNATURE-----
--w48EsOC4TJROBCR1URCeQPoBqBbOkFsw7--
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 14:27:10 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 68304C84;
Fri, 7 Feb 2014 14:27:10 +0000 (UTC)
Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 28E301281;
Fri, 7 Feb 2014 14:27:09 +0000 (UTC)
Received: by caravan.chchile.org (Postfix, from userid 1000)
id 7EFE1102659; Fri, 7 Feb 2014 14:17:14 +0000 (UTC)
Date: Fri, 7 Feb 2014 15:17:14 +0100
From: Jeremie Le Hen <jlh@FreeBSD.org>
To: Gleb Smirnoff <glebius@FreeBSD.org>, freebsd-current@FreeBSD.org
Subject: -CURRENT on VBox is broken (was: Re: buildworld fails with "Zero
byte read from file, skipping rest) of line"
Message-ID: <20140207141714.GA94833@caravan.chchile.org>
Mail-Followup-To: Gleb Smirnoff <glebius@FreeBSD.org>,
freebsd-current@FreeBSD.org
References: <20140114072620.GB83762@caravan.chchile.org>
<20140114085818.GQ8472@FreeBSD.org>
<20140115074053.GD83762@caravan.chchile.org>
<20140115084035.GC26504@glebius.int.ru>
<20140115113653.GE83762@caravan.chchile.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140115113653.GE83762@caravan.chchile.org>
User-Agent: Mutt/1.5.22 (2013-10-16)
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 14:27:10 -0000
On Wed, Jan 15, 2014 at 12:36:53PM +0100, Jeremie Le Hen wrote:
> On Wed, Jan 15, 2014 at 12:40:35PM +0400, Gleb Smirnoff wrote:
> > J> >
> > J> > Can you try to reproduce this with unmapped I/O turned off in boot loader?
> > J>
> > J> I've never heard of that. Can you please point me to the right
> > J> code/doc?
> >
> > In loader prompt:
> >
> > OK set vfs.unmapped_buf_allowed=0
> > OK boot
>
> No, unfortunately I still have the same problem without unmapped bufs.
Ok, I'm back to try to try building world on VirtualBox with a recent
-CURRENT.
So, on a new workstation, I've installed a new VirtualBox, downloaded
the latest i386 snapshot and installed it:
FreeBSD-11.0-CURRENT-i386-20140203-r261419-disc1.iso
Things started to be shady when I tried to build and install
ports-mgmt/pkg:
% install -s -o root -g wheel -m 555 pkg-static /usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static
% strip: /usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static: File format not recognized
So I tried to disallow VFS unmapped bufs as you advised me and this
seems to have solved the problem (but maybe by chance, see below).
Now I'm still running with vfs.unmapped_buf_allowed=0, I installed all
the ports I need for basic development. I fetched freebsd-src from
GitHub and tried to build world... And now it's started to be very
wacky: it failed, multiple times, but never at the same place (I removed
/usr/obj/* between each run).
There is at least something consistent, it always fails with the same
error ".../.depend: Zero byte read from file, skipping rest of line.":
% [jlh@freefall ~/www/wacky_buildworld_on_vbox]$ grep -B 1 -A 5 'warning: Zero byte read from file' *
% typescript.fail1.txt-TMP=_depend$$; sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po \1.So:/' < .depend > $TMP; mv $TMP .depend
% typescript.fail1.txt:make[4]: "/usr/obj/usr/src/kerberos5/lib/libheimbase/.depend" line 3: warning: Zero byte read from file, skipping rest of line.
% typescript.fail1.txt-make[4]: "/usr/obj/usr/src/kerberos5/lib/libheimbase/.depend" line 3: Need an operator
% typescript.fail1.txt-make[4]: "/usr/obj/usr/src/kerberos5/lib/libheimbase/.depend" line 4: Need an operator
% typescript.fail1.txt-make[4]: Fatal errors encountered -- cannot continue
% typescript.fail1.txt-make[4]: stopped in /usr/src/kerberos5/lib/libheimbase
% typescript.fail1.txt-*** Error code 1
% --
% typescript.fail2.txt-TMP=_depend$$; sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po \1.So:/' < .depend > $TMP; mv $TMP .depend
% typescript.fail2.txt:make[3]: "/usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend" line 3: warning: Zero byte read from file, skipping rest of line.
% typescript.fail2.txt-make[3]: "/usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend" line 3: Need an operator
% typescript.fail2.txt-make[3]: "/usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend" line 4: Need an operator
% typescript.fail2.txt-make[3]: Fatal errors encountered -- cannot continue
% typescript.fail2.txt-make[3]: stopped in /usr/src/kerberos5/lib/libvers
% typescript.fail2.txt-*** Error code 1
% --
% typescript.fail3.txt-echo libroken.so.11: /usr/obj/usr/src/tmp/usr/lib/libcrypt.a >> .depend
% typescript.fail3.txt:make[4]: "/usr/obj/usr/src/kerberos5/lib/libroken/.depend" line 3: warning: Zero byte read from file, skipping rest of line.
% typescript.fail3.txt-make[4]: "/usr/obj/usr/src/kerberos5/lib/libroken/.depend" line 3: Need an operator
% typescript.fail3.txt-make[4]: "/usr/obj/usr/src/kerberos5/lib/libroken/.depend" line 4: Unknown directive
% typescript.fail3.txt-make[4]: Fatal errors encountered -- cannot continue
% typescript.fail3.txt-make[4]: stopped in /usr/src/kerberos5/lib/libroken
% typescript.fail3.txt-*** Error code 1
% --
% typescript.fail4.txt-echo asn1_compile: /usr/lib/libc.a /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/../../lib/libroken/libroken.a /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/../../lib/libvers/libvers.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend
% typescript.fail4.txt:make[3]: "/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend" line 3: warning: Zero byte read from file, skipping rest of line.
% typescript.fail4.txt-make[3]: "/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend" line 3: Need an operator
% typescript.fail4.txt-make[3]: "/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend" line 4: Need an operator
% typescript.fail4.txt-make[3]: Fatal errors encountered -- cannot continue
% typescript.fail4.txt-make[3]: stopped in /usr/src/kerberos5/tools/asn1_compile
Any idea how to debug this?
--
Jeremie Le Hen
Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 14:36:41 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 2D9AD440
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 14:36:41 +0000 (UTC)
Received: from eu1sys200aog104.obsmtp.com (eu1sys200aog104.obsmtp.com
[207.126.144.117])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 7C8991343
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 14:36:40 +0000 (UTC)
Received: from mail-wi0-f174.google.com ([209.85.212.174]) (using TLSv1) by
eu1sys200aob104.postini.com ([207.126.147.11]) with SMTP
ID DSNKUvTvYl/Nn6vu4UBsQVN/9gX1Mfu6kEhy@postini.com;
Fri, 07 Feb 2014 14:36:40 UTC
Received: by mail-wi0-f174.google.com with SMTP id f8so897594wiw.7
for <freebsd-current@freebsd.org>; Fri, 07 Feb 2014 06:36:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to;
bh=0OqjRpJ2mdSxvtkMF+1CGR5CSvXbx5kinA6d7rlUPNk=;
b=AyacCO0g0yNOww1x6c8HpSamLlivJvLmNZXbKcwlaMvcNCwCU4tiKmwCNU3RyMdPRS
dyT38udy05kB2one47UcqY3oGSVqCcG5cHexdvPPZyzpj7CRAirpny55K+IQYCyoRqYF
X9sj8+RMUv0CBI8izbpW7T61RAs8P6R4cDscN8Lm8+Q/Y/A9aIqqnaMocLNJiPhz477h
/o1pg/yE5Ewi8lNMsKweIGNAbsLc/jHWKqMedDoC0idP7k22Qf/sdLnITYoYAKX8PHWX
wPjUeLZGfblS4SelocoC8TmvdfA92i2slyzK8tAyHfJUwkGI0+cAQ43N704q1BZC0grQ
UKmw==
X-Received: by 10.180.182.199 with SMTP id eg7mr3875214wic.13.1391780037666;
Fri, 07 Feb 2014 05:33:57 -0800 (PST)
X-Gm-Message-State: ALoCoQmgJiL9X9QKpc3g0YGnMhG19pZHi0l0ncKIrMq9hRgbHW3gMuS0CQJ5jIZ5kSBoKzBqyTGs6nNVUt5Cs3rfkEqsuGYAgzMrO3lfwN/u0BMX9A3t34AhsPvWaTF98Tgo6QfArp+f7KGUDaJqazd5yd3o1Zxu+PVVMEY1Fbl1Qy/zAZ4kxdY=
X-Received: by 10.180.182.199 with SMTP id eg7mr3875203wic.13.1391780037583;
Fri, 07 Feb 2014 05:33:57 -0800 (PST)
Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk.
[137.222.187.241])
by mx.google.com with ESMTPSA id j9sm10759489wjz.13.2014.02.07.05.33.55
for <freebsd-current@freebsd.org>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 07 Feb 2014 05:33:56 -0800 (PST)
Sender: Anton Shterenlikht <mexas@bristol.ac.uk>
Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1])
by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id s17DXsku069720
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 13:33:54 GMT
(envelope-from mexas@mech-cluster241.men.bris.ac.uk)
Received: (from mexas@localhost)
by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id s17DXs2D069719
for freebsd-current@freebsd.org; Fri, 7 Feb 2014 13:33:54 GMT
(envelope-from mexas)
Date: Fri, 07 Feb 2014 05:33:56 -0800 (PST)
From: Anton Shterenlikht <mexas@bris.ac.uk>
Message-Id: <201402071333.s17DXs2D069719@mech-cluster241.men.bris.ac.uk>
To: freebsd-current@freebsd.org
Subject: option PROCDESC is gone?
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mexas@bris.ac.uk
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 14:36:41 -0000
/usr/src/UPDATING:
20130905:
The PROCDESC kernel option is now part of the GENERIC kernel
configuration and is required for the rwhod(8) to work.
If you are using custom kernel configuration, you should include
'options PROCDESC'.
There is no later entry advising not to use it,
yet it seems to have gone from all generic kernels.
Please advise
Thanks
Anton
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 15:02:49 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id F1628923
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 15:02:48 +0000 (UTC)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com
[IPv6:2a00:1450:4010:c03::22f])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 715F716CE
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 15:02:48 +0000 (UTC)
Received: by mail-la0-f47.google.com with SMTP id hr17so2702945lab.20
for <freebsd-current@freebsd.org>; Fri, 07 Feb 2014 07:02:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=sender:date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=8Nnxny5LFwG46pLvnmbs3XSeK302y9LU7VN9LmY7B3I=;
b=XfLpZjJecM5XUdd4vVivc+TE4cD7DvIrHxKITwgEbP607ZKO/nxsheBx8uvJe0LanN
lZRq443Tm8Lfuy3+t2pkhgh80qJ4XlDqZd+6rIYUqh0hvMjXCsAo4z7JWH/EYIMDho2q
2zlNBwtPRw9YQP8h81EFDFGZyXUNC3dbsJAtJhlTmQN7E5P0/Kf1QAUO+8aktKq0NdO4
GA2CKr9Rct//hrHI04jS5KIbWk2sV5VGbtN9LQTaCwVEdzEYLVHVdcqGDm2jTXr3tYN1
2mHCbwNZVzvSfRozoELjUHGF/OhES0DqECPN/n0Tx18MClEEgSuv3BeovRwPvw5xcRSk
8mzA==
X-Received: by 10.112.99.74 with SMTP id eo10mr9787440lbb.15.1391785365960;
Fri, 07 Feb 2014 07:02:45 -0800 (PST)
Received: from omg (pluknet-1-pt.tunnel.tserv11.ams1.ipv6.he.net.
[2001:470:1f14:4d0::2])
by mx.google.com with ESMTPSA id mo3sm5137547lbb.17.2014.02.07.07.02.43
for <multiple recipients>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 07 Feb 2014 07:02:44 -0800 (PST)
Sender: Sergey Kandaurov <pluknet@gmail.com>
Date: Fri, 7 Feb 2014 19:02:40 +0400
From: Sergey Kandaurov <pluknet@freebsd.org>
To: Anton Shterenlikht <mexas@bris.ac.uk>
Subject: Re: option PROCDESC is gone?
Message-ID: <20140207150240.GA9090@omg>
References: <201402071333.s17DXs2D069719@mech-cluster241.men.bris.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh"
Content-Disposition: inline
In-Reply-To: <201402071333.s17DXs2D069719@mech-cluster241.men.bris.ac.uk>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: freebsd-current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 15:02:49 -0000
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 07, 2014 at 05:33:56AM -0800, Anton Shterenlikht wrote:
> /usr/src/UPDATING:
>=20
> 20130905:
> The PROCDESC kernel option is now part of the GENERIC kernel
> configuration and is required for the rwhod(8) to work.
> If you are using custom kernel configuration, you should include
> 'options PROCDESC'.
>=20
> There is no later entry advising not to use it,
> yet it seems to have gone from all generic kernels.
This options was removed in HEAD. This probably should be noted.
Index: UPDATING
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- UPDATING (revision 261596)
+++ UPDATING (working copy)
@@ -57,6 +57,10 @@
big-endian integer in accordance with RFC 4402.
__FreeBSD_version is bumped to 1100004.
=20
+20131130:
+ The PROCDESC kernel option has been removed. Its
+ functionality now turned on by default.
+
20131108:
The WITHOUT_ATF build knob has been removed and its functionality
has been subsumed into the more generic WITHOUT_TESTS. If you were
--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJS9PWQAAoJED9Ol7oQYHQZ0AMH/ROXYnK2UTyy7/kk0Bzc6q3C
wbRSMBKcmgg7SG8SXE4Wjauf6NoUdcIbg0EUCayzWg2Xcr4MxZcN+5GVd2Xc/v/a
MO8XLy6vThN61w3PcyZyZaQ3F4zx42Q3wDqq1izov5CJ/RurBDHUUSe2T6vcAUxJ
IXVCyhfdupJG5Od6ar80OLf6DTJbteSPw3i5J9eAwRlOzE6MRA9+ZlaonRBuqtPe
T8r3QqfXue0lMcK68I7TUh3S2+iwO6NJ/gK8RFLAXMbzpwSQOOIcNNRoB7yAsnon
QvuKedbBmjZXwLSXRLv74BhUJrTUMRW48qkF3BcziBaSEMx6J5NRBRIoBJVR5R4=
=aaVS
-----END PGP SIGNATURE-----
--jI8keyz6grp/JLjh--
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 15:57:37 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 965DAEBB
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 15:57:37 +0000 (UTC)
Received: from nm14.bullet.mail.ne1.yahoo.com (nm14.bullet.mail.ne1.yahoo.com
[98.138.90.77])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 474B71BEA
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 15:57:36 +0000 (UTC)
Received: from [98.138.100.115] by nm14.bullet.mail.ne1.yahoo.com with NNFMP;
07 Feb 2014 15:57:30 -0000
Received: from [98.138.226.126] by tm106.bullet.mail.ne1.yahoo.com with NNFMP;
07 Feb 2014 15:57:30 -0000
Received: from [127.0.0.1] by smtp205.mail.ne1.yahoo.com with NNFMP;
07 Feb 2014 15:57:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
t=1391788650; bh=xQtwmhB7EPKJ4JjXe7ZnsIZwvlbCsb/Dhlu6qMn973c=;
h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding;
b=rw2SPf3GflYKyOSzXOLmQwZVX9a0Ww+EMMSm1R8YKso7e07VUg9RD3gQneYOMzJnACaT0AddXz9tFfnLa4yltlSZXPv0LEI0/OT4P4Ghrjrxq8bmDrfMOBPZ34wwNGZwLQ85nQX2FVpnBDTUww+uL8nRL7C3sJoYX63QyGRGGdQ=
X-Yahoo-Newman-Id: 206758.83247.bm@smtp205.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 6z1F5nsVM1lJiOJC0olSD9mqeKH7FDwAJGetsQAHMkAZTzZ
anCqx.JMct_NMfbCGIuJKADW0yvse63rcu09aOHyAGcuzGOkxKgHOfYjElIU
rv0Q.iOf91s2URU9XKC36bWCDsdxKvbqzw.LYxpbKdQkWJfqX51uNJP0jfmK
ZVeyNOpj_ND4fFHzd5.i2xDbyyx5nEsU1G3Z03y3outdlY0TJbZSQKOPNqXX
fL2PDDQRo8qpb12LhQ5VPCYTrR5ZTGZ0YAYaKz6oncKTN.D5Ou0N7aPQcSBy
KNiPUnMUcINL7_Bp456nybx3dV_Z5X4urL96CpvXWrgU_hs.zngadyjPgY2I
AAj.J1eNIn1.vJ..rDLgMEiNDr5YwPDMnUs.84OwjcHUETUd0C6BHJWSnaQ7
GlYRNFdHcUu0gvJwzFusT2mq4C3ITMTzzqzCIfhv8RTzEkaLuWJV24qbr31w
SydI4B56XMxsjBB36sjYTlat9fpxqQbjZBnGWvswBlm24XuuRKHNAbYZkyZD
CgsZCtKLs2d5EPGhvHp0krQCL.qqfFeMTR1FFvoIpAgxKnz71ojPYF99xfSc
f323wJK4-
X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4-
X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with plain
[98.139.211.125])
by smtp205.mail.ne1.yahoo.com with SMTP; 07 Feb 2014 07:57:30 -0800 PST
Subject: Re: fonts and characters
From: Sean Bruno <sean_bruno@yahoo.com>
To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
In-Reply-To: <1391620002.1481.10.camel@powernoodle.corp.yahoo.com>
References: <1391614923.1481.3.camel@powernoodle.corp.yahoo.com>
<1391619779.1481.9.camel@powernoodle.corp.yahoo.com>
<1391620002.1481.10.camel@powernoodle.corp.yahoo.com>
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 07 Feb 2014 07:57:28 -0800
Message-ID: <1391788648.1472.1.camel@powernoodle.corp.yahoo.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: sbruno@freebsd.org
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 15:57:37 -0000
On Wed, 2014-02-05 at 09:06 -0800, Sean Bruno wrote:
> On Wed, 2014-02-05 at 09:02 -0800, Sean Bruno wrote:
> > On Wed, 2014-02-05 at 07:42 -0800, Sean Bruno wrote:
> > > I note that I have somehow failed to install or configure my system so
> > > that my terminal does not render characters outside of my alphabet at
> > > all.
> > >
> > > Typically, I run my IRC sessions in tmux inside a xfce-terminal, but I'm
> > > not sure how to get proper rendering of characters for other alphabets
> > > (cyrillic, kanji, etc). Is this a trivial mistake on my part or is
> > > something slightly more interesting going on?
> > >
> > > sean
> > >
> > > p.s. firefox renders other alphabets (for the most part) just fine.
> >
> > Huh ... setting LANG=en_US.UTF-8 totally fixes this. No idea why its
> > not set but default though.
> >
> > sean
> >
> > _______________________________________________
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
>
> Oh gross. Now the ncurses rendering in net-im/finch is screwed up. :-)
> More debugging required I guess.
>
> sean
>
> ___________
Full rebuild of all ports and everything is happy again.
1 question though, I see that LANG isn't set by default. Should I know
where to modify my system to set en_US.UTF-8 or is it supposed to have
that turned on by default?
sean
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 16:22:49 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 8A70E97B;
Fri, 7 Feb 2014 16:22:49 +0000 (UTC)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com
[IPv6:2a00:1450:4010:c04::233])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id D88D01E28;
Fri, 7 Feb 2014 16:22:48 +0000 (UTC)
Received: by mail-lb0-f179.google.com with SMTP id l4so2807004lbv.38
for <multiple recipients>; Fri, 07 Feb 2014 08:22:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=mj0qkhXBK8xoekkl+iXKaLhbVYmtk35wEWwJyTCkPEg=;
b=D7C3egJGjpV5SOqgIZSjxj3v7kX3zD/dEp5W8pyKl9c/jmJ+yY17jaGZ/zYk1plduT
QeYfW9wYeGuORWv/sSYrfZ6GHMg0moxK8vWL/IC14jcP20Dd+LUxCO0uYK4WPEdOavZZ
PObai2URNvnWfpygMC6UKcSVg0lwsJtgpwh+Z6JM8vga3Ds9upe68yaSflJchsK0rofH
CKFaVetoga+H/6u6cjfmNBiAGMJk0h+SpBvm9KuSsJn6238JjgVMANJch2IjZgh/iEZv
OIazjaVYlBwiGwAqkEjmGxeU/RYam7tupkeyhx8BA94lcbrqaJBqjStm+1m9cmOzkT8H
CoSg==
MIME-Version: 1.0
X-Received: by 10.152.205.197 with SMTP id li5mr1890982lac.50.1391790166749;
Fri, 07 Feb 2014 08:22:46 -0800 (PST)
Received: by 10.112.0.205 with HTTP; Fri, 7 Feb 2014 08:22:46 -0800 (PST)
In-Reply-To: <1391788648.1472.1.camel@powernoodle.corp.yahoo.com>
References: <1391614923.1481.3.camel@powernoodle.corp.yahoo.com>
<1391619779.1481.9.camel@powernoodle.corp.yahoo.com>
<1391620002.1481.10.camel@powernoodle.corp.yahoo.com>
<1391788648.1472.1.camel@powernoodle.corp.yahoo.com>
Date: Fri, 7 Feb 2014 16:22:46 +0000
Message-ID: <CAFHbX1+19TqOfh6=n-qkPvbsxGZCLLidZua2wZ-m7x2AsGAqJg@mail.gmail.com>
Subject: Re: fonts and characters
From: Tom Evans <tevans.uk@googlemail.com>
To: sbruno@freebsd.org
Content-Type: text/plain; charset=UTF-8
Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 16:22:49 -0000
On Fri, Feb 7, 2014 at 3:57 PM, Sean Bruno <sean_bruno@yahoo.com> wrote:
> 1 question though, I see that LANG isn't set by default. Should I know
> where to modify my system to set en_US.UTF-8 or is it supposed to have
> that turned on by default?
/etc/profile is where I set it on mine.
Cheers
Tom
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 18:04:43 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 77CE52C3;
Fri, 7 Feb 2014 18:04:43 +0000 (UTC)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com
[IPv6:2a00:1450:400c:c03::231])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 7343618C9;
Fri, 7 Feb 2014 18:04:42 +0000 (UTC)
Received: by mail-we0-f177.google.com with SMTP id t61so2473553wes.8
for <multiple recipients>; Fri, 07 Feb 2014 10:04:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:date:message-id:subject:from:to:content-type;
bh=EPpHZRIQns5b3v4l/FKGuYGgGk1Tzn3yj7YN5zKlXvc=;
b=mddps6Oy3IWm11exk4AusBBdLCZdM1ZxZ7Le87b8ozxtt0NpDTEvdc526oJKN4SqLu
yAS/CYc9cDWuKuEwBevZCRotDo9b1OUPh7THhnmKdQgKPl4XyVg19ZgqIKPHD8mfo6A9
U0ziuBP8W5MTyM285ataU9I/Et85IFTIFsiP/VKiP0NDCXzQ+VRCXSVe5ThhMKrhx0Ee
5VM8BFtTUYfFmoBatfkDTDbD+85DN9GdtE+ewLHYaRKZLiXRhGZxmPWnQPAanCPFFejV
0nMXkBNx7ZMRn/yPZhNpPuwYCxdWdQVRyrsT4IGYxcQbetl4pd+ltnrNet3rnNDSkgnr
R9kQ==
MIME-Version: 1.0
X-Received: by 10.194.63.228 with SMTP id j4mr11907621wjs.34.1391796280784;
Fri, 07 Feb 2014 10:04:40 -0800 (PST)
Sender: asomers@gmail.com
Received: by 10.194.168.197 with HTTP; Fri, 7 Feb 2014 10:04:40 -0800 (PST)
Date: Fri, 7 Feb 2014 11:04:40 -0700
X-Google-Sender-Auth: cZVPRDvroqnToXM8gnRB5I2H6nM
Message-ID: <CAOtMX2juj+=-bo0kznhLi01QxjVkdvJoT890q+BYhoKSpwpXng@mail.gmail.com>
Subject: contrib/libc++/include/locale contains -Wsign-compare errors
From: Alan Somers <asomers@freebsd.org>
To: FreeBSD CURRENT <freebsd-current@freebsd.org>,
"freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>,
theraven@freebsd.org,
Brooks Davis <brooks@freebsd.org>, Dimitry Andric <dim@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 18:04:43 -0000
contrib/libc++/include/locale compares integers of different signs.
With our CXXFLAG settings, this causes "WITH_TESTS=1 make buildworld"
to fail while compiling libatf-c++, as I mentioned in another thread.
I've now written a minimal test case. Just #include locale and
compile it with the right settings.
$ cat use_locale.cpp
#include <locale>
$ c++ -Wsystem-headers -Werror -Wsign-compare -Wno-unused-parameter
-Wno-c++11-extensions -c -o use_locale.o use_locale.cpp
In file included from use_locale.cpp:1:
/usr/include/c++/v1/locale:1016:27: error: comparison of integers of different
signs: 'long' and 'size_type' (aka 'unsigned long')
[-Werror,-Wsign-compare]
if (__a_end - __a == __buf.size())
~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
/usr/include/c++/v1/locale:1066:27: error: comparison of integers of different
signs: 'long' and 'size_type' (aka 'unsigned long')
[-Werror,-Wsign-compare]
if (__a_end - __a == __buf.size())
~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
/usr/include/c++/v1/locale:1120:27: error: comparison of integers of different
signs: 'long' and 'size_type' (aka 'unsigned long')
[-Werror,-Wsign-compare]
if (__a_end - __a == __buf.size())
~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
3 errors generated.
The below patch fixes the problem, but I don't have the confidence to
change the system C++ library myself. Can somebody please review it?
Index: contrib/libc++/include/locale
===================================================================
--- contrib/libc++/include/locale (revision 261283)
+++ contrib/libc++/include/locale (working copy)
@@ -1012,7 +1012,7 @@
unsigned __dc = 0;
for (; __b != __e; ++__b)
{
- if (__a_end - __a == __buf.size())
+ if ((size_t)(__a_end - __a) == __buf.size())
{
size_t __tmp = __buf.size();
__buf.resize(2*__buf.size());
@@ -1062,7 +1062,7 @@
unsigned __dc = 0;
for (; __b != __e; ++__b)
{
- if (__a_end - __a == __buf.size())
+ if ((size_t)(__a_end - __a) == __buf.size())
{
size_t __tmp = __buf.size();
__buf.resize(2*__buf.size());
@@ -1116,7 +1116,7 @@
char __exp = 'E';
for (; __b != __e; ++__b)
{
- if (__a_end - __a == __buf.size())
+ if ((size_t)(__a_end - __a) == __buf.size())
{
size_t __tmp = __buf.size();
__buf.resize(2*__buf.size());
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 20:47:35 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 6C41FA8A
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 20:47:35 +0000 (UTC)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 404A11726
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 20:47:35 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3F5DDB96B;
Fri, 7 Feb 2014 15:47:34 -0500 (EST)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-current@freebsd.org
Subject: Re: [PATCH] PCI bus number management
Date: Fri, 7 Feb 2014 15:27:41 -0500
User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; )
References: <201402061437.53355.jhb@freebsd.org> <ld2kdq$srr$1@ger.gmane.org>
In-Reply-To: <ld2kdq$srr$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201402071527.41452.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
(bigwig.baldwin.cx); Fri, 07 Feb 2014 15:47:34 -0500 (EST)
Cc: Julian Stecklina <jsteckli@os.inf.tu-dresden.de>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 20:47:35 -0000
On Friday, February 07, 2014 7:43:51 am Julian Stecklina wrote:
> On 02/06/2014 08:37 PM, John Baldwin wrote:
> > I would like to commit this to HEAD soon but thought I would post it for some
> > pre-commit testing for the brave. :) If you are really brave, try booting
> > with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses
> > in the system.
>
> This is a really bad idea, because BIOS/SMM tends to have those
> hardcoded. Or am I misunderstanding the purpose of this patch?
The BIOS just programs them initially. By default we use whatever the BIOS
programs and only rely on this infrastructure if we need to grow the tree
for some reason (e.g. hotplug). However, it is definitely valid for an OS
to reassign bus numbers as it sees fit.
--
John Baldwin
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 20:47:31 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 2FCBAA89
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 20:47:31 +0000 (UTC)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 07BBF1725
for <freebsd-current@freebsd.org>; Fri, 7 Feb 2014 20:47:31 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id EC134B941;
Fri, 7 Feb 2014 15:47:29 -0500 (EST)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-current@freebsd.org
Subject: Re: [PATCH] PCI bus number management
Date: Fri, 7 Feb 2014 15:26:10 -0500
User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; )
References: <201402061437.53355.jhb@freebsd.org> <ld1ekh$4pe$1@ger.gmane.org>
In-Reply-To: <ld1ekh$4pe$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201402071526.10129.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
(bigwig.baldwin.cx); Fri, 07 Feb 2014 15:47:30 -0500 (EST)
Cc: David Shane Holden <dpejesh@yahoo.com>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 20:47:31 -0000
On Thursday, February 06, 2014 8:58:42 pm David Shane Holden wrote:
> On 02/06/14 14:37, John Baldwin wrote:
> > I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
> > manage PCI bus numbers. The approach is somewhat similar to how
> > NEW_PCIB manages I/O windows for briges. Each bridge creates an rman
> > to manage the bus numbers for all buses and bridges that live below
> > it. Each bus allocates a bus resource from its parent bridge, and
> > child bridges allocate their ranges from their parent devices. At the
> > "top" of the PCI tree, the Host-PCI bridges allocate their respective
> > bus ranges from their PCI domain/segment. There isn't really a
> > device node for PCI domains, so I created a helper API that basically
> > auto- creates a PCI bus rman for each domain on first use and then
> > sub-allocates from that for Host-PCI bridges.
> >
> > The current patch (with some extra debugging) is at
> > http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
> >
> > I would like to commit this to HEAD soon but thought I would post it
> > for some pre-commit testing for the brave. :) If you are really
> > brave, try booting with 'hw.pci.clear_buses=1' which will force the
> > kernel to renumber all buses in the system. If you are really,
> > really brave, try booting with 'hw.pci.clear_bars=1',
> > 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop
> > survives with all those set)
> >
> > Note that the patch only enables bus number management on amd64 and
> > i386. I believe ia64 just needs to define PCI_RES_BUS for this to
> > work since it mandates ACPI. Porting this to other platforms
> > requires handling PCI_RES_BUS rseources for Host-PCI bridges in
> > bus_alloc_resource(), bus_adjust_resource(), and
> > bus_release_resource().
> >
>
> Setting all 3 on an Atom D510MO works fine. On a Lenovo W520 though
> hw.pci.clear_bars=1 causes a lockup during boot. The last few lines
> with a normal boot are:
>
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pcib0: decoding 5 range 0-0xfe
> pci0: <ACPI PCI bus> on pcib0
> secbus=1, subbus=1
> pci0:0:1:0: allocated initial secbus range
>
> While a verbose boot produces:
>
> pcib0: allocated type 3 (0xc0000400-0xc00007ff) for rid 10 of pci:0:0:26:0
> pcib0: matched entry for 0x26.INTA
> pcib0: slot 26 INTA hardwired to IRQ 26
>
> And it ends there. Setting the other 2 are fine though.
Ok, I think this may be a bit of a known issue in that some video cards
really don't like having their framebuffer disabled, even temporarily. Thanks
for testing!
--
John Baldwin
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 21:11:01 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 7418F2C0;
Fri, 7 Feb 2014 21:11:01 +0000 (UTC)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com
[IPv6:2607:f8b0:400c:c02::230])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 1C0F2191F;
Fri, 7 Feb 2014 21:11:01 +0000 (UTC)
Received: by mail-vb0-f48.google.com with SMTP id q16so3063621vbe.35
for <multiple recipients>; Fri, 07 Feb 2014 13:11:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=JRSRlWl+0cYqPTj9y4HBOO2C48HnTWUTdRVmoqgV6l0=;
b=0yo4xvIUzKYqr82qtrGcTQZPo9m9eQvjG52wipV/ITObu6gv4NS22zYeM9pKUwWSgy
+78pJUI2f8X6GSIJFeoQhuP8Zq8FQTB5Ul9uG4KkTx7JQCi8Sbgq0kjB/ML7m/J/opXA
rYe/P+iFgzntajqsg6WHuVNRIHtKYeygnKQAN6qXRkd7bJJUlz7ziER02U31DHjNFL1q
khDG3zObebeuLeSNnm+G56msLDHdFaNTctDGtOEJg5uxTaHv1vciQGoWxCDdKykeE87n
V6ykIpf331ZbAGnkJIl8krmNVhWYNzmdQhF51fKDvJKjDD7+v/BivKXeFm8ZYr7QUDoQ
hLQg==
MIME-Version: 1.0
X-Received: by 10.59.5.102 with SMTP id cl6mr834206ved.41.1391807460212; Fri,
07 Feb 2014 13:11:00 -0800 (PST)
Received: by 10.58.251.36 with HTTP; Fri, 7 Feb 2014 13:11:00 -0800 (PST)
In-Reply-To: <201402061437.53355.jhb@freebsd.org>
References: <201402061437.53355.jhb@freebsd.org>
Date: Fri, 7 Feb 2014 22:11:00 +0100
Message-ID: <CACyC=qbwXz1g5sP16bihsLCJ78t3ok4gNGUTrD2yJ-2+=NkqjQ@mail.gmail.com>
Subject: Re: [PATCH] PCI bus number management
From: "Ranjan1018 ." <214748mv@gmail.com>
To: John Baldwin <jhb@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.17
Cc: current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 21:11:01 -0000
Works fine setting all 3 on a Samsung ATIV BOOK 2 model NP270E5E-K02IT on
FreeBSD 11.0-CURRENT amd64 r261561 with NEWCONS.
Maurizio
From owner-freebsd-current@FreeBSD.ORG Fri Feb 7 21:19:54 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 416A268C;
Fri, 7 Feb 2014 21:19:54 +0000 (UTC)
Received: from tensor.andric.com (unknown
[IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id EB31C19E7;
Fri, 7 Feb 2014 21:19:53 +0000 (UTC)
Received: from [IPv6:2001:7b8:3a7::9502:12a8:3deb:47e] (unknown
[IPv6:2001:7b8:3a7:0:9502:12a8:3deb:47e])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by tensor.andric.com (Postfix) with ESMTPSA id 8D5AA5C44;
Fri, 7 Feb 2014 22:19:50 +0100 (CET)
Subject: Re: contrib/libc++/include/locale contains -Wsign-compare errors
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_F5EB2442-8888-41C9-8BD9-71FBEC52AE3D";
protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.1 (6062eb4)
From: Dimitry Andric <dim@FreeBSD.org>
In-Reply-To: <CAOtMX2juj+=-bo0kznhLi01QxjVkdvJoT890q+BYhoKSpwpXng@mail.gmail.com>
Date: Fri, 7 Feb 2014 22:19:41 +0100
Message-Id: <5FD73D01-F8E4-42F8-B5A6-67A6BD516A08@FreeBSD.org>
References: <CAOtMX2juj+=-bo0kznhLi01QxjVkdvJoT890q+BYhoKSpwpXng@mail.gmail.com>
To: Alan Somers <asomers@freebsd.org>
X-Mailer: Apple Mail (2.1827)
Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>,
FreeBSD CURRENT <freebsd-current@freebsd.org>, theraven@freebsd.org,
Brooks Davis <brooks@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 21:19:54 -0000
--Apple-Mail=_F5EB2442-8888-41C9-8BD9-71FBEC52AE3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On 07 Feb 2014, at 19:04, Alan Somers <asomers@freebsd.org> wrote:
...
> In file included from use_locale.cpp:1:
> /usr/include/c++/v1/locale:1016:27: error: comparison of integers of =
different
> signs: 'long' and 'size_type' (aka 'unsigned long')
> [-Werror,-Wsign-compare]
> if (__a_end - __a =3D=3D __buf.size())
> ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
Fixed in r261608 (in a somewhat cleaner way than r261604). It's also
going to be applied upstream.
-Dimitry
--Apple-Mail=_F5EB2442-8888-41C9-8BD9-71FBEC52AE3D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlL1Te0ACgkQsF6jCi4glqMwXwCgz796JqT8UBvbiTs8meGm02B8
gTwAoMOjPc15ucvhUUoeaP/O3XxCb/V3
=AlND
-----END PGP SIGNATURE-----
--Apple-Mail=_F5EB2442-8888-41C9-8BD9-71FBEC52AE3D--
From owner-freebsd-current@FreeBSD.ORG Sat Feb 8 20:13:56 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 64CC3D68;
Sat, 8 Feb 2014 20:13:56 +0000 (UTC)
Received: from sarah.protected-networks.net (sarah.protected-networks.net
[IPv6:2001:470:1f07:4e1::1])
(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 2A5BC1AFC;
Sat, 8 Feb 2014 20:13:56 +0000 (UTC)
Received: from toshi.auburn.protected-networks.net
(toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK))
(Authenticated sender: imb@protected-networks.net)
by sarah.protected-networks.net (Postfix) with ESMTPSA id 34C616121;
Sat, 8 Feb 2014 15:13:48 -0500 (EST)
DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws;
q=dns;
h=message-id:date:from:user-agent:mime-version:to:subject:
references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding;
b=f000B/56jy7qcATzHzIMotvly/bOQbuRLveawG6zjUpwlopYYKtnboIljhnx7zL9F
AfLUaHyxD7fSxVbssRPR1OTrxw3OfYXFMbSxH3eikOIdXfGgKz9BE7E3xNCe1qM
Message-ID: <52F68FFA.9020009@protected-networks.net>
Date: Sat, 08 Feb 2014 15:13:46 -0500
From: Michael Butler <imb@protected-networks.net>
User-Agent: Mozilla/5.0 (X11; FreeBSD i386;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Gleb Smirnoff <glebius@FreeBSD.org>, freebsd-current@FreeBSD.org
Subject: Re: buildworld fails with "Zero byte read from file, skipping rest
of line"
References: <20140114072620.GB83762@caravan.chchile.org>
<20140114085818.GQ8472@FreeBSD.org>
<20140115074053.GD83762@caravan.chchile.org>
<20140115084035.GC26504@glebius.int.ru>
In-Reply-To: <20140115084035.GC26504@glebius.int.ru>
X-Enigmail-Version: 1.6
OpenPGP: id=0442D492
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Feb 2014 20:13:56 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/15/14 03:40, Gleb Smirnoff wrote:
> Jeremie,
>
> On Wed, Jan 15, 2014 at 08:40:53AM +0100, Jeremie Le Hen wrote:
> J> > J> ===> gnu/usr.bin/groff/src/libs/libgroff (all)
> J> > J> make[6]: "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" line 3: warning: Zero byte read from file, skipping rest of line.
> J> > J> make[6]: "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" line 3: Need an operator
> J> > J> make[6]: "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" line 4: Need an operator
> J> > J> make[6]: Fatal errors encountered -- cannot continue
> J> > J> make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff
> J> > J> *** [all] Error code 1
> J> > J>
> J> > J> Typscript available here:
> J> > J> http://people.freebsd.org/~jlh/typescript.buildworld.txt
> J> > J>
> J> > J> Any ideas?
> J> >
> J> > Can you try to reproduce this with unmapped I/O turned off in boot loader?
> J>
> J> I've never heard of that. Can you please point me to the right
> J> code/doc?
>
> In loader prompt:
>
> OK set vfs.unmapped_buf_allowed=0
> OK boot
I'm seeing this on a non-virtualized laptop.
Core Duo T2300 (1.8GHz Prescott architecture)
Occurs randomly with either IDE or AHCI enabled on ICH-7 or on a USB
external drive.
Seems to only occur under heavy loads such as recompiling libreoffice,
KDE or similar.
Maybe a race condition in buffer management?
imb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlL2j/kACgkQQv9rrgRC1JJADgCfb4sPmsA1F2HZm3HEJdCCtw43
u9AAoMpEmC94skFsLpCSWbulY1epWtk3
=aewU
-----END PGP SIGNATURE-----