From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 08:48:29 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41BFB106566B for ; Sun, 18 Jan 2009 08:48:29 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id D28788FC17 for ; Sun, 18 Jan 2009 08:48:28 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 62689 invoked from network); 18 Jan 2009 08:21:47 -0000 Received: from 87.58.145.190 (HELO x2.osted.lan) (87.58.145.190) by relay03.pair.com with SMTP; 18 Jan 2009 08:21:47 -0000 X-pair-Authenticated: 87.58.145.190 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n0I8LkDo018256 for ; Sun, 18 Jan 2009 09:21:46 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n0I8Lk6W018255 for freebsd-arch@freebsd.org; Sun, 18 Jan 2009 09:21:46 +0100 (CET) (envelope-from pho) Date: Sun, 18 Jan 2009 09:21:45 +0100 From: Peter Holm To: freebsd-arch@freebsd.org Message-ID: <20090118082145.GA18067@x2.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 08:48:29 -0000 The Kernel Stress Test Suite (stress2) is now in svn: svn://svn.freebsd.org/base/projects/stress2 The purpose of the test suite is to expose design and implementation problems in the kernel, which may lead to panics or deadlocks. The key functionality of this test suite is that it runs a random number of test programs for a random period, in random incarnations and in random sequence. This very simple idea is implemented in the "run" test program, which controls the behavior of all the other test programs. To simplify writing test programs, a test harness is implemented as a library that handles running the test programs. All the creator of new test programs has to implement are three procedures: setup(), cleanup() and test(). Usage should be straight forward: cd projects/stress2 make sh ./run.sh The "run.sh" script accepts an optional configuration file in order to test specific areas. For example: ./run.sh vfs.sh More details in projects/stress2/README. Documentation may be found in projects/stress2/doc. Please have me in mind when you find a problem that can panic the kernel, as I collect regression test scenarios in projects/stress2/misc. - Peter From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 12:11:27 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD74B106566B for ; Sun, 18 Jan 2009 12:11:27 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5618FC12 for ; Sun, 18 Jan 2009 12:11:27 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 9B52A6D43F; Sun, 18 Jan 2009 12:11:26 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 79F2284508; Sun, 18 Jan 2009 13:11:26 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Peter Holm References: <20090118082145.GA18067@x2.osted.lan> Date: Sun, 18 Jan 2009 13:11:25 +0100 In-Reply-To: <20090118082145.GA18067@x2.osted.lan> (Peter Holm's message of "Sun, 18 Jan 2009 09:21:45 +0100") Message-ID: <86iqocstjm.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 12:11:28 -0000 Peter Holm writes: > The key functionality of this test suite is that it runs a random > number of test programs for a random period, in random incarnations > and in random sequence. In other words, it's non-deterministic and non-reproducable. You should at the very least allow the user to specify the random seed. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 13:10:30 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A429A1065675 for ; Sun, 18 Jan 2009 13:10:30 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 439868FC0A for ; Sun, 18 Jan 2009 13:10:30 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 82020 invoked from network); 18 Jan 2009 13:10:28 -0000 Received: from 87.58.145.190 (HELO x2.osted.lan) (87.58.145.190) by relay00.pair.com with SMTP; 18 Jan 2009 13:10:28 -0000 X-pair-Authenticated: 87.58.145.190 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n0IDAS8g026495; Sun, 18 Jan 2009 14:10:28 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n0IDASxI026494; Sun, 18 Jan 2009 14:10:28 +0100 (CET) (envelope-from pho) Date: Sun, 18 Jan 2009 14:10:28 +0100 From: Peter Holm To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20090118131028.GA26179@x2.osted.lan> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86iqocstjm.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 13:10:30 -0000 On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Smørgrav wrote: > Peter Holm writes: > > The key functionality of this test suite is that it runs a random > > number of test programs for a random period, in random incarnations > > and in random sequence. > > In other words, it's non-deterministic and non-reproducable. > Yes, by design. > You should at the very least allow the user to specify the random seed. > Yes, it would be interesting to see if this is enough to reproduce a problem in a deterministic way. I'll look into this. > DES > -- > Dag-Erling Smørgrav - des@des.no -- Peter Holm From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 13:48:17 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73412106566B for ; Sun, 18 Jan 2009 13:48:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 167F08FC19 for ; Sun, 18 Jan 2009 13:48:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LOXhR-000JeO-Tq; Sun, 18 Jan 2009 15:28:26 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0IDSJha085039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jan 2009 15:28:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0IDSJdg084059; Sun, 18 Jan 2009 15:28:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0IDSJEY084058; Sun, 18 Jan 2009 15:28:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 Jan 2009 15:28:19 +0200 From: Kostik Belousov To: Peter Holm Message-ID: <20090118132819.GS48057@deviant.kiev.zoral.com.ua> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <20090118131028.GA26179@x2.osted.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nSQp8DZZn7gZbDHt" Content-Disposition: inline In-Reply-To: <20090118131028.GA26179@x2.osted.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LOXhR-000JeO-Tq 3e7a2ed9d13c533d849c7e95f1fbd7b3 X-Terabit: YES Cc: Dag-Erling Sm?rgrav , freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 13:48:17 -0000 --nSQp8DZZn7gZbDHt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote: > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote: > > Peter Holm writes: > > > The key functionality of this test suite is that it runs a random > > > number of test programs for a random period, in random incarnations > > > and in random sequence. > >=20 > > In other words, it's non-deterministic and non-reproducable. > >=20 >=20 > Yes, by design. >=20 > > You should at the very least allow the user to specify the random seed. > >=20 >=20 > Yes, it would be interesting to see if this is enough to reproduce a > problem in a deterministic way. I'll look into this. I shall state from my experience using it (or, rather, inspecting bug reports generated by stress2), that in fact it is quite repeatable. I.e., when looking into one area, you almost always get _that_ problem, together with 2-3 related issues. Due to the nature of the tests and kernel undeterministic operations, I think that use of the same random seed gains nothing in regard with repeatability of the tests. --nSQp8DZZn7gZbDHt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklzLnIACgkQC3+MBN1Mb4hZvwCggBe2mzNy2k9tJKXTcl97p2jt CtYAoNj5zt2iHC3fw21shvfNiGpokWEB =I4hn -----END PGP SIGNATURE----- --nSQp8DZZn7gZbDHt-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 13:52:30 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A59F0106567D; Sun, 18 Jan 2009 13:52:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from host57.msm.che.vodafone (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF1998FC2B; Sun, 18 Jan 2009 13:52:27 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <49733419.5000407@FreeBSD.org> Date: Sun, 18 Jan 2009 13:52:25 +0000 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> In-Reply-To: <86iqocstjm.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 13:52:30 -0000 Dag-Erling Smørgrav wrote: > Peter Holm writes: >> The key functionality of this test suite is that it runs a random >> number of test programs for a random period, in random incarnations >> and in random sequence. > > In other words, it's non-deterministic and non-reproducable. > > You should at the very least allow the user to specify the random seed. > > DES I doubt this will help at all since the test suite is (by design) massively parallel, so you're at the mercy of small timing changes. Kris From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 14:09:27 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B890106564A for ; Sun, 18 Jan 2009 14:09:27 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id B61998FC08 for ; Sun, 18 Jan 2009 14:09:26 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 87351 invoked from network); 18 Jan 2009 14:09:25 -0000 Received: from 87.58.145.190 (HELO x2.osted.lan) (87.58.145.190) by relay03.pair.com with SMTP; 18 Jan 2009 14:09:25 -0000 X-pair-Authenticated: 87.58.145.190 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n0IE9O6x027944; Sun, 18 Jan 2009 15:09:24 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n0IE9OpG027943; Sun, 18 Jan 2009 15:09:24 +0100 (CET) (envelope-from pho) Date: Sun, 18 Jan 2009 15:09:24 +0100 From: Peter Holm To: Kostik Belousov Message-ID: <20090118140924.GA27264@x2.osted.lan> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <20090118131028.GA26179@x2.osted.lan> <20090118132819.GS48057@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090118132819.GS48057@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm?rgrav , freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 14:09:27 -0000 On Sun, Jan 18, 2009 at 03:28:19PM +0200, Kostik Belousov wrote: > On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote: > > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote: > > > Peter Holm writes: > > > > The key functionality of this test suite is that it runs a random > > > > number of test programs for a random period, in random incarnations > > > > and in random sequence. > > > > > > In other words, it's non-deterministic and non-reproducable. > > > > > > > Yes, by design. > > > > > You should at the very least allow the user to specify the random seed. > > > > > > > Yes, it would be interesting to see if this is enough to reproduce a > > problem in a deterministic way. I'll look into this. > > I shall state from my experience using it (or, rather, inspecting bug > reports generated by stress2), that in fact it is quite repeatable. > I.e., when looking into one area, you almost always get _that_ problem, > together with 2-3 related issues. > > Due to the nature of the tests and kernel undeterministic operations, > I think that use of the same random seed gains nothing in regard with > repeatability of the tests. It is an old issue that has come up many times: It would be so great if it was possible to some how record the exact sequence that lead up to a panic and play it back. But on the other hand, as you say, it *is* repeatable. The only issue is that it may take 5 minutes or 5 hours. But I'm still game to see if it is possible at all (in single user mode with no network activity etc.) - Peter From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 20:17:45 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1253F1065670 for ; Sun, 18 Jan 2009 20:17:45 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id A7F4A8FC1E for ; Sun, 18 Jan 2009 20:17:44 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 674665B61; Sun, 18 Jan 2009 12:12:02 -0800 (PST) To: Peter Holm In-reply-to: Your message of "Sun, 18 Jan 2009 15:09:24 +0100." <20090118140924.GA27264@x2.osted.lan> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <20090118131028.GA26179@x2.osted.lan> <20090118132819.GS48057@deviant.kiev.zoral.com.ua> <20090118140924.GA27264@x2.osted.lan> Date: Sun, 18 Jan 2009 12:12:02 -0800 From: Bakul Shah Message-Id: <20090118201202.674665B61@mail.bitblocks.com> Cc: Kostik Belousov , Dag-Erling Sm?rgrav , freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 20:17:45 -0000 On Sun, 18 Jan 2009 15:09:24 +0100 Peter Holm wrote: > On Sun, Jan 18, 2009 at 03:28:19PM +0200, Kostik Belousov wrote: > > On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote: > > > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote: > > > > Peter Holm writes: > > > > > The key functionality of this test suite is that it runs a random > > > > > number of test programs for a random period, in random incarnations > > > > > and in random sequence. > > > > > > > > In other words, it's non-deterministic and non-reproducable. > > > > > > > > > > Yes, by design. > > > > > > > You should at the very least allow the user to specify the random seed. > > > > > > > > > > Yes, it would be interesting to see if this is enough to reproduce a > > > problem in a deterministic way. I'll look into this. > > > > I shall state from my experience using it (or, rather, inspecting bug > > reports generated by stress2), that in fact it is quite repeatable. > > I.e., when looking into one area, you almost always get _that_ problem, > > together with 2-3 related issues. > > > > Due to the nature of the tests and kernel undeterministic operations, > > I think that use of the same random seed gains nothing in regard with > > repeatability of the tests. > > It is an old issue that has come up many times: It would be so great > if it was possible to some how record the exact sequence that lead up > to a panic and play it back. > > But on the other hand, as you say, it *is* repeatable. The only > issue is that it may take 5 minutes or 5 hours. > > But I'm still game to see if it is possible at all (in single user > mode with no network activity etc.) Allowing a user to specify the random seed (and *always* reporting the random seed of every test) can't hurt and it may actually gain you repeatability in some cases. Most bugs are typically of garden variety, not dependent on some complex interactions between parallel programs (or worse, on processor heisenbugs). You can always try repeating a failing test on a more deterministic set up like qemu etc. One trick I have used in the past is to record "significant" events in one or more ring buffers using some cheap encoding. You have then access to past N events during any post kernel crash analysis. This has far less of an overhead than debug printfs and you can even leave it enabled in production use. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 20:31:34 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 565C81065670; Sun, 18 Jan 2009 20:31:34 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 45A888FC0A; Sun, 18 Jan 2009 20:31:34 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 221951A3C3E; Sun, 18 Jan 2009 12:31:34 -0800 (PST) Date: Sun, 18 Jan 2009 12:31:34 -0800 From: Alfred Perlstein To: Kris Kennaway Message-ID: <20090118203134.GF60686@elvis.mu.org> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <49733419.5000407@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49733419.5000407@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm??rgrav , freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 20:31:34 -0000 * Kris Kennaway [090118 05:52] wrote: > Dag-Erling Sm??rgrav wrote: > >Peter Holm writes: > >>The key functionality of this test suite is that it runs a random > >>number of test programs for a random period, in random incarnations > >>and in random sequence. > > > >In other words, it's non-deterministic and non-reproducable. > > > >You should at the very least allow the user to specify the random seed. > > > >DES > > I doubt this will help at all since the test suite is (by design) > massively parallel, so you're at the mercy of small timing changes. If the start and stop times of the scripts were recorded one could synch with the original potentially between runs, at least on the same hardware it ran. Basically, replay the suite based on time instead of random. -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 22:05:35 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6531106566B; Sun, 18 Jan 2009 22:05:35 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-76-187.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 648D28FC21; Sun, 18 Jan 2009 22:05:34 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4973A7AD.8050106@FreeBSD.org> Date: Sun, 18 Jan 2009 22:05:33 +0000 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alfred Perlstein References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <49733419.5000407@FreeBSD.org> <20090118203134.GF60686@elvis.mu.org> In-Reply-To: <20090118203134.GF60686@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dag-Erling Sm??rgrav , freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 22:05:36 -0000 Alfred Perlstein wrote: > * Kris Kennaway [090118 05:52] wrote: >> Dag-Erling Sm??rgrav wrote: >>> Peter Holm writes: >>>> The key functionality of this test suite is that it runs a random >>>> number of test programs for a random period, in random incarnations >>>> and in random sequence. >>> In other words, it's non-deterministic and non-reproducable. >>> >>> You should at the very least allow the user to specify the random seed. >>> >>> DES >> I doubt this will help at all since the test suite is (by design) >> massively parallel, so you're at the mercy of small timing changes. > > If the start and stop times of the scripts were recorded one could > synch with the original potentially between runs, at least on the > same hardware it ran. > > Basically, replay the suite based on time instead of random. > > -Alfred > > Since the goal of the stress test is effectively to exploit race conditions, I'm still skeptical there is a way to make that happen deterministically. Anyway as Kostik says, problems discovered by stress2 do tend to be reproducible given suitable runtime. Kris From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 22:25:00 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F08310656C4 for ; Sun, 18 Jan 2009 22:25:00 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 3635A8FC24 for ; Sun, 18 Jan 2009 22:24:59 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 40640 invoked from network); 18 Jan 2009 22:24:58 -0000 Received: from 87.58.145.190 (HELO x2.osted.lan) (87.58.145.190) by relay03.pair.com with SMTP; 18 Jan 2009 22:24:58 -0000 X-pair-Authenticated: 87.58.145.190 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n0IMOvJu042803; Sun, 18 Jan 2009 23:24:57 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n0IMOu3s042802; Sun, 18 Jan 2009 23:24:56 +0100 (CET) (envelope-from pho) Date: Sun, 18 Jan 2009 23:24:56 +0100 From: Peter Holm To: Bakul Shah Message-ID: <20090118222456.GA42363@x2.osted.lan> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <20090118131028.GA26179@x2.osted.lan> <20090118132819.GS48057@deviant.kiev.zoral.com.ua> <20090118140924.GA27264@x2.osted.lan> <20090118201202.674665B61@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090118201202.674665B61@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i Cc: Kostik Belousov , Dag-Erling Sm?rgrav , freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 22:25:00 -0000 On Sun, Jan 18, 2009 at 12:12:02PM -0800, Bakul Shah wrote: > On Sun, 18 Jan 2009 15:09:24 +0100 Peter Holm wrote: > > On Sun, Jan 18, 2009 at 03:28:19PM +0200, Kostik Belousov wrote: > > > On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote: > > > > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote: > > > > > Peter Holm writes: > > > > > > The key functionality of this test suite is that it runs a random > > > > > > number of test programs for a random period, in random incarnations > > > > > > and in random sequence. > > > > > > > > > > In other words, it's non-deterministic and non-reproducable. > > > > > > > > > > > > > Yes, by design. > > > > > > > > > You should at the very least allow the user to specify the random seed. > > > > > > > > > > > > > Yes, it would be interesting to see if this is enough to reproduce a > > > > problem in a deterministic way. I'll look into this. > > > > > > I shall state from my experience using it (or, rather, inspecting bug > > > reports generated by stress2), that in fact it is quite repeatable. > > > I.e., when looking into one area, you almost always get _that_ problem, > > > together with 2-3 related issues. > > > > > > Due to the nature of the tests and kernel undeterministic operations, > > > I think that use of the same random seed gains nothing in regard with > > > repeatability of the tests. > > > > It is an old issue that has come up many times: It would be so great > > if it was possible to some how record the exact sequence that lead up > > to a panic and play it back. > > > > But on the other hand, as you say, it *is* repeatable. The only > > issue is that it may take 5 minutes or 5 hours. > > > > But I'm still game to see if it is possible at all (in single user > > mode with no network activity etc.) > > Allowing a user to specify the random seed (and *always* > reporting the random seed of every test) can't hurt and it > may actually gain you repeatability in some cases. Most bugs > are typically of garden variety, not dependent on some Ah, yes if that was the case. But most of the problems I encounter are typically lock related. > complex interactions between parallel programs (or worse, on > processor heisenbugs). You can always try repeating a failing > test on a more deterministic set up like qemu etc. > Different hardware also seems to play a big role in finding bugs: Number of CPUs etc. > One trick I have used in the past is to record "significant" > events in one or more ring buffers using some cheap encoding. > You have then access to past N events during any post kernel > crash analysis. This has far less of an overhead than debug > printfs and you can even leave it enabled in production use. -- Peter Holm From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 22:29:13 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD8E1065676 for ; Sun, 18 Jan 2009 22:29:13 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id A687B8FC38 for ; Sun, 18 Jan 2009 22:29:13 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 71640 invoked from network); 18 Jan 2009 22:29:09 -0000 Received: from 87.58.145.190 (HELO x2.osted.lan) (87.58.145.190) by relay02.pair.com with SMTP; 18 Jan 2009 22:29:09 -0000 X-pair-Authenticated: 87.58.145.190 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n0IMT8BT042953; Sun, 18 Jan 2009 23:29:08 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n0IMT84b042952; Sun, 18 Jan 2009 23:29:08 +0100 (CET) (envelope-from pho) Date: Sun, 18 Jan 2009 23:29:08 +0100 From: Peter Holm To: Alfred Perlstein Message-ID: <20090118222908.GA42845@x2.osted.lan> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <49733419.5000407@FreeBSD.org> <20090118203134.GF60686@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090118203134.GF60686@elvis.mu.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm??rgrav , freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 22:29:14 -0000 On Sun, Jan 18, 2009 at 12:31:34PM -0800, Alfred Perlstein wrote: > * Kris Kennaway [090118 05:52] wrote: > > Dag-Erling Sm??rgrav wrote: > > >Peter Holm writes: > > >>The key functionality of this test suite is that it runs a random > > >>number of test programs for a random period, in random incarnations > > >>and in random sequence. > > > > > >In other words, it's non-deterministic and non-reproducable. > > > > > >You should at the very least allow the user to specify the random seed. > > > > > >DES > > > > I doubt this will help at all since the test suite is (by design) > > massively parallel, so you're at the mercy of small timing changes. > > If the start and stop times of the scripts were recorded one could > synch with the original potentially between runs, at least on the > same hardware it ran. > > Basically, replay the suite based on time instead of random. > During the more than 10 years I have used this test suite with FreeBSD I have always prioritized the ability to panic the kernel. I have never looked much into a method of re-creating a test stream. As I see it, it is a *slight* inconvenience that a panic or deadlock is not 100% reproducible in time. A fix for any problem still needs a thorough test (measured in days), IMHO. Several methods exists, as I see it, to create a test stream. One could for example generate the random work list first and then execute the tests after that. After a panic you would the have the work list that created the problem. But would re-running the work list reproduce the panic? I seriously doubt that. But there is only one way to find out. It should not be that hard to create deterministic execution of the the tests. - Peter > -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Jan 19 11:06:55 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92193106566B for ; Mon, 19 Jan 2009 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 648B08FC13 for ; Mon, 19 Jan 2009 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0JB6tJF062908 for ; Mon, 19 Jan 2009 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0JB6sNQ062904 for freebsd-arch@FreeBSD.org; Mon, 19 Jan 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Jan 2009 11:06:54 GMT Message-Id: <200901191106.n0JB6sNQ062904@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 19 20:36:09 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B83A41065673 for ; Mon, 19 Jan 2009 20:36:09 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7A11F8FC19 for ; Mon, 19 Jan 2009 20:36:09 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n0JK44RJ027313; Mon, 19 Jan 2009 15:04:04 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n0JK42cW027312; Mon, 19 Jan 2009 15:04:02 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 19 Jan 2009 15:04:02 -0500 From: David Schultz To: d@delphij.net Message-ID: <20090119200402.GA26878@zim.MIT.EDU> Mail-Followup-To: d@delphij.net, freebsd-arch@FreeBSD.ORG References: <4966B5D4.7040709@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4966B5D4.7040709@delphij.net> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: MI strlen() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 20:36:10 -0000 On Thu, Jan 08, 2009, Xin LI wrote: > Here is a new implementation of strlen() which employed the bitmask > skill in order to achieve better performance on modern hardware. For > common case, this would be a 5.2x boost on FreeBSD/amd64. The code is > intended for MI use when there is no hand-optimized assembly. I ran some microbenchmarks on amd64, which show that the version of strlen() in libc is up to twice as fast as yours for short strings (< 4 bytes), but your implementation is nearly 5 times as fast for longer strings. As Bruce pointed out, gcc will almost use its builtin strlen(). However, that may change in the future, and nobody has suggested that your version would actually hurt anything, so I think you should commit it. Benchmark results: http://www.freebsd.org/~das/strlen.gif I ran this on a Wolfdale core using word-aligned ASCII strings and an adaptive number of iterations. As you can see, the gcc builtin is always slower than your code, but faster than our current libc implementation. I can't explain why the builtin is faster for strings of length 10 than it is for strings of length 1, but the results are repeatable. Another interesting thing to note is that your implementation is the only one that gets less throughput when the string no longer fits in the L2 cache. This suggests that either the other two are so slow that they can't use the full memory bandwidth, or they are more effective at triggering the CPU's prefetch heuristics. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 20 00:56:51 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 107CD1065674 for ; Tue, 20 Jan 2009 00:56:51 +0000 (UTC) (envelope-from ghostviewer@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id C46878FC0A for ; Tue, 20 Jan 2009 00:56:50 +0000 (UTC) (envelope-from ghostviewer@web.de) Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate01.web.de (Postfix) with ESMTP id 1C084FBFA679 for ; Tue, 20 Jan 2009 01:28:57 +0100 (CET) Received: from [89.53.125.81] (helo=[192.168.178.23]) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LP4UC-0002YG-00 for freebsd-arch@freebsd.org; Tue, 20 Jan 2009 01:28:56 +0100 Message-ID: <49751AC8.7080901@web.de> Date: Tue, 20 Jan 2009 01:28:56 +0100 From: =?ISO-8859-15?Q?rainer_herrend=F6rfer?= User-Agent: IceDove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: ghostviewer@web.de X-Sender: ghostviewer@web.de X-Provags-ID: V01U2FsdGVkX1/Clo0ZTlIaZI3NIdovd3eTdUl1Fn3eWETqLKlt tsS3GfPSW9eyU3rWxXnBvpyff/5YiO9hw05y8DTMULOdaOVpbQ pBmQu2B00= Subject: bge0: Firmware handshake timed out X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 00:56:51 -0000 Hi, I just tried to install amd64 7.1 Release on a HP Compaq 6715b laptop. No NICs were found. dmesg: ... bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 bge0: Firmware handshake timed out, found 0x4b657654 bge0: Firmware handshake timed out, found 0x4b657654 bge0: RX CPU self-diagnostics failed! bge0: chip initialization failed device_attach: bge0 attach returned 6 ... I tried 7.0 amd64 with the same result. Another odd thing: Boot with acpi disabled ends with hang up. Last lines on the screen: ... Timecounters tics every 1.000msec md0: Preloaded image 4194304 bytes at 0xffffffff80c4be40 Trying to mount root from ufs:/dev/md0 On the other hand linux runs without any problems, no changes in BIOS or elsewhere. So Hardware should be o.k.. Any hints? -- kind regards rainer herrendoerfer From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 07:27:30 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93B8D1065674 for ; Wed, 21 Jan 2009 07:27:30 +0000 (UTC) (envelope-from kosuru.pavan@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB318FC08 for ; Wed, 21 Jan 2009 07:27:30 +0000 (UTC) (envelope-from kosuru.pavan@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3629116rvf.43 for ; Tue, 20 Jan 2009 23:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=s05OkUKU+VwsrDTW9e/82waZg225BbdgatsAo3DiDIY=; b=NgZ8jCT6B6M9SYmxikGHUI/SGzDu1B1axxezF/QsBo61udO/CE4F9iSkw5fQg+4ga0 wzKb5wyK/6X0UojG+kWNtmDOkWunOwY3Tc1JYigAoC/r97yqCFyUfg/m7gokGQCIwP5c u3YUJ0UgGqg+cGxDnjor+lehMnhvdJRe5ctcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tZszN+aiZcoY1yDg/PqWUTJ1Qvu/V//Ydu+SD/Vd4Jabz8/QsNlXGLetmMxfHjrL3O z66KgK9W/SVGLCk2gI251qQyOYcq4nVpizuEIkq83solXEJRwSSfIDSbM5NHv57BLcvf JPgX/E5aI+qrcIzOlqb3YtivpnNXDy3mb/FNU= MIME-Version: 1.0 Received: by 10.140.165.21 with SMTP id n21mr1729406rve.240.1232521414988; Tue, 20 Jan 2009 23:03:34 -0800 (PST) Date: Wed, 21 Jan 2009 12:33:34 +0530 Message-ID: <1ed07a9e0901202303o465cba12wfbcdb10b759cada7@mail.gmail.com> From: pavan kosuru To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Reg:SendMail Not working X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 07:27:31 -0000 Hi , I am trying to send SMTP mail using the mail() function in php but unable send to the destination I intended to. I wanted send mail using the php script which is running fine in one server but not in my localmachine.In my local machine it just returning the succes code and I m not receving any mails. I configured the sendmail as well as postfix. Some one help me ------ Pavan ... From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 13:00:21 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55CF310658BF for ; Wed, 21 Jan 2009 13:00:21 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from websrv01.jr-hosting.nl (websrv01.jr-hosting.nl [78.47.69.233]) by mx1.freebsd.org (Postfix) with ESMTP id 14A478FC1C for ; Wed, 21 Jan 2009 13:00:20 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from localhost ([127.0.0.1] helo=galain.elvandar.org) by websrv01.jr-hosting.nl with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LPcDh-0006Hd-HY; Wed, 21 Jan 2009 13:30:09 +0100 Received: from 145.7.91.133 (SquirrelMail authenticated user remko) by galain.elvandar.org with HTTP; Wed, 21 Jan 2009 13:30:09 +0100 (CET) Message-ID: In-Reply-To: <1ed07a9e0901202303o465cba12wfbcdb10b759cada7@mail.gmail.com> References: <1ed07a9e0901202303o465cba12wfbcdb10b759cada7@mail.gmail.com> Date: Wed, 21 Jan 2009 13:30:09 +0100 (CET) From: "Remko Lodder" To: "pavan kosuru" User-Agent: SquirrelMail/1.4.16 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-arch@freebsd.org Subject: Re: Reg:SendMail Not working X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 13:00:23 -0000 Dear Pavan, On Wed, January 21, 2009 8:03 am, pavan kosuru wrote: > Hi , > I am trying to send SMTP mail using the mail() function in php but unable > send to the destination I intended to. I wanted send mail using the php > script which is running fine in one server but not in my localmachine.In > my > local machine it just returning the succes code and I m not receving any > mails. I configured the sendmail as well as postfix. Some one help me > > > ------ Pavan ... Thank you for your interest in the FreeBSD Operating System. FreeBSD is an open source BSD licensed operating system which can be extended by third party tools. One of these tools is the PHP application set. We can try to give you support for FreeBSD as much as possible within our volunteer time and technical knowledge, that is the operating system. It is much harder for us to support you with "PHP" kind of problems, since that is not within our scope. PHP Mail() functionality uses /usr/sbin/sendmail as far as i can remember, which might require a running sendmail version. Can you please check with ``ps auxww | grep sendmail'' whether sendmail is being listed in the process list? One simple thing to know whether the sendmail application works or not, is by seeing if you get daily periodic emails from the system maintenance scripts. If that is being received, I suggest that you look at the mail() documentation from PHP and potentially set the correct parameters. Also note that php.ini has some mentionings of where and how mail should be send. Also note that the -arch list is not for questions like these, questions like this, if applicable should be send to the questions@FreeBSD.org mailinglist. Again thanks for your interest in FreeBSD and the willingness to share knowledge! Best Regards, Remko > -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 14:19:01 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4291065940; Wed, 21 Jan 2009 14:19:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B72F68FC29; Wed, 21 Jan 2009 14:19:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 5487B46B03; Wed, 21 Jan 2009 09:19:00 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LEIsoF033505; Wed, 21 Jan 2009 09:18:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 21 Jan 2009 08:43:32 -0500 User-Agent: KMail/1.9.7 References: <4929C6D8.7090305@freebsd.org> <20081124.105800.-267230932.imp@bsdimp.com> <4963AFE3.5080607@freebsd.org> In-Reply-To: <4963AFE3.5080607@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901210843.33247.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 09:18:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8884/Wed Jan 21 08:15:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Nathan Whitehorn Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:19:03 -0000 On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote: > M. Warner Losh wrote: > > In message: <492AC8DE.6050902@freebsd.org> > > Nathan Whitehorn writes: > > : M. Warner Losh wrote: > > : > In message: <4929C6D8.7090305@freebsd.org> > > : > Nathan Whitehorn writes: > > : > : Rafa=C5=82 Jaworowski wrote: > > : > : >=20 > > : > : > On 2008-11-23, at 19:18, Dag-Erling Sm=C3=B8rgrav wrote: > > : > : >=20 > > : > : >> Nathan Whitehorn writes: > > : > : >>> The current I2C bus mechanism does not support the bus adding= =20 its own > > : > : >>> children [...] > > : > : >> > > : > : >> That's because the I2C protocol does not support device=20 enumeration or > > : > : >> identification. You have to know in advance what kind of devi= ces=20 are > > : > : >> attached and at what address. Even worse, it is not uncommon = for > > : > : >> similar but not entirely compatible devices to use the same I2= C=20 address > > : > : >> (for instance, every I2C-capable RTC chip uses the same addres= s,=20 even > > : > : >> though they have different feature sets) > > : > : >=20 > > : > : > Well, hard-coded addresses and conflicting assignments between= =20 vendors=20 > > : > : > do not technically prevent from scanning the bus; actually, our= =20 current=20 > > : > : > iicbus code can do bus scaning when compiled with a diag define= =2E=20 The=20 > > : > : > problem however is some slave devices are not well-behaved, and= =20 they=20 > > : > : > don't like to be read/written to other than in very specific=20 scenario:=20 > > : > : > if polled during bus scan strange effects occur e.g. they=20 disappear from=20 > > : > : > the bus, or do not react to consecutive requests etc. > > : > :=20 > > : > : All of this is true, but perhaps my question was badly worded. Wh= at=20 I am=20 > > : > : trying to figure out is how to shove information from an out-of-b= and=20 > > : > : source (Open Firmware, in this case) into newbus without disrupti= ng=20 > > : > : existing code. In that way, my question is not I2C specific -- we= =20 run=20 > > : > : into the same issue with the Open Firmware nexus node and=20 pseudo-devices=20 > > : > : like cryptosoft that attach themselves. > > : >=20 > > : > You are looking at the problem incorrectly. In newbus, a case like > > : > this the i2c bus should be a subclass (say i2c_of) that is derived > > : > from the normal i2c bus stuff, but replaces the hints insertion of > > : > devices with OF enumeration of devices. The OF higher levels will > > : > already know to attach this kind of i2c bus to certain i2c > > : > controllers, or always on certain platforms. > > :=20 > > : Yes, this is exactly what I wanted to do, like how ofw_pci works. > > :=20 > > : > : What I want to do is to have the I2C bus add the children that th= e=20 > > : > : firmware says it has. What the firmware cannot tell in advance,=20 however,=20 > > : > : is which FreeBSD driver is responsible for those devices, and so = the=20 I2C=20 > > : > : bus driver can't know that without a translation table that I wou= ld=20 > > : > : prefer not to hack in to the bus driver. > > : >=20 > > : > This is the bigger problem. Today, we are stuck with a lame table > > : > that will translate the OF provided properties into FreeBSD driver > > : > names. > > :=20 > > : At the moment, I don't believe Apple uses any of the current very sma= ll=20 > > : number of I2C device drivers in tree. So I may skip the table for the= =20 > > : time being, assuming the hack below is OK. In future, this may change= ,=20 > > : since G5 systems require software thermal control. But that will be t= he=20 > > : subject of another mail to this list... > > :=20 > > : > : It seems reasonable to allow devices to use a real probe routine = to=20 look=20 > > : > : at the firmware's name and compatible properties, like we allow o= n=20 other=20 > > : > : Open Firmware busses. The trouble is that existing drivers don't = do=20 > > : > : this, because they expect to be attached with hints, so they will= =20 attach=20 > > : > : to all devices. I'm trying to figure out how to avoid this. > > : > :=20 > > : > : My basic question comes down to whether there is a good way in=20 newbus to=20 > > : > : handle busses that may be wholly or partially enumerated by firmw= are=20 or=20 > > : > : some other method, and may also have devices that can only attach= =20 > > : > : themselves if told to by hints. > > : >=20 > > : > Yes. This is a bit of a problem. The problem is that the existing > > : > hints mechanism combines device tree and driver tree into one, and = in > > : > such a scenario, we wind up with the problem that you have. > > : >=20 > > : > One could make the probe routines return BUS_PROBE_GENERIC, and that > > : > would help somewhat. One could also have the probe routine check to > > : > see if a specific driver is assigned to the device or not. That wo= uld > > : > also help, but does mean changing all the i2c bus attached drivers = in > > : > the tree. > > :=20 > > : I think changing existing I2C drivers may be unavoidable. Would there= be=20 > > : any objection to changing the MI iicbus drivers to return=20 > > : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been=20 > > : introduced (by you) to solve more or less exactly this problem. By my= =20 > > : count, the relevant files are: > > : dev/iicbus/ds133x.c > > : dev/iicbus/icee.c > > : dev/iicbus/ad7418.c > > : dev/iicbus/iicsmb.c > > : dev/iicbus/ds1672.c > > : dev/iicbus/if_ic.c > > : dev/iicbus/iic.c > > :=20 > > : I would also like to change iicbus_probe to return -1000 like=20 > > : dev/pci/pci.c to allow it to be overridden by a subclass. Please let = me=20 > > : know if this is a terrible idea or if I have forgotten any I2C device= =20 > > : drivers. > > > > Short term, this is the right fix. There was an objection, I think by > > Marcel, to this approach. However, his objections were part of a > > larger set of objections and I think that we're working to solve > > those. > > > > Warner > > =20 > This is now in the tree. Now for part 2, which I had not considered=20 > previously: connecting the I2C bus layer to the I2C host adapters. >=20 > Right now, we have the following: > kiic/other i2c adapters > ---iicbus > ---ofw_iicbus >=20 > Since kiic provides an Open Firmware node, ofw_iicbus gets priority,=20 > attaches, and everything after that is wonderful. The issue is how best=20 > to attach the iicbus modules to kiic. Current I2C controllers contain a=20 > line like this: > DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0); >=20 > This explicitly specifies that you want the standard driver, so we need=20 > additional glue to allow the ofw_iicbus driver to attach. One solution=20 > is that each relevant host adapter can add an additional DRIVER_MODULE=20 > line with the ofw_iicbus driver and class, which would have to exported=20 > in a header somewhere. This is pretty ugly. Another solution is for the=20 > ofw_iicbus module to grow a list of the names of interesting adapters.=20 > This is worse. >=20 > The third option is to do what we do for pci, where all PCI adapters are= =20 > named 'pcib'. So we could make new I2C host adapters named 'iichb' or=20 > something, and then move the DRIVER_MODULE logic for new code into the=20 > bus modules, as is done for PCI. This decreases the amount of=20 > information in the device names, but seems a bit cleaner. Thoughts? > -Nathan If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same=20 functionality) similar to the OF-aware PCI bus, then I would go the PCI rou= te=20 and just call it iicbus but give it a higher probe priority. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 14:19:06 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACF2A1065BCD for ; Wed, 21 Jan 2009 14:19:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3948FC29 for ; Wed, 21 Jan 2009 14:19:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 29B4746B17; Wed, 21 Jan 2009 09:19:06 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LEIsoG033505; Wed, 21 Jan 2009 09:19:00 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 21 Jan 2009 08:47:05 -0500 User-Agent: KMail/1.9.7 References: <20081229212020.GA1809@curry.mchp.siemens.de> <20081229143221.X1076@desktop> In-Reply-To: <20081229143221.X1076@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901210847.05858.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 09:19:00 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8884/Wed Jan 21 08:15:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Andre Albsmeier Subject: Re: Two drivers, one physical device: How to deal with that? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:19:09 -0000 On Monday 29 December 2008 7:35:21 pm Jeff Roberson wrote: > On Mon, 29 Dec 2008, Andre Albsmeier wrote: > > > Hello, > > > > I have written a driver which attaches to the host bridge in > > order to periodically read the appropriate registers and > > inform the user about ECC errors (ECC-Monitor). No I have > > run across a mainboard where the host bridge is already > > taken by the agp driver. Of course, I can detach the agp > > driver and attach myself and everything is working but > > what is if someone does not want to loose the agp > > functionality? > > > > How does one deal with the case when two separate drivers > > have to access the same device (the host bridge in my case)? > > > > I assume, the correct way would be to join the AGP and > > ECC functionality in one driver but maybe there are other > > tricks I am not aware of? > > Well I don't think it would be correct to merge two conceptually seperate > drivers into one just to share the same device. It sounds like the right > solution is to make a generic layer the attaches to the host bridge and > arbitrates access to it. Then allow other device to find and communicate > with this generic layer. For the host bridge this doesn't have to be > particularly fancy. This is already the case in 7.0 and later where hostb(4) always attaches to host bridges and agp(4) attaches to the hostb(4) devices. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 14:19:15 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E551065CAF; Wed, 21 Jan 2009 14:19:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D367D8FC25; Wed, 21 Jan 2009 14:19:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 809DB46B06; Wed, 21 Jan 2009 09:19:14 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LEIsoH033505; Wed, 21 Jan 2009 09:19:08 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 21 Jan 2009 08:57:21 -0500 User-Agent: KMail/1.9.7 References: <496C8C6A.2030708@icyb.net.ua> <20090115.110824.298933043.imp@bsdimp.com> <497088E6.4020908@icyb.net.ua> In-Reply-To: <497088E6.4020908@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901210857.22204.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 09:19:08 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8884/Wed Jan 21 08:15:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Andriy Gapon , Archie Cobbs Subject: Re: smb(4): address format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:19:18 -0000 On Friday 16 January 2009 8:17:26 am Andriy Gapon wrote: > on 15/01/2009 20:08 M. Warner Losh said the following: > > The format that is preferred on FreeBSD is xxxxxxxx0b. That's the > > format that the existing IIC bridge drivers use and deal with. I've > > not looked at the SMB drivers, but I went through all the iic bridge > > drivers in the 6.x time frame and made sure they were all consistent. > > If I missed the smb drivers, that's my bad. > > > > I could find no evidence that there was a format that was more > > preferred apart from the dozen data sheets that I'd read at the time > > which used the xxxxxxx0b. > > What about the attached patch. > It brings ichsmb in line with this format and also adds a simple check > into smb(4). Commit! -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 14:19:21 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30F461065D12; Wed, 21 Jan 2009 14:19:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EF93B8FC1E; Wed, 21 Jan 2009 14:19:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 9D94546B03; Wed, 21 Jan 2009 09:19:20 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LEIsoI033505; Wed, 21 Jan 2009 09:19:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 21 Jan 2009 09:00:28 -0500 User-Agent: KMail/1.9.7 References: <20090118082145.GA18067@x2.osted.lan> <20090118140924.GA27264@x2.osted.lan> <20090118201202.674665B61@mail.bitblocks.com> In-Reply-To: <20090118201202.674665B61@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901210900.29226.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 09:19:14 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8884/Wed Jan 21 08:15:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , Dag-Erling Sm?rgrav Subject: Re: stress2 is now in projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:19:28 -0000 On Sunday 18 January 2009 3:12:02 pm Bakul Shah wrote: > Allowing a user to specify the random seed (and *always* > reporting the random seed of every test) can't hurt and it > may actually gain you repeatability in some cases. Most bugs > are typically of garden variety, not dependent on some > complex interactions between parallel programs (or worse, on > processor heisenbugs). You can always try repeating a failing > test on a more deterministic set up like qemu etc. Actually, all the bugs I've used stress2 for were race conditions and locking bugs for which having a set random seed would not have helped. > One trick I have used in the past is to record "significant" > events in one or more ring buffers using some cheap encoding. > You have then access to past N events during any post kernel > crash analysis. This has far less of an overhead than debug > printfs and you can even leave it enabled in production use. man ktr -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 14:20:57 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 208E51065975; Wed, 21 Jan 2009 14:20:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BA8878FC22; Wed, 21 Jan 2009 14:20:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA07645; Wed, 21 Jan 2009 16:20:53 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49772F44.1030806@icyb.net.ua> Date: Wed, 21 Jan 2009 16:20:52 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: John Baldwin , "M. Warner Losh" References: <496C8C6A.2030708@icyb.net.ua> <20090115.110824.298933043.imp@bsdimp.com> <497088E6.4020908@icyb.net.ua> <200901210857.22204.jhb@freebsd.org> In-Reply-To: <200901210857.22204.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Archie Cobbs , freebsd-arch@freebsd.org Subject: Re: smb(4): address format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:21:02 -0000 on 21/01/2009 15:57 John Baldwin said the following: > On Friday 16 January 2009 8:17:26 am Andriy Gapon wrote: >> on 15/01/2009 20:08 M. Warner Losh said the following: >>> The format that is preferred on FreeBSD is xxxxxxxx0b. That's the >>> format that the existing IIC bridge drivers use and deal with. I've >>> not looked at the SMB drivers, but I went through all the iic bridge >>> drivers in the 6.x time frame and made sure they were all consistent. >>> If I missed the smb drivers, that's my bad. >>> >>> I could find no evidence that there was a format that was more >>> preferred apart from the dozen data sheets that I'd read at the time >>> which used the xxxxxxx0b. >> What about the attached patch. >> It brings ichsmb in line with this format and also adds a simple check >> into smb(4). > > Commit! > I guess this would also need a note in UPDATING and some HEADS UP in current@. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 14:36:43 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32EEE1065679; Wed, 21 Jan 2009 14:36:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EE6D48FC1F; Wed, 21 Jan 2009 14:36:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 9A6B746B17; Wed, 21 Jan 2009 09:36:42 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LEaaWp033642; Wed, 21 Jan 2009 09:36:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Wed, 21 Jan 2009 09:36:28 -0500 User-Agent: KMail/1.9.7 References: <496C8C6A.2030708@icyb.net.ua> <200901210857.22204.jhb@freebsd.org> <49772F44.1030806@icyb.net.ua> In-Reply-To: <49772F44.1030806@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901210936.28773.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 09:36:36 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8884/Wed Jan 21 08:15:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Archie Cobbs , freebsd-arch@freebsd.org Subject: Re: smb(4): address format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:36:49 -0000 On Wednesday 21 January 2009 9:20:52 am Andriy Gapon wrote: > on 21/01/2009 15:57 John Baldwin said the following: > > On Friday 16 January 2009 8:17:26 am Andriy Gapon wrote: > >> on 15/01/2009 20:08 M. Warner Losh said the following: > >>> The format that is preferred on FreeBSD is xxxxxxxx0b. That's the > >>> format that the existing IIC bridge drivers use and deal with. I've > >>> not looked at the SMB drivers, but I went through all the iic bridge > >>> drivers in the 6.x time frame and made sure they were all consistent. > >>> If I missed the smb drivers, that's my bad. > >>> > >>> I could find no evidence that there was a format that was more > >>> preferred apart from the dozen data sheets that I'd read at the time > >>> which used the xxxxxxx0b. > >> What about the attached patch. > >> It brings ichsmb in line with this format and also adds a simple check > >> into smb(4). > > > > Commit! > > > > I guess this would also need a note in UPDATING and some HEADS UP in > current@. Sure, though I had a hard time getting people to test the locking changes to the smbus(4) drivers, so I doubt many current@ users actually use smbus(4). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 15:44:55 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFCAE1065678; Wed, 21 Jan 2009 15:44:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 9017B8FC13; Wed, 21 Jan 2009 15:44:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) id <0KDT00310SYU6T00@smtpauth1.wiscmail.wisc.edu>; Wed, 21 Jan 2009 08:44:54 -0600 (CST) Received: from trantor.tachypleus.net ([76.201.159.224]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KDT00JEDSYLM050@smtpauth1.wiscmail.wisc.edu>; Wed, 21 Jan 2009 08:44:49 -0600 (CST) Date: Wed, 21 Jan 2009 08:47:50 -0600 From: Nathan Whitehorn In-reply-to: <200901210843.33247.jhb@freebsd.org> To: John Baldwin Message-id: <49773596.2050700@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.201.159.224 X-Spam-PmxInfo: Server=avs-13, Version=5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.1.21.142829, SenderIP=76.201.159.224 References: <4929C6D8.7090305@freebsd.org> <20081124.105800.-267230932.imp@bsdimp.com> <4963AFE3.5080607@freebsd.org> <200901210843.33247.jhb@freebsd.org> User-Agent: Thunderbird 2.0.0.19 (X11/20090103) Cc: freebsd-arch@freebsd.org Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 15:44:56 -0000 John Baldwin wrote: > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote: >> M. Warner Losh wrote: >>> In message: <492AC8DE.6050902@freebsd.org> >>> Nathan Whitehorn writes: >>> : M. Warner Losh wrote: >>> : > In message: <4929C6D8.7090305@freebsd.org> >>> : > Nathan Whitehorn writes: >>> : > : RafaÅ‚ Jaworowski wrote: >>> : > : > >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Smørgrav wrote: >>> : > : > >>> : > : >> Nathan Whitehorn writes: >>> : > : >>> The current I2C bus mechanism does not support the bus adding > its own >>> : > : >>> children [...] >>> : > : >> >>> : > : >> That's because the I2C protocol does not support device > enumeration or >>> : > : >> identification. You have to know in advance what kind of devices > are >>> : > : >> attached and at what address. Even worse, it is not uncommon for >>> : > : >> similar but not entirely compatible devices to use the same I2C > address >>> : > : >> (for instance, every I2C-capable RTC chip uses the same address, > even >>> : > : >> though they have different feature sets) >>> : > : > >>> : > : > Well, hard-coded addresses and conflicting assignments between > vendors >>> : > : > do not technically prevent from scanning the bus; actually, our > current >>> : > : > iicbus code can do bus scaning when compiled with a diag define. > The >>> : > : > problem however is some slave devices are not well-behaved, and > they >>> : > : > don't like to be read/written to other than in very specific > scenario: >>> : > : > if polled during bus scan strange effects occur e.g. they > disappear from >>> : > : > the bus, or do not react to consecutive requests etc. >>> : > : >>> : > : All of this is true, but perhaps my question was badly worded. What > I am >>> : > : trying to figure out is how to shove information from an out-of-band >>> : > : source (Open Firmware, in this case) into newbus without disrupting >>> : > : existing code. In that way, my question is not I2C specific -- we > run >>> : > : into the same issue with the Open Firmware nexus node and > pseudo-devices >>> : > : like cryptosoft that attach themselves. >>> : > >>> : > You are looking at the problem incorrectly. In newbus, a case like >>> : > this the i2c bus should be a subclass (say i2c_of) that is derived >>> : > from the normal i2c bus stuff, but replaces the hints insertion of >>> : > devices with OF enumeration of devices. The OF higher levels will >>> : > already know to attach this kind of i2c bus to certain i2c >>> : > controllers, or always on certain platforms. >>> : >>> : Yes, this is exactly what I wanted to do, like how ofw_pci works. >>> : >>> : > : What I want to do is to have the I2C bus add the children that the >>> : > : firmware says it has. What the firmware cannot tell in advance, > however, >>> : > : is which FreeBSD driver is responsible for those devices, and so the > I2C >>> : > : bus driver can't know that without a translation table that I would >>> : > : prefer not to hack in to the bus driver. >>> : > >>> : > This is the bigger problem. Today, we are stuck with a lame table >>> : > that will translate the OF provided properties into FreeBSD driver >>> : > names. >>> : >>> : At the moment, I don't believe Apple uses any of the current very small >>> : number of I2C device drivers in tree. So I may skip the table for the >>> : time being, assuming the hack below is OK. In future, this may change, >>> : since G5 systems require software thermal control. But that will be the >>> : subject of another mail to this list... >>> : >>> : > : It seems reasonable to allow devices to use a real probe routine to > look >>> : > : at the firmware's name and compatible properties, like we allow on > other >>> : > : Open Firmware busses. The trouble is that existing drivers don't do >>> : > : this, because they expect to be attached with hints, so they will > attach >>> : > : to all devices. I'm trying to figure out how to avoid this. >>> : > : >>> : > : My basic question comes down to whether there is a good way in > newbus to >>> : > : handle busses that may be wholly or partially enumerated by firmware > or >>> : > : some other method, and may also have devices that can only attach >>> : > : themselves if told to by hints. >>> : > >>> : > Yes. This is a bit of a problem. The problem is that the existing >>> : > hints mechanism combines device tree and driver tree into one, and in >>> : > such a scenario, we wind up with the problem that you have. >>> : > >>> : > One could make the probe routines return BUS_PROBE_GENERIC, and that >>> : > would help somewhat. One could also have the probe routine check to >>> : > see if a specific driver is assigned to the device or not. That would >>> : > also help, but does mean changing all the i2c bus attached drivers in >>> : > the tree. >>> : >>> : I think changing existing I2C drivers may be unavoidable. Would there be >>> : any objection to changing the MI iicbus drivers to return >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been >>> : introduced (by you) to solve more or less exactly this problem. By my >>> : count, the relevant files are: >>> : dev/iicbus/ds133x.c >>> : dev/iicbus/icee.c >>> : dev/iicbus/ad7418.c >>> : dev/iicbus/iicsmb.c >>> : dev/iicbus/ds1672.c >>> : dev/iicbus/if_ic.c >>> : dev/iicbus/iic.c >>> : >>> : I would also like to change iicbus_probe to return -1000 like >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please let me >>> : know if this is a terrible idea or if I have forgotten any I2C device >>> : drivers. >>> >>> Short term, this is the right fix. There was an objection, I think by >>> Marcel, to this approach. However, his objections were part of a >>> larger set of objections and I think that we're working to solve >>> those. >>> >>> Warner >>> >> This is now in the tree. Now for part 2, which I had not considered >> previously: connecting the I2C bus layer to the I2C host adapters. >> >> Right now, we have the following: >> kiic/other i2c adapters >> ---iicbus >> ---ofw_iicbus >> >> Since kiic provides an Open Firmware node, ofw_iicbus gets priority, >> attaches, and everything after that is wonderful. The issue is how best >> to attach the iicbus modules to kiic. Current I2C controllers contain a >> line like this: >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0); >> >> This explicitly specifies that you want the standard driver, so we need >> additional glue to allow the ofw_iicbus driver to attach. One solution >> is that each relevant host adapter can add an additional DRIVER_MODULE >> line with the ofw_iicbus driver and class, which would have to exported >> in a header somewhere. This is pretty ugly. Another solution is for the >> ofw_iicbus module to grow a list of the names of interesting adapters. >> This is worse. >> >> The third option is to do what we do for pci, where all PCI adapters are >> named 'pcib'. So we could make new I2C host adapters named 'iichb' or >> something, and then move the DRIVER_MODULE logic for new code into the >> bus modules, as is done for PCI. This decreases the amount of >> information in the device names, but seems a bit cleaner. Thoughts? >> -Nathan > > If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same > functionality) similar to the OF-aware PCI bus, then I would go the PCI route > and just call it iicbus but give it a higher probe priority. > Which it is. What I meant was the bridge devices to which iicbus attaches. For pci, they all end up with the same name (pcib) so that the pci layer knows to attach to them. For I2C, they are called iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the standard iicbus to itself, instead of letting it and any firmware-aware versions probe. -Nathan From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 17:08:41 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E8B910656DB for ; Wed, 21 Jan 2009 17:08:41 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id A16558FC19 for ; Wed, 21 Jan 2009 17:08:40 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n0LH8daM011764; Wed, 21 Jan 2009 18:08:39 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n0LH8dsd032066; Wed, 21 Jan 2009 18:08:39 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n0LH8cmR011218; Date: Wed, 21 Jan 2009 18:08:38 +0100 From: Andre Albsmeier To: John Baldwin Message-ID: <20090121170838.GB94880@curry.mchp.siemens.de> References: <20081229212020.GA1809@curry.mchp.siemens.de> <20081229143221.X1076@desktop> <200901210847.05858.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901210847.05858.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Andre Albsmeier , freebsd-arch@freebsd.org Subject: Re: Two drivers, one physical device: How to deal with that? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 17:08:42 -0000 On Wed, 21-Jan-2009 at 08:47:05 -0500, John Baldwin wrote: > On Monday 29 December 2008 7:35:21 pm Jeff Roberson wrote: > > On Mon, 29 Dec 2008, Andre Albsmeier wrote: > > > > > Hello, > > > > > > I have written a driver which attaches to the host bridge in > > > order to periodically read the appropriate registers and > > > inform the user about ECC errors (ECC-Monitor). No I have > > > run across a mainboard where the host bridge is already > > > taken by the agp driver. Of course, I can detach the agp > > > driver and attach myself and everything is working but > > > what is if someone does not want to loose the agp > > > functionality? > > > > > > How does one deal with the case when two separate drivers > > > have to access the same device (the host bridge in my case)? > > > > > > I assume, the correct way would be to join the AGP and > > > ECC functionality in one driver but maybe there are other > > > tricks I am not aware of? > > > > Well I don't think it would be correct to merge two conceptually seperate > > drivers into one just to share the same device. It sounds like the right > > solution is to make a generic layer the attaches to the host bridge and > > arbitrates access to it. Then allow other device to find and communicate > > with this generic layer. For the host bridge this doesn't have to be > > particularly fancy. > > This is already the case in 7.0 and later where hostb(4) always attaches to > host bridges and agp(4) attaches to the hostb(4) devices. Thanks for the hint. I will try this as soon as I got my first 7.x system running. -Andre -- Es ist den Untertanen untersagt, den Massstab ihrer beschraenkten Einsicht an die Handlungen der Obrigkeit anzulegen. (Friedrich Wilhelm, Kurfuerst von Brandenburg, 1620 - 1688) From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 18:47:01 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49464106566C for ; Wed, 21 Jan 2009 18:47:01 +0000 (UTC) (envelope-from Steven.Sears@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0F88FC16 for ; Wed, 21 Jan 2009 18:47:01 +0000 (UTC) (envelope-from Steven.Sears@netapp.com) X-IronPort-AV: E=Sophos;i="4.37,301,1231142400"; d="scan'208";a="116298930" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 21 Jan 2009 10:18:53 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n0LIIAnl018446 for ; Wed, 21 Jan 2009 10:18:30 -0800 (PST) Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 10:16:14 -0800 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 13:16:09 -0500 Received: from 10.97.16.134 ([10.97.16.134]) by RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.119]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Jan 2009 18:15:21 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 21 Jan 2009 13:15:20 -0500 From: Steve Sears To: Message-ID: Thread-Topic: mtx_trylock and td_locks Thread-Index: Acl79DgWdq8LwOfnEd2sNAAf805ctw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jan 2009 18:16:10.0088 (UTC) FILETIME=[55F13E80:01C97BF4] Subject: mtx_trylock and td_locks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 18:47:01 -0000 I just discovered something that I would think would be documented somewhere, but my best google'ing turns up nary a mention of it. In debug builds thread->td_locks is incremented and decremented with mtx_lock, mtx_trylock, and mtx_unlock. However, if LOCK_DEBUG = 0 then mtx_lock() and mtx_unlock become inline routines that don't modify thread->td_locks. mtx_trylock() doesn't have a non-debug inline version, so it still increments the thread value. This means mtx_trylock() should not be used with mtx_unlock(), but rather should always be paired with mtx_unlock_flags() to ensure thread->td_locks receives proper accounting. Is this by design? Or a bug? mtx_trylock is not heavily used, so it's easy to understand that it may not have had as much attention as the other locking routines. Thanks, -Steve From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 20:09:30 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 514CA106567A; Wed, 21 Jan 2009 20:09:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 02C108FC2A; Wed, 21 Jan 2009 20:09:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 7C5EE46B09; Wed, 21 Jan 2009 15:09:29 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LK9NdQ035728; Wed, 21 Jan 2009 15:09:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nathan Whitehorn Date: Wed, 21 Jan 2009 11:10:33 -0500 User-Agent: KMail/1.9.7 References: <4929C6D8.7090305@freebsd.org> <200901210843.33247.jhb@freebsd.org> <49773596.2050700@freebsd.org> In-Reply-To: <49773596.2050700@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901211110.33961.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 15:09:23 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8885/Wed Jan 21 12:48:08 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 20:09:32 -0000 On Wednesday 21 January 2009 9:47:50 am Nathan Whitehorn wrote: > John Baldwin wrote: > > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote: > >> M. Warner Losh wrote: > >>> In message: <492AC8DE.6050902@freebsd.org> > >>> Nathan Whitehorn writes: > >>> : M. Warner Losh wrote: > >>> : > In message: <4929C6D8.7090305@freebsd.org> > >>> : > Nathan Whitehorn writes: > >>> : > : Rafa=C5=82 Jaworowski wrote: > >>> : > : >=20 > >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm=C3=B8rgrav wrote: > >>> : > : >=20 > >>> : > : >> Nathan Whitehorn writes: > >>> : > : >>> The current I2C bus mechanism does not support the bus addi= ng=20 > > its own > >>> : > : >>> children [...] > >>> : > : >> > >>> : > : >> That's because the I2C protocol does not support device=20 > > enumeration or > >>> : > : >> identification. You have to know in advance what kind of=20 devices=20 > > are > >>> : > : >> attached and at what address. Even worse, it is not uncommo= n=20 for > >>> : > : >> similar but not entirely compatible devices to use the same = I2C=20 > > address > >>> : > : >> (for instance, every I2C-capable RTC chip uses the same=20 address,=20 > > even > >>> : > : >> though they have different feature sets) > >>> : > : >=20 > >>> : > : > Well, hard-coded addresses and conflicting assignments betwee= n=20 > > vendors=20 > >>> : > : > do not technically prevent from scanning the bus; actually, o= ur=20 > > current=20 > >>> : > : > iicbus code can do bus scaning when compiled with a diag defi= ne.=20 > > The=20 > >>> : > : > problem however is some slave devices are not well-behaved, a= nd=20 > > they=20 > >>> : > : > don't like to be read/written to other than in very specific= =20 > > scenario:=20 > >>> : > : > if polled during bus scan strange effects occur e.g. they=20 > > disappear from=20 > >>> : > : > the bus, or do not react to consecutive requests etc. > >>> : > :=20 > >>> : > : All of this is true, but perhaps my question was badly worded.= =20 What=20 > > I am=20 > >>> : > : trying to figure out is how to shove information from an=20 out-of-band=20 > >>> : > : source (Open Firmware, in this case) into newbus without=20 disrupting=20 > >>> : > : existing code. In that way, my question is not I2C specific -- = we=20 > > run=20 > >>> : > : into the same issue with the Open Firmware nexus node and=20 > > pseudo-devices=20 > >>> : > : like cryptosoft that attach themselves. > >>> : >=20 > >>> : > You are looking at the problem incorrectly. In newbus, a case li= ke > >>> : > this the i2c bus should be a subclass (say i2c_of) that is derived > >>> : > from the normal i2c bus stuff, but replaces the hints insertion of > >>> : > devices with OF enumeration of devices. The OF higher levels will > >>> : > already know to attach this kind of i2c bus to certain i2c > >>> : > controllers, or always on certain platforms. > >>> :=20 > >>> : Yes, this is exactly what I wanted to do, like how ofw_pci works. > >>> :=20 > >>> : > : What I want to do is to have the I2C bus add the children that = the=20 > >>> : > : firmware says it has. What the firmware cannot tell in advance,= =20 > > however,=20 > >>> : > : is which FreeBSD driver is responsible for those devices, and s= o=20 the=20 > > I2C=20 > >>> : > : bus driver can't know that without a translation table that I=20 would=20 > >>> : > : prefer not to hack in to the bus driver. > >>> : >=20 > >>> : > This is the bigger problem. Today, we are stuck with a lame table > >>> : > that will translate the OF provided properties into FreeBSD driver > >>> : > names. > >>> :=20 > >>> : At the moment, I don't believe Apple uses any of the current very=20 small=20 > >>> : number of I2C device drivers in tree. So I may skip the table for t= he=20 > >>> : time being, assuming the hack below is OK. In future, this may chan= ge,=20 > >>> : since G5 systems require software thermal control. But that will be= =20 the=20 > >>> : subject of another mail to this list... > >>> :=20 > >>> : > : It seems reasonable to allow devices to use a real probe routin= e=20 to=20 > > look=20 > >>> : > : at the firmware's name and compatible properties, like we allow= on=20 > > other=20 > >>> : > : Open Firmware busses. The trouble is that existing drivers don'= t=20 do=20 > >>> : > : this, because they expect to be attached with hints, so they wi= ll=20 > > attach=20 > >>> : > : to all devices. I'm trying to figure out how to avoid this. > >>> : > :=20 > >>> : > : My basic question comes down to whether there is a good way in= =20 > > newbus to=20 > >>> : > : handle busses that may be wholly or partially enumerated by=20 firmware=20 > > or=20 > >>> : > : some other method, and may also have devices that can only atta= ch=20 > >>> : > : themselves if told to by hints. > >>> : >=20 > >>> : > Yes. This is a bit of a problem. The problem is that the existi= ng > >>> : > hints mechanism combines device tree and driver tree into one, an= d=20 in > >>> : > such a scenario, we wind up with the problem that you have. > >>> : >=20 > >>> : > One could make the probe routines return BUS_PROBE_GENERIC, and t= hat > >>> : > would help somewhat. One could also have the probe routine check= to > >>> : > see if a specific driver is assigned to the device or not. That= =20 would > >>> : > also help, but does mean changing all the i2c bus attached driver= s=20 in > >>> : > the tree. > >>> :=20 > >>> : I think changing existing I2C drivers may be unavoidable. Would the= re=20 be=20 > >>> : any objection to changing the MI iicbus drivers to return=20 > >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been= =20 > >>> : introduced (by you) to solve more or less exactly this problem. By = my=20 > >>> : count, the relevant files are: > >>> : dev/iicbus/ds133x.c > >>> : dev/iicbus/icee.c > >>> : dev/iicbus/ad7418.c > >>> : dev/iicbus/iicsmb.c > >>> : dev/iicbus/ds1672.c > >>> : dev/iicbus/if_ic.c > >>> : dev/iicbus/iic.c > >>> :=20 > >>> : I would also like to change iicbus_probe to return -1000 like=20 > >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please le= t=20 me=20 > >>> : know if this is a terrible idea or if I have forgotten any I2C devi= ce=20 > >>> : drivers. > >>> > >>> Short term, this is the right fix. There was an objection, I think by > >>> Marcel, to this approach. However, his objections were part of a > >>> larger set of objections and I think that we're working to solve > >>> those. > >>> > >>> Warner > >>> =20 > >> This is now in the tree. Now for part 2, which I had not considered=20 > >> previously: connecting the I2C bus layer to the I2C host adapters. > >> > >> Right now, we have the following: > >> kiic/other i2c adapters > >> ---iicbus > >> ---ofw_iicbus > >> > >> Since kiic provides an Open Firmware node, ofw_iicbus gets priority,=20 > >> attaches, and everything after that is wonderful. The issue is how bes= t=20 > >> to attach the iicbus modules to kiic. Current I2C controllers contain = a=20 > >> line like this: > >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0); > >> > >> This explicitly specifies that you want the standard driver, so we nee= d=20 > >> additional glue to allow the ofw_iicbus driver to attach. One solution= =20 > >> is that each relevant host adapter can add an additional DRIVER_MODULE= =20 > >> line with the ofw_iicbus driver and class, which would have to exporte= d=20 > >> in a header somewhere. This is pretty ugly. Another solution is for th= e=20 > >> ofw_iicbus module to grow a list of the names of interesting adapters.= =20 > >> This is worse. > >> > >> The third option is to do what we do for pci, where all PCI adapters a= re=20 > >> named 'pcib'. So we could make new I2C host adapters named 'iichb' or= =20 > >> something, and then move the DRIVER_MODULE logic for new code into the= =20 > >> bus modules, as is done for PCI. This decreases the amount of=20 > >> information in the device names, but seems a bit cleaner. Thoughts? > >> -Nathan > >=20 > > If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same=20 > > functionality) similar to the OF-aware PCI bus, then I would go the PCI= =20 route=20 > > and just call it iicbus but give it a higher probe priority. > >=20 >=20 > Which it is. What I meant was the bridge devices to which iicbus=20 > attaches. For pci, they all end up with the same name (pcib) so that the= =20 > pci layer knows to attach to them. For I2C, they are called=20 > iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the=20 > standard iicbus to itself, instead of letting it and any firmware-aware=20 > versions probe. I'm a bit torn on that one, especially since you have weird cases like one = of=20 the via parts that has both smbus and iicbus children. The other option would be to fix the attaching to subclasses thing (that=20 should make all pci drivers attach to cardbus0 devices since cardbus inheri= ts=20 from pci, for example) and then you could have what would basically be an=20 abstract base class "iicbridge" with no devmethods that all bridge drivers= =20 inherit from, and iicbus would attach to that. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 20:30:04 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE0F110658DD; Wed, 21 Jan 2009 20:30:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC958FC0A; Wed, 21 Jan 2009 20:30:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0LKRRWr028541; Wed, 21 Jan 2009 13:27:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 13:28:05 -0700 (MST) Message-Id: <20090121.132805.1108816677.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200901211110.33961.jhb@freebsd.org> References: <200901210843.33247.jhb@freebsd.org> <49773596.2050700@freebsd.org> <200901211110.33961.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: nwhitehorn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 20:30:05 -0000 SW4gbWVzc2FnZTogPDIwMDkwMTIxMTExMC4zMzk2MS5qaGJAZnJlZWJzZC5vcmc+DQogICAgICAg ICAgICBKb2huIEJhbGR3aW4gPGpoYkBGcmVlQlNELm9yZz4gd3JpdGVzOg0KOiBPbiBXZWRuZXNk YXkgMjEgSmFudWFyeSAyMDA5IDk6NDc6NTAgYW0gTmF0aGFuIFdoaXRlaG9ybiB3cm90ZToNCjog PiBKb2huIEJhbGR3aW4gd3JvdGU6DQo6ID4gPiBPbiBUdWVzZGF5IDA2IEphbnVhcnkgMjAwOSAy OjI0OjE5IHBtIE5hdGhhbiBXaGl0ZWhvcm4gd3JvdGU6DQo6ID4gPj4gTS4gV2FybmVyIExvc2gg d3JvdGU6DQo6ID4gPj4+IEluIG1lc3NhZ2U6IDw0OTJBQzhERS42MDUwOTAyQGZyZWVic2Qub3Jn Pg0KOiA+ID4+PiAgICAgICAgICAgICBOYXRoYW4gV2hpdGVob3JuIDxud2hpdGVob3JuQGZyZWVi c2Qub3JnPiB3cml0ZXM6DQo6ID4gPj4+IDogTS4gV2FybmVyIExvc2ggd3JvdGU6DQo6ID4gPj4+ IDogPiBJbiBtZXNzYWdlOiA8NDkyOUM2RDguNzA5MDMwNUBmcmVlYnNkLm9yZz4NCjogPiA+Pj4g OiA+ICAgICAgICAgICAgIE5hdGhhbiBXaGl0ZWhvcm4gPG53aGl0ZWhvcm5AZnJlZWJzZC5vcmc+ IHdyaXRlczoNCjogPiA+Pj4gOiA+IDogUmFmYcWCIEphd29yb3dza2kgd3JvdGU6DQo6ID4gPj4+ IDogPiA6ID4gDQo6ID4gPj4+IDogPiA6ID4gT24gMjAwOC0xMS0yMywgYXQgMTk6MTgsIERhZy1F cmxpbmcgU23DuHJncmF2IHdyb3RlOg0KOiA+ID4+PiA6ID4gOiA+IA0KOiA+ID4+PiA6ID4gOiA+ PiBOYXRoYW4gV2hpdGVob3JuIDxud2hpdGVob3JuQGZyZWVic2Qub3JnPiB3cml0ZXM6DQo6ID4g Pj4+IDogPiA6ID4+PiBUaGUgY3VycmVudCBJMkMgYnVzIG1lY2hhbmlzbSBkb2VzIG5vdCBzdXBw b3J0IHRoZSBidXMgYWRkaW5nIA0KOiA+ID4gaXRzIG93bg0KOiA+ID4+PiA6ID4gOiA+Pj4gY2hp bGRyZW4gWy4uLl0NCjogPiA+Pj4gOiA+IDogPj4NCjogPiA+Pj4gOiA+IDogPj4gVGhhdCdzIGJl Y2F1c2UgdGhlIEkyQyBwcm90b2NvbCBkb2VzIG5vdCBzdXBwb3J0IGRldmljZSANCjogPiA+IGVu dW1lcmF0aW9uIG9yDQo6ID4gPj4+IDogPiA6ID4+IGlkZW50aWZpY2F0aW9uLiAgWW91IGhhdmUg dG8ga25vdyBpbiBhZHZhbmNlIHdoYXQga2luZCBvZiANCjogZGV2aWNlcyANCjogPiA+IGFyZQ0K OiA+ID4+PiA6ID4gOiA+PiBhdHRhY2hlZCBhbmQgYXQgd2hhdCBhZGRyZXNzLiAgRXZlbiB3b3Jz ZSwgaXQgaXMgbm90IHVuY29tbW9uIA0KOiBmb3INCjogPiA+Pj4gOiA+IDogPj4gc2ltaWxhciBi dXQgbm90IGVudGlyZWx5IGNvbXBhdGlibGUgZGV2aWNlcyB0byB1c2UgdGhlIHNhbWUgSTJDIA0K OiA+ID4gYWRkcmVzcw0KOiA+ID4+PiA6ID4gOiA+PiAoZm9yIGluc3RhbmNlLCBldmVyeSBJMkMt Y2FwYWJsZSBSVEMgY2hpcCB1c2VzIHRoZSBzYW1lIA0KOiBhZGRyZXNzLCANCjogPiA+IGV2ZW4N CjogPiA+Pj4gOiA+IDogPj4gdGhvdWdoIHRoZXkgaGF2ZSBkaWZmZXJlbnQgZmVhdHVyZSBzZXRz KQ0KOiA+ID4+PiA6ID4gOiA+IA0KOiA+ID4+PiA6ID4gOiA+IFdlbGwsIGhhcmQtY29kZWQgYWRk cmVzc2VzIGFuZCBjb25mbGljdGluZyBhc3NpZ25tZW50cyBiZXR3ZWVuIA0KOiA+ID4gdmVuZG9y cyANCjogPiA+Pj4gOiA+IDogPiBkbyBub3QgdGVjaG5pY2FsbHkgcHJldmVudCBmcm9tIHNjYW5u aW5nIHRoZSBidXM7IGFjdHVhbGx5LCBvdXIgDQo6ID4gPiBjdXJyZW50IA0KOiA+ID4+PiA6ID4g OiA+IGlpY2J1cyBjb2RlIGNhbiBkbyBidXMgc2NhbmluZyB3aGVuIGNvbXBpbGVkIHdpdGggYSBk aWFnIGRlZmluZS4gDQo6ID4gPiBUaGUgDQo6ID4gPj4+IDogPiA6ID4gcHJvYmxlbSBob3dldmVy IGlzIHNvbWUgc2xhdmUgZGV2aWNlcyBhcmUgbm90IHdlbGwtYmVoYXZlZCwgYW5kIA0KOiA+ID4g dGhleSANCjogPiA+Pj4gOiA+IDogPiBkb24ndCBsaWtlIHRvIGJlIHJlYWQvd3JpdHRlbiB0byBv dGhlciB0aGFuIGluIHZlcnkgc3BlY2lmaWMgDQo6ID4gPiBzY2VuYXJpbzogDQo6ID4gPj4+IDog PiA6ID4gaWYgcG9sbGVkIGR1cmluZyBidXMgc2NhbiBzdHJhbmdlIGVmZmVjdHMgb2NjdXIgZS5n LiB0aGV5IA0KOiA+ID4gZGlzYXBwZWFyIGZyb20gDQo6ID4gPj4+IDogPiA6ID4gdGhlIGJ1cywg b3IgZG8gbm90IHJlYWN0IHRvIGNvbnNlY3V0aXZlIHJlcXVlc3RzIGV0Yy4NCjogPiA+Pj4gOiA+ IDogDQo6ID4gPj4+IDogPiA6IEFsbCBvZiB0aGlzIGlzIHRydWUsIGJ1dCBwZXJoYXBzIG15IHF1 ZXN0aW9uIHdhcyBiYWRseSB3b3JkZWQuIA0KOiBXaGF0IA0KOiA+ID4gSSBhbSANCjogPiA+Pj4g OiA+IDogdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaXMgaG93IHRvIHNob3ZlIGluZm9ybWF0aW9uIGZy b20gYW4gDQo6IG91dC1vZi1iYW5kIA0KOiA+ID4+PiA6ID4gOiBzb3VyY2UgKE9wZW4gRmlybXdh cmUsIGluIHRoaXMgY2FzZSkgaW50byBuZXdidXMgd2l0aG91dCANCjogZGlzcnVwdGluZyANCjog PiA+Pj4gOiA+IDogZXhpc3RpbmcgY29kZS4gSW4gdGhhdCB3YXksIG15IHF1ZXN0aW9uIGlzIG5v dCBJMkMgc3BlY2lmaWMgLS0gd2UgDQo6ID4gPiBydW4gDQo6ID4gPj4+IDogPiA6IGludG8gdGhl IHNhbWUgaXNzdWUgd2l0aCB0aGUgT3BlbiBGaXJtd2FyZSBuZXh1cyBub2RlIGFuZCANCjogPiA+ IHBzZXVkby1kZXZpY2VzIA0KOiA+ID4+PiA6ID4gOiBsaWtlIGNyeXB0b3NvZnQgdGhhdCBhdHRh Y2ggdGhlbXNlbHZlcy4NCjogPiA+Pj4gOiA+IA0KOiA+ID4+PiA6ID4gWW91IGFyZSBsb29raW5n IGF0IHRoZSBwcm9ibGVtIGluY29ycmVjdGx5LiAgSW4gbmV3YnVzLCBhIGNhc2UgbGlrZQ0KOiA+ ID4+PiA6ID4gdGhpcyB0aGUgaTJjIGJ1cyBzaG91bGQgYmUgYSBzdWJjbGFzcyAoc2F5IGkyY19v ZikgdGhhdCBpcyBkZXJpdmVkDQo6ID4gPj4+IDogPiBmcm9tIHRoZSBub3JtYWwgaTJjIGJ1cyBz dHVmZiwgYnV0IHJlcGxhY2VzIHRoZSBoaW50cyBpbnNlcnRpb24gb2YNCjogPiA+Pj4gOiA+IGRl dmljZXMgd2l0aCBPRiBlbnVtZXJhdGlvbiBvZiBkZXZpY2VzLiAgVGhlIE9GIGhpZ2hlciBsZXZl bHMgd2lsbA0KOiA+ID4+PiA6ID4gYWxyZWFkeSBrbm93IHRvIGF0dGFjaCB0aGlzIGtpbmQgb2Yg aTJjIGJ1cyB0byBjZXJ0YWluIGkyYw0KOiA+ID4+PiA6ID4gY29udHJvbGxlcnMsIG9yIGFsd2F5 cyBvbiBjZXJ0YWluIHBsYXRmb3Jtcy4NCjogPiA+Pj4gOiANCjogPiA+Pj4gOiBZZXMsIHRoaXMg aXMgZXhhY3RseSB3aGF0IEkgd2FudGVkIHRvIGRvLCBsaWtlIGhvdyBvZndfcGNpIHdvcmtzLg0K OiA+ID4+PiA6IA0KOiA+ID4+PiA6ID4gOiBXaGF0IEkgd2FudCB0byBkbyBpcyB0byBoYXZlIHRo ZSBJMkMgYnVzIGFkZCB0aGUgY2hpbGRyZW4gdGhhdCB0aGUgDQo6ID4gPj4+IDogPiA6IGZpcm13 YXJlIHNheXMgaXQgaGFzLiBXaGF0IHRoZSBmaXJtd2FyZSBjYW5ub3QgdGVsbCBpbiBhZHZhbmNl LCANCjogPiA+IGhvd2V2ZXIsIA0KOiA+ID4+PiA6ID4gOiBpcyB3aGljaCBGcmVlQlNEIGRyaXZl ciBpcyByZXNwb25zaWJsZSBmb3IgdGhvc2UgZGV2aWNlcywgYW5kIHNvIA0KOiB0aGUgDQo6ID4g PiBJMkMgDQo6ID4gPj4+IDogPiA6IGJ1cyBkcml2ZXIgY2FuJ3Qga25vdyB0aGF0IHdpdGhvdXQg YSB0cmFuc2xhdGlvbiB0YWJsZSB0aGF0IEkgDQo6IHdvdWxkIA0KOiA+ID4+PiA6ID4gOiBwcmVm ZXIgbm90IHRvIGhhY2sgaW4gdG8gdGhlIGJ1cyBkcml2ZXIuDQo6ID4gPj4+IDogPiANCjogPiA+ Pj4gOiA+IFRoaXMgaXMgdGhlIGJpZ2dlciBwcm9ibGVtLiAgVG9kYXksIHdlIGFyZSBzdHVjayB3 aXRoIGEgbGFtZSB0YWJsZQ0KOiA+ID4+PiA6ID4gdGhhdCB3aWxsIHRyYW5zbGF0ZSB0aGUgT0Yg cHJvdmlkZWQgcHJvcGVydGllcyBpbnRvIEZyZWVCU0QgZHJpdmVyDQo6ID4gPj4+IDogPiBuYW1l cy4NCjogPiA+Pj4gOiANCjogPiA+Pj4gOiBBdCB0aGUgbW9tZW50LCBJIGRvbid0IGJlbGlldmUg QXBwbGUgdXNlcyBhbnkgb2YgdGhlIGN1cnJlbnQgdmVyeSANCjogc21hbGwgDQo6ID4gPj4+IDog bnVtYmVyIG9mIEkyQyBkZXZpY2UgZHJpdmVycyBpbiB0cmVlLiBTbyBJIG1heSBza2lwIHRoZSB0 YWJsZSBmb3IgdGhlIA0KOiA+ID4+PiA6IHRpbWUgYmVpbmcsIGFzc3VtaW5nIHRoZSBoYWNrIGJl bG93IGlzIE9LLiBJbiBmdXR1cmUsIHRoaXMgbWF5IGNoYW5nZSwgDQo6ID4gPj4+IDogc2luY2Ug RzUgc3lzdGVtcyByZXF1aXJlIHNvZnR3YXJlIHRoZXJtYWwgY29udHJvbC4gQnV0IHRoYXQgd2ls bCBiZSANCjogdGhlIA0KOiA+ID4+PiA6IHN1YmplY3Qgb2YgYW5vdGhlciBtYWlsIHRvIHRoaXMg bGlzdC4uLg0KOiA+ID4+PiA6IA0KOiA+ID4+PiA6ID4gOiBJdCBzZWVtcyByZWFzb25hYmxlIHRv IGFsbG93IGRldmljZXMgdG8gdXNlIGEgcmVhbCBwcm9iZSByb3V0aW5lIA0KOiB0byANCjogPiA+ IGxvb2sgDQo6ID4gPj4+IDogPiA6IGF0IHRoZSBmaXJtd2FyZSdzIG5hbWUgYW5kIGNvbXBhdGli bGUgcHJvcGVydGllcywgbGlrZSB3ZSBhbGxvdyBvbiANCjogPiA+IG90aGVyIA0KOiA+ID4+PiA6 ID4gOiBPcGVuIEZpcm13YXJlIGJ1c3Nlcy4gVGhlIHRyb3VibGUgaXMgdGhhdCBleGlzdGluZyBk cml2ZXJzIGRvbid0IA0KOiBkbyANCjogPiA+Pj4gOiA+IDogdGhpcywgYmVjYXVzZSB0aGV5IGV4 cGVjdCB0byBiZSBhdHRhY2hlZCB3aXRoIGhpbnRzLCBzbyB0aGV5IHdpbGwgDQo6ID4gPiBhdHRh Y2ggDQo6ID4gPj4+IDogPiA6IHRvIGFsbCBkZXZpY2VzLiBJJ20gdHJ5aW5nIHRvIGZpZ3VyZSBv dXQgaG93IHRvIGF2b2lkIHRoaXMuDQo6ID4gPj4+IDogPiA6IA0KOiA+ID4+PiA6ID4gOiBNeSBi YXNpYyBxdWVzdGlvbiBjb21lcyBkb3duIHRvIHdoZXRoZXIgdGhlcmUgaXMgYSBnb29kIHdheSBp biANCjogPiA+IG5ld2J1cyB0byANCjogPiA+Pj4gOiA+IDogaGFuZGxlIGJ1c3NlcyB0aGF0IG1h eSBiZSB3aG9sbHkgb3IgcGFydGlhbGx5IGVudW1lcmF0ZWQgYnkgDQo6IGZpcm13YXJlIA0KOiA+ ID4gb3IgDQo6ID4gPj4+IDogPiA6IHNvbWUgb3RoZXIgbWV0aG9kLCBhbmQgbWF5IGFsc28gaGF2 ZSBkZXZpY2VzIHRoYXQgY2FuIG9ubHkgYXR0YWNoIA0KOiA+ID4+PiA6ID4gOiB0aGVtc2VsdmVz IGlmIHRvbGQgdG8gYnkgaGludHMuDQo6ID4gPj4+IDogPiANCjogPiA+Pj4gOiA+IFllcy4gIFRo aXMgaXMgYSBiaXQgb2YgYSBwcm9ibGVtLiAgVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgZXhpc3Rp bmcNCjogPiA+Pj4gOiA+IGhpbnRzIG1lY2hhbmlzbSBjb21iaW5lcyBkZXZpY2UgdHJlZSBhbmQg ZHJpdmVyIHRyZWUgaW50byBvbmUsIGFuZCANCjogaW4NCjogPiA+Pj4gOiA+IHN1Y2ggYSBzY2Vu YXJpbywgd2Ugd2luZCB1cCB3aXRoIHRoZSBwcm9ibGVtIHRoYXQgeW91IGhhdmUuDQo6ID4gPj4+ IDogPiANCjogPiA+Pj4gOiA+IE9uZSBjb3VsZCBtYWtlIHRoZSBwcm9iZSByb3V0aW5lcyByZXR1 cm4gQlVTX1BST0JFX0dFTkVSSUMsIGFuZCB0aGF0DQo6ID4gPj4+IDogPiB3b3VsZCBoZWxwIHNv bWV3aGF0LiAgT25lIGNvdWxkIGFsc28gaGF2ZSB0aGUgcHJvYmUgcm91dGluZSBjaGVjayB0bw0K OiA+ID4+PiA6ID4gc2VlIGlmIGEgc3BlY2lmaWMgZHJpdmVyIGlzIGFzc2lnbmVkIHRvIHRoZSBk ZXZpY2Ugb3Igbm90LiAgVGhhdCANCjogd291bGQNCjogPiA+Pj4gOiA+IGFsc28gaGVscCwgYnV0 IGRvZXMgbWVhbiBjaGFuZ2luZyBhbGwgdGhlIGkyYyBidXMgYXR0YWNoZWQgZHJpdmVycyANCjog aW4NCjogPiA+Pj4gOiA+IHRoZSB0cmVlLg0KOiA+ID4+PiA6IA0KOiA+ID4+PiA6IEkgdGhpbmsg Y2hhbmdpbmcgZXhpc3RpbmcgSTJDIGRyaXZlcnMgbWF5IGJlIHVuYXZvaWRhYmxlLiBXb3VsZCB0 aGVyZSANCjogYmUgDQo6ID4gPj4+IDogYW55IG9iamVjdGlvbiB0byBjaGFuZ2luZyB0aGUgTUkg aWljYnVzIGRyaXZlcnMgdG8gcmV0dXJuIA0KOiA+ID4+PiA6IEJVU19QUk9CRV9OT1dJTERDQVJE IGluIHRoZWlyIHByb2JlIHJvdXRpbmVzPyBJdCBzZWVtcyB0byBoYXZlIGJlZW4gDQo6ID4gPj4+ IDogaW50cm9kdWNlZCAoYnkgeW91KSB0byBzb2x2ZSBtb3JlIG9yIGxlc3MgZXhhY3RseSB0aGlz IHByb2JsZW0uIEJ5IG15IA0KOiA+ID4+PiA6IGNvdW50LCB0aGUgcmVsZXZhbnQgZmlsZXMgYXJl Og0KOiA+ID4+PiA6IGRldi9paWNidXMvZHMxMzN4LmMNCjogPiA+Pj4gOiBkZXYvaWljYnVzL2lj ZWUuYw0KOiA+ID4+PiA6IGRldi9paWNidXMvYWQ3NDE4LmMNCjogPiA+Pj4gOiBkZXYvaWljYnVz L2lpY3NtYi5jDQo6ID4gPj4+IDogZGV2L2lpY2J1cy9kczE2NzIuYw0KOiA+ID4+PiA6IGRldi9p aWNidXMvaWZfaWMuYw0KOiA+ID4+PiA6IGRldi9paWNidXMvaWljLmMNCjogPiA+Pj4gOiANCjog PiA+Pj4gOiBJIHdvdWxkIGFsc28gbGlrZSB0byBjaGFuZ2UgaWljYnVzX3Byb2JlIHRvIHJldHVy biAtMTAwMCBsaWtlIA0KOiA+ID4+PiA6IGRldi9wY2kvcGNpLmMgdG8gYWxsb3cgaXQgdG8gYmUg b3ZlcnJpZGRlbiBieSBhIHN1YmNsYXNzLiBQbGVhc2UgbGV0IA0KOiBtZSANCjogPiA+Pj4gOiBr bm93IGlmIHRoaXMgaXMgYSB0ZXJyaWJsZSBpZGVhIG9yIGlmIEkgaGF2ZSBmb3Jnb3R0ZW4gYW55 IEkyQyBkZXZpY2UgDQo6ID4gPj4+IDogZHJpdmVycy4NCjogPiA+Pj4NCjogPiA+Pj4gU2hvcnQg dGVybSwgdGhpcyBpcyB0aGUgcmlnaHQgZml4LiAgVGhlcmUgd2FzIGFuIG9iamVjdGlvbiwgSSB0 aGluayBieQ0KOiA+ID4+PiBNYXJjZWwsIHRvIHRoaXMgYXBwcm9hY2guICBIb3dldmVyLCBoaXMg b2JqZWN0aW9ucyB3ZXJlIHBhcnQgb2YgYQ0KOiA+ID4+PiBsYXJnZXIgc2V0IG9mIG9iamVjdGlv bnMgYW5kIEkgdGhpbmsgdGhhdCB3ZSdyZSB3b3JraW5nIHRvIHNvbHZlDQo6ID4gPj4+IHRob3Nl Lg0KOiA+ID4+Pg0KOiA+ID4+PiBXYXJuZXINCjogPiA+Pj4gICANCjogPiA+PiBUaGlzIGlzIG5v dyBpbiB0aGUgdHJlZS4gTm93IGZvciBwYXJ0IDIsIHdoaWNoIEkgaGFkIG5vdCBjb25zaWRlcmVk IA0KOiA+ID4+IHByZXZpb3VzbHk6IGNvbm5lY3RpbmcgdGhlIEkyQyBidXMgbGF5ZXIgdG8gdGhl IEkyQyBob3N0IGFkYXB0ZXJzLg0KOiA+ID4+DQo6ID4gPj4gUmlnaHQgbm93LCB3ZSBoYXZlIHRo ZSBmb2xsb3dpbmc6DQo6ID4gPj4ga2lpYy9vdGhlciBpMmMgYWRhcHRlcnMNCjogPiA+PiAtLS1p aWNidXMNCjogPiA+PiAtLS1vZndfaWljYnVzDQo6ID4gPj4NCjogPiA+PiBTaW5jZSBraWljIHBy b3ZpZGVzIGFuIE9wZW4gRmlybXdhcmUgbm9kZSwgb2Z3X2lpY2J1cyBnZXRzIHByaW9yaXR5LCAN CjogPiA+PiBhdHRhY2hlcywgYW5kIGV2ZXJ5dGhpbmcgYWZ0ZXIgdGhhdCBpcyB3b25kZXJmdWwu IFRoZSBpc3N1ZSBpcyBob3cgYmVzdCANCjogPiA+PiB0byBhdHRhY2ggdGhlIGlpY2J1cyBtb2R1 bGVzIHRvIGtpaWMuIEN1cnJlbnQgSTJDIGNvbnRyb2xsZXJzIGNvbnRhaW4gYSANCjogPiA+PiBs aW5lIGxpa2UgdGhpczoNCjogPiA+PiBEUklWRVJfTU9EVUxFKGlpY2J1cywgbWUsIGlpY2J1c19k cml2ZXIsIGlpY2J1c19kZXZjbGFzcywgMCwgMCk7DQo6ID4gPj4NCjogPiA+PiBUaGlzIGV4cGxp Y2l0bHkgc3BlY2lmaWVzIHRoYXQgeW91IHdhbnQgdGhlIHN0YW5kYXJkIGRyaXZlciwgc28gd2Ug bmVlZCANCjogPiA+PiBhZGRpdGlvbmFsIGdsdWUgdG8gYWxsb3cgdGhlIG9md19paWNidXMgZHJp dmVyIHRvIGF0dGFjaC4gT25lIHNvbHV0aW9uIA0KOiA+ID4+IGlzIHRoYXQgZWFjaCByZWxldmFu dCBob3N0IGFkYXB0ZXIgY2FuIGFkZCBhbiBhZGRpdGlvbmFsIERSSVZFUl9NT0RVTEUgDQo6ID4g Pj4gbGluZSB3aXRoIHRoZSBvZndfaWljYnVzIGRyaXZlciBhbmQgY2xhc3MsIHdoaWNoIHdvdWxk IGhhdmUgdG8gZXhwb3J0ZWQgDQo6ID4gPj4gaW4gYSBoZWFkZXIgc29tZXdoZXJlLiBUaGlzIGlz IHByZXR0eSB1Z2x5LiBBbm90aGVyIHNvbHV0aW9uIGlzIGZvciB0aGUgDQo6ID4gPj4gb2Z3X2lp Y2J1cyBtb2R1bGUgdG8gZ3JvdyBhIGxpc3Qgb2YgdGhlIG5hbWVzIG9mIGludGVyZXN0aW5nIGFk YXB0ZXJzLiANCjogPiA+PiBUaGlzIGlzIHdvcnNlLg0KOiA+ID4+DQo6ID4gPj4gVGhlIHRoaXJk IG9wdGlvbiBpcyB0byBkbyB3aGF0IHdlIGRvIGZvciBwY2ksIHdoZXJlIGFsbCBQQ0kgYWRhcHRl cnMgYXJlIA0KOiA+ID4+IG5hbWVkICdwY2liJy4gU28gd2UgY291bGQgbWFrZSBuZXcgSTJDIGhv c3QgYWRhcHRlcnMgbmFtZWQgJ2lpY2hiJyBvciANCjogPiA+PiBzb21ldGhpbmcsIGFuZCB0aGVu IG1vdmUgdGhlIERSSVZFUl9NT0RVTEUgbG9naWMgZm9yIG5ldyBjb2RlIGludG8gdGhlIA0KOiA+ ID4+IGJ1cyBtb2R1bGVzLCBhcyBpcyBkb25lIGZvciBQQ0kuIFRoaXMgZGVjcmVhc2VzIHRoZSBh bW91bnQgb2YgDQo6ID4gPj4gaW5mb3JtYXRpb24gaW4gdGhlIGRldmljZSBuYW1lcywgYnV0IHNl ZW1zIGEgYml0IGNsZWFuZXIuIFRob3VnaHRzPw0KOiA+ID4+IC1OYXRoYW4NCjogPiA+IA0KOiA+ ID4gSWYgb2Z3X2lpY2J1cyBpcyBzaW1wbHkgYW4gT0YtYXdhcmUgdmVyc2lvbiBvZiBpaWNidXMg KGkuZS4gc2FtZSANCjogPiA+IGZ1bmN0aW9uYWxpdHkpIHNpbWlsYXIgdG8gdGhlIE9GLWF3YXJl IFBDSSBidXMsIHRoZW4gSSB3b3VsZCBnbyB0aGUgUENJIA0KOiByb3V0ZSANCjogPiA+IGFuZCBq dXN0IGNhbGwgaXQgaWljYnVzIGJ1dCBnaXZlIGl0IGEgaGlnaGVyIHByb2JlIHByaW9yaXR5Lg0K OiA+ID4gDQo6ID4gDQo6ID4gV2hpY2ggaXQgaXMuIFdoYXQgSSBtZWFudCB3YXMgdGhlIGJyaWRn ZSBkZXZpY2VzIHRvIHdoaWNoIGlpY2J1cyANCjogPiBhdHRhY2hlcy4gRm9yIHBjaSwgdGhleSBh bGwgZW5kIHVwIHdpdGggdGhlIHNhbWUgbmFtZSAocGNpYikgc28gdGhhdCB0aGUgDQo6ID4gcGNp IGxheWVyIGtub3dzIHRvIGF0dGFjaCB0byB0aGVtLiBGb3IgSTJDLCB0aGV5IGFyZSBjYWxsZWQg DQo6ID4gaWljYmIvcGNmL2F0OTFfdHdpL2V0Yy4gYW5kIGVhY2ggYnJpZGdlIGRldmljZSBleHBs aWNpdGx5IGF0dGFjaGVzIHRoZSANCjogPiBzdGFuZGFyZCBpaWNidXMgdG8gaXRzZWxmLCBpbnN0 ZWFkIG9mIGxldHRpbmcgaXQgYW5kIGFueSBmaXJtd2FyZS1hd2FyZSANCjogPiB2ZXJzaW9ucyBw cm9iZS4NCjogDQo6IEknbSBhIGJpdCB0b3JuIG9uIHRoYXQgb25lLCBlc3BlY2lhbGx5IHNpbmNl IHlvdSBoYXZlIHdlaXJkIGNhc2VzIGxpa2Ugb25lIG9mIA0KOiB0aGUgdmlhIHBhcnRzIHRoYXQg aGFzIGJvdGggc21idXMgYW5kIGlpY2J1cyBjaGlsZHJlbi4NCjogDQo6IFRoZSBvdGhlciBvcHRp b24gd291bGQgYmUgdG8gZml4IHRoZSBhdHRhY2hpbmcgdG8gc3ViY2xhc3NlcyB0aGluZyAodGhh dCANCjogc2hvdWxkIG1ha2UgYWxsIHBjaSBkcml2ZXJzIGF0dGFjaCB0byBjYXJkYnVzMCBkZXZp Y2VzIHNpbmNlIGNhcmRidXMgaW5oZXJpdHMgDQo6IGZyb20gcGNpLCBmb3IgZXhhbXBsZSkgYW5k IHRoZW4geW91IGNvdWxkIGhhdmUgd2hhdCB3b3VsZCBiYXNpY2FsbHkgYmUgYW4gDQo6IGFic3Ry YWN0IGJhc2UgY2xhc3MgImlpY2JyaWRnZSIgd2l0aCBubyBkZXZtZXRob2RzIHRoYXQgYWxsIGJy aWRnZSBkcml2ZXJzIA0KOiBpbmhlcml0IGZyb20sIGFuZCBpaWNidXMgd291bGQgYXR0YWNoIHRv IHRoYXQuDQoNClJpZ2h0IG5vdywgdGhlIG9ubHkgYnVnIHRoYXQgSSBrbm93IGFib3V0IHdpdGgg dGhlIGNhcmRidXMgdnMgcGNpDQp0aGluZyBpcyB0aGF0IGtsZGxvYWQgZG9lc24ndCBuZWNlc3Nh cmlseSBwcm9iZS9hdHRhY2ggcGNpIGRyaXZlcnMgb24NCmEgY2FyZGJ1cyBidXMuICBPdGhlcndp c2UsIGl0IHdvcmtzIHBlcmZlY3RseS4gIFRoaXMgaXMgdGhlIG9ubHkNCnJlYXNvbiB0aGF0IHdl IGhhdmUgZHJpdmVyIGxpbmVzIHdpdGggY2FyZGJ1cyBhdHRhY2htZW50cyBpbiB0aGUgcGNpDQpk cml2ZXJzIGF0IGFsbC4uLg0KDQpXYXJuZXINCg== From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 23:11:18 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 569D5106567E; Wed, 21 Jan 2009 23:11:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A625D8FC0C; Wed, 21 Jan 2009 23:11:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3CCF246B09; Wed, 21 Jan 2009 18:11:17 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LNB5dc037051; Wed, 21 Jan 2009 18:11:11 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Wed, 21 Jan 2009 15:42:08 -0500 User-Agent: KMail/1.9.7 References: <200901210843.33247.jhb@freebsd.org> <200901211110.33961.jhb@freebsd.org> <20090121.132805.1108816677.imp@bsdimp.com> In-Reply-To: <20090121.132805.1108816677.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901211542.08461.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 18:11:11 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8885/Wed Jan 21 12:48:08 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: nwhitehorn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 23:11:18 -0000 On Wednesday 21 January 2009 3:28:05 pm M. Warner Losh wrote: > In message: <200901211110.33961.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 21 January 2009 9:47:50 am Nathan Whitehorn wrote: > : > John Baldwin wrote: > : > > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote: > : > >> M. Warner Losh wrote: > : > >>> In message: <492AC8DE.6050902@freebsd.org> > : > >>> Nathan Whitehorn writes: > : > >>> : M. Warner Losh wrote: > : > >>> : > In message: <4929C6D8.7090305@freebsd.org> > : > >>> : > Nathan Whitehorn writes: > : > >>> : > : Rafa=C5=82 Jaworowski wrote: > : > >>> : > : >=20 > : > >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm=C3=B8rgrav wrote: > : > >>> : > : >=20 > : > >>> : > : >> Nathan Whitehorn writes: > : > >>> : > : >>> The current I2C bus mechanism does not support the bus= =20 adding=20 > : > > its own > : > >>> : > : >>> children [...] > : > >>> : > : >> > : > >>> : > : >> That's because the I2C protocol does not support device= =20 > : > > enumeration or > : > >>> : > : >> identification. You have to know in advance what kind o= f=20 > : devices=20 > : > > are > : > >>> : > : >> attached and at what address. Even worse, it is not=20 uncommon=20 > : for > : > >>> : > : >> similar but not entirely compatible devices to use the s= ame=20 I2C=20 > : > > address > : > >>> : > : >> (for instance, every I2C-capable RTC chip uses the same= =20 > : address,=20 > : > > even > : > >>> : > : >> though they have different feature sets) > : > >>> : > : >=20 > : > >>> : > : > Well, hard-coded addresses and conflicting assignments=20 between=20 > : > > vendors=20 > : > >>> : > : > do not technically prevent from scanning the bus; actuall= y,=20 our=20 > : > > current=20 > : > >>> : > : > iicbus code can do bus scaning when compiled with a diag= =20 define.=20 > : > > The=20 > : > >>> : > : > problem however is some slave devices are not well-behave= d,=20 and=20 > : > > they=20 > : > >>> : > : > don't like to be read/written to other than in very speci= fic=20 > : > > scenario:=20 > : > >>> : > : > if polled during bus scan strange effects occur e.g. they= =20 > : > > disappear from=20 > : > >>> : > : > the bus, or do not react to consecutive requests etc. > : > >>> : > :=20 > : > >>> : > : All of this is true, but perhaps my question was badly word= ed.=20 > : What=20 > : > > I am=20 > : > >>> : > : trying to figure out is how to shove information from an=20 > : out-of-band=20 > : > >>> : > : source (Open Firmware, in this case) into newbus without=20 > : disrupting=20 > : > >>> : > : existing code. In that way, my question is not I2C specific= --=20 we=20 > : > > run=20 > : > >>> : > : into the same issue with the Open Firmware nexus node and=20 > : > > pseudo-devices=20 > : > >>> : > : like cryptosoft that attach themselves. > : > >>> : >=20 > : > >>> : > You are looking at the problem incorrectly. In newbus, a cas= e=20 like > : > >>> : > this the i2c bus should be a subclass (say i2c_of) that is=20 derived > : > >>> : > from the normal i2c bus stuff, but replaces the hints inserti= on=20 of > : > >>> : > devices with OF enumeration of devices. The OF higher levels= =20 will > : > >>> : > already know to attach this kind of i2c bus to certain i2c > : > >>> : > controllers, or always on certain platforms. > : > >>> :=20 > : > >>> : Yes, this is exactly what I wanted to do, like how ofw_pci work= s. > : > >>> :=20 > : > >>> : > : What I want to do is to have the I2C bus add the children t= hat=20 the=20 > : > >>> : > : firmware says it has. What the firmware cannot tell in=20 advance,=20 > : > > however,=20 > : > >>> : > : is which FreeBSD driver is responsible for those devices, a= nd=20 so=20 > : the=20 > : > > I2C=20 > : > >>> : > : bus driver can't know that without a translation table that= I=20 > : would=20 > : > >>> : > : prefer not to hack in to the bus driver. > : > >>> : >=20 > : > >>> : > This is the bigger problem. Today, we are stuck with a lame= =20 table > : > >>> : > that will translate the OF provided properties into FreeBSD=20 driver > : > >>> : > names. > : > >>> :=20 > : > >>> : At the moment, I don't believe Apple uses any of the current ve= ry=20 > : small=20 > : > >>> : number of I2C device drivers in tree. So I may skip the table f= or=20 the=20 > : > >>> : time being, assuming the hack below is OK. In future, this may= =20 change,=20 > : > >>> : since G5 systems require software thermal control. But that wil= l=20 be=20 > : the=20 > : > >>> : subject of another mail to this list... > : > >>> :=20 > : > >>> : > : It seems reasonable to allow devices to use a real probe=20 routine=20 > : to=20 > : > > look=20 > : > >>> : > : at the firmware's name and compatible properties, like we=20 allow on=20 > : > > other=20 > : > >>> : > : Open Firmware busses. The trouble is that existing drivers= =20 don't=20 > : do=20 > : > >>> : > : this, because they expect to be attached with hints, so the= y=20 will=20 > : > > attach=20 > : > >>> : > : to all devices. I'm trying to figure out how to avoid this. > : > >>> : > :=20 > : > >>> : > : My basic question comes down to whether there is a good way= in=20 > : > > newbus to=20 > : > >>> : > : handle busses that may be wholly or partially enumerated by= =20 > : firmware=20 > : > > or=20 > : > >>> : > : some other method, and may also have devices that can only= =20 attach=20 > : > >>> : > : themselves if told to by hints. > : > >>> : >=20 > : > >>> : > Yes. This is a bit of a problem. The problem is that the=20 existing > : > >>> : > hints mechanism combines device tree and driver tree into one= ,=20 and=20 > : in > : > >>> : > such a scenario, we wind up with the problem that you have. > : > >>> : >=20 > : > >>> : > One could make the probe routines return BUS_PROBE_GENERIC, a= nd=20 that > : > >>> : > would help somewhat. One could also have the probe routine=20 check to > : > >>> : > see if a specific driver is assigned to the device or not. T= hat=20 > : would > : > >>> : > also help, but does mean changing all the i2c bus attached=20 drivers=20 > : in > : > >>> : > the tree. > : > >>> :=20 > : > >>> : I think changing existing I2C drivers may be unavoidable. Would= =20 there=20 > : be=20 > : > >>> : any objection to changing the MI iicbus drivers to return=20 > : > >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have= =20 been=20 > : > >>> : introduced (by you) to solve more or less exactly this problem.= By=20 my=20 > : > >>> : count, the relevant files are: > : > >>> : dev/iicbus/ds133x.c > : > >>> : dev/iicbus/icee.c > : > >>> : dev/iicbus/ad7418.c > : > >>> : dev/iicbus/iicsmb.c > : > >>> : dev/iicbus/ds1672.c > : > >>> : dev/iicbus/if_ic.c > : > >>> : dev/iicbus/iic.c > : > >>> :=20 > : > >>> : I would also like to change iicbus_probe to return -1000 like=20 > : > >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Pleas= e=20 let=20 > : me=20 > : > >>> : know if this is a terrible idea or if I have forgotten any I2C= =20 device=20 > : > >>> : drivers. > : > >>> > : > >>> Short term, this is the right fix. There was an objection, I thi= nk=20 by > : > >>> Marcel, to this approach. However, his objections were part of a > : > >>> larger set of objections and I think that we're working to solve > : > >>> those. > : > >>> > : > >>> Warner > : > >>> =20 > : > >> This is now in the tree. Now for part 2, which I had not considere= d=20 > : > >> previously: connecting the I2C bus layer to the I2C host adapters. > : > >> > : > >> Right now, we have the following: > : > >> kiic/other i2c adapters > : > >> ---iicbus > : > >> ---ofw_iicbus > : > >> > : > >> Since kiic provides an Open Firmware node, ofw_iicbus gets priorit= y,=20 > : > >> attaches, and everything after that is wonderful. The issue is how= =20 best=20 > : > >> to attach the iicbus modules to kiic. Current I2C controllers cont= ain=20 a=20 > : > >> line like this: > : > >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0); > : > >> > : > >> This explicitly specifies that you want the standard driver, so we= =20 need=20 > : > >> additional glue to allow the ofw_iicbus driver to attach. One=20 solution=20 > : > >> is that each relevant host adapter can add an additional=20 DRIVER_MODULE=20 > : > >> line with the ofw_iicbus driver and class, which would have to=20 exported=20 > : > >> in a header somewhere. This is pretty ugly. Another solution is fo= r=20 the=20 > : > >> ofw_iicbus module to grow a list of the names of interesting=20 adapters.=20 > : > >> This is worse. > : > >> > : > >> The third option is to do what we do for pci, where all PCI adapte= rs=20 are=20 > : > >> named 'pcib'. So we could make new I2C host adapters named 'iichb'= or=20 > : > >> something, and then move the DRIVER_MODULE logic for new code into= =20 the=20 > : > >> bus modules, as is done for PCI. This decreases the amount of=20 > : > >> information in the device names, but seems a bit cleaner. Thoughts? > : > >> -Nathan > : > >=20 > : > > If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same=20 > : > > functionality) similar to the OF-aware PCI bus, then I would go the= =20 PCI=20 > : route=20 > : > > and just call it iicbus but give it a higher probe priority. > : > >=20 > : >=20 > : > Which it is. What I meant was the bridge devices to which iicbus=20 > : > attaches. For pci, they all end up with the same name (pcib) so that = the=20 > : > pci layer knows to attach to them. For I2C, they are called=20 > : > iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches th= e=20 > : > standard iicbus to itself, instead of letting it and any firmware-awa= re=20 > : > versions probe. > :=20 > : I'm a bit torn on that one, especially since you have weird cases like = one=20 of=20 > : the via parts that has both smbus and iicbus children. > :=20 > : The other option would be to fix the attaching to subclasses thing (tha= t=20 > : should make all pci drivers attach to cardbus0 devices since cardbus=20 inherits=20 > : from pci, for example) and then you could have what would basically be = an=20 > : abstract base class "iicbridge" with no devmethods that all bridge driv= ers=20 > : inherit from, and iicbus would attach to that. >=20 > Right now, the only bug that I know about with the cardbus vs pci > thing is that kldload doesn't necessarily probe/attach pci drivers on > a cardbus bus. Otherwise, it works perfectly. This is the only > reason that we have driver lines with cardbus attachments in the pci > drivers at all... That is the bug though. :) I've looked at it and I think I know how to fix= =20 it, I just haven't gotten around to it. I think device_probe_and_attach()= =20 needs to actually walk up the inheritance list of the current 'bus' driver,= =20 but only if all of the drivers for the current 'bus' failed to probe (or=20 there are no drivers). =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 23:30:09 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B4CE106566B; Wed, 21 Jan 2009 23:30:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id ABD998FC0C; Wed, 21 Jan 2009 23:30:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0LNTDWe030657; Wed, 21 Jan 2009 16:29:13 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 16:29:50 -0700 (MST) Message-Id: <20090121.162950.1552132922.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200901211542.08461.jhb@freebsd.org> References: <200901211110.33961.jhb@freebsd.org> <20090121.132805.1108816677.imp@bsdimp.com> <200901211542.08461.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: nwhitehorn@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 23:30:09 -0000 SW4gbWVzc2FnZTogPDIwMDkwMTIxMTU0Mi4wODQ2MS5qaGJAZnJlZWJzZC5vcmc+DQogICAgICAg ICAgICBKb2huIEJhbGR3aW4gPGpoYkBGcmVlQlNELm9yZz4gd3JpdGVzOg0KOiBPbiBXZWRuZXNk YXkgMjEgSmFudWFyeSAyMDA5IDM6Mjg6MDUgcG0gTS4gV2FybmVyIExvc2ggd3JvdGU6DQo6ID4g SW4gbWVzc2FnZTogPDIwMDkwMTIxMTExMC4zMzk2MS5qaGJAZnJlZWJzZC5vcmc+DQo6ID4gICAg ICAgICAgICAgSm9obiBCYWxkd2luIDxqaGJARnJlZUJTRC5vcmc+IHdyaXRlczoNCjogPiA6IE9u IFdlZG5lc2RheSAyMSBKYW51YXJ5IDIwMDkgOTo0Nzo1MCBhbSBOYXRoYW4gV2hpdGVob3JuIHdy b3RlOg0KOiA+IDogPiBKb2huIEJhbGR3aW4gd3JvdGU6DQo6ID4gOiA+ID4gT24gVHVlc2RheSAw NiBKYW51YXJ5IDIwMDkgMjoyNDoxOSBwbSBOYXRoYW4gV2hpdGVob3JuIHdyb3RlOg0KOiA+IDog PiA+PiBNLiBXYXJuZXIgTG9zaCB3cm90ZToNCjogPiA6ID4gPj4+IEluIG1lc3NhZ2U6IDw0OTJB QzhERS42MDUwOTAyQGZyZWVic2Qub3JnPg0KOiA+IDogPiA+Pj4gICAgICAgICAgICAgTmF0aGFu IFdoaXRlaG9ybiA8bndoaXRlaG9ybkBmcmVlYnNkLm9yZz4gd3JpdGVzOg0KOiA+IDogPiA+Pj4g OiBNLiBXYXJuZXIgTG9zaCB3cm90ZToNCjogPiA6ID4gPj4+IDogPiBJbiBtZXNzYWdlOiA8NDky OUM2RDguNzA5MDMwNUBmcmVlYnNkLm9yZz4NCjogPiA6ID4gPj4+IDogPiAgICAgICAgICAgICBO YXRoYW4gV2hpdGVob3JuIDxud2hpdGVob3JuQGZyZWVic2Qub3JnPiB3cml0ZXM6DQo6ID4gOiA+ ID4+PiA6ID4gOiBSYWZhxYIgSmF3b3Jvd3NraSB3cm90ZToNCjogPiA6ID4gPj4+IDogPiA6ID4g DQo6ID4gOiA+ID4+PiA6ID4gOiA+IE9uIDIwMDgtMTEtMjMsIGF0IDE5OjE4LCBEYWctRXJsaW5n IFNtw7hyZ3JhdiB3cm90ZToNCjogPiA6ID4gPj4+IDogPiA6ID4gDQo6ID4gOiA+ID4+PiA6ID4g OiA+PiBOYXRoYW4gV2hpdGVob3JuIDxud2hpdGVob3JuQGZyZWVic2Qub3JnPiB3cml0ZXM6DQo6 ID4gOiA+ID4+PiA6ID4gOiA+Pj4gVGhlIGN1cnJlbnQgSTJDIGJ1cyBtZWNoYW5pc20gZG9lcyBu b3Qgc3VwcG9ydCB0aGUgYnVzIA0KOiBhZGRpbmcgDQo6ID4gOiA+ID4gaXRzIG93bg0KOiA+IDog PiA+Pj4gOiA+IDogPj4+IGNoaWxkcmVuIFsuLi5dDQo6ID4gOiA+ID4+PiA6ID4gOiA+Pg0KOiA+ IDogPiA+Pj4gOiA+IDogPj4gVGhhdCdzIGJlY2F1c2UgdGhlIEkyQyBwcm90b2NvbCBkb2VzIG5v dCBzdXBwb3J0IGRldmljZSANCjogPiA6ID4gPiBlbnVtZXJhdGlvbiBvcg0KOiA+IDogPiA+Pj4g OiA+IDogPj4gaWRlbnRpZmljYXRpb24uICBZb3UgaGF2ZSB0byBrbm93IGluIGFkdmFuY2Ugd2hh dCBraW5kIG9mIA0KOiA+IDogZGV2aWNlcyANCjogPiA6ID4gPiBhcmUNCjogPiA6ID4gPj4+IDog PiA6ID4+IGF0dGFjaGVkIGFuZCBhdCB3aGF0IGFkZHJlc3MuICBFdmVuIHdvcnNlLCBpdCBpcyBu b3QgDQo6IHVuY29tbW9uIA0KOiA+IDogZm9yDQo6ID4gOiA+ID4+PiA6ID4gOiA+PiBzaW1pbGFy IGJ1dCBub3QgZW50aXJlbHkgY29tcGF0aWJsZSBkZXZpY2VzIHRvIHVzZSB0aGUgc2FtZSANCjog STJDIA0KOiA+IDogPiA+IGFkZHJlc3MNCjogPiA6ID4gPj4+IDogPiA6ID4+IChmb3IgaW5zdGFu Y2UsIGV2ZXJ5IEkyQy1jYXBhYmxlIFJUQyBjaGlwIHVzZXMgdGhlIHNhbWUgDQo6ID4gOiBhZGRy ZXNzLCANCjogPiA6ID4gPiBldmVuDQo6ID4gOiA+ID4+PiA6ID4gOiA+PiB0aG91Z2ggdGhleSBo YXZlIGRpZmZlcmVudCBmZWF0dXJlIHNldHMpDQo6ID4gOiA+ID4+PiA6ID4gOiA+IA0KOiA+IDog PiA+Pj4gOiA+IDogPiBXZWxsLCBoYXJkLWNvZGVkIGFkZHJlc3NlcyBhbmQgY29uZmxpY3Rpbmcg YXNzaWdubWVudHMgDQo6IGJldHdlZW4gDQo6ID4gOiA+ID4gdmVuZG9ycyANCjogPiA6ID4gPj4+ IDogPiA6ID4gZG8gbm90IHRlY2huaWNhbGx5IHByZXZlbnQgZnJvbSBzY2FubmluZyB0aGUgYnVz OyBhY3R1YWxseSwgDQo6IG91ciANCjogPiA6ID4gPiBjdXJyZW50IA0KOiA+IDogPiA+Pj4gOiA+ IDogPiBpaWNidXMgY29kZSBjYW4gZG8gYnVzIHNjYW5pbmcgd2hlbiBjb21waWxlZCB3aXRoIGEg ZGlhZyANCjogZGVmaW5lLiANCjogPiA6ID4gPiBUaGUgDQo6ID4gOiA+ID4+PiA6ID4gOiA+IHBy b2JsZW0gaG93ZXZlciBpcyBzb21lIHNsYXZlIGRldmljZXMgYXJlIG5vdCB3ZWxsLWJlaGF2ZWQs IA0KOiBhbmQgDQo6ID4gOiA+ID4gdGhleSANCjogPiA6ID4gPj4+IDogPiA6ID4gZG9uJ3QgbGlr ZSB0byBiZSByZWFkL3dyaXR0ZW4gdG8gb3RoZXIgdGhhbiBpbiB2ZXJ5IHNwZWNpZmljIA0KOiA+ IDogPiA+IHNjZW5hcmlvOiANCjogPiA6ID4gPj4+IDogPiA6ID4gaWYgcG9sbGVkIGR1cmluZyBi dXMgc2NhbiBzdHJhbmdlIGVmZmVjdHMgb2NjdXIgZS5nLiB0aGV5IA0KOiA+IDogPiA+IGRpc2Fw cGVhciBmcm9tIA0KOiA+IDogPiA+Pj4gOiA+IDogPiB0aGUgYnVzLCBvciBkbyBub3QgcmVhY3Qg dG8gY29uc2VjdXRpdmUgcmVxdWVzdHMgZXRjLg0KOiA+IDogPiA+Pj4gOiA+IDogDQo6ID4gOiA+ ID4+PiA6ID4gOiBBbGwgb2YgdGhpcyBpcyB0cnVlLCBidXQgcGVyaGFwcyBteSBxdWVzdGlvbiB3 YXMgYmFkbHkgd29yZGVkLiANCjogPiA6IFdoYXQgDQo6ID4gOiA+ID4gSSBhbSANCjogPiA6ID4g Pj4+IDogPiA6IHRyeWluZyB0byBmaWd1cmUgb3V0IGlzIGhvdyB0byBzaG92ZSBpbmZvcm1hdGlv biBmcm9tIGFuIA0KOiA+IDogb3V0LW9mLWJhbmQgDQo6ID4gOiA+ID4+PiA6ID4gOiBzb3VyY2Ug KE9wZW4gRmlybXdhcmUsIGluIHRoaXMgY2FzZSkgaW50byBuZXdidXMgd2l0aG91dCANCjogPiA6 IGRpc3J1cHRpbmcgDQo6ID4gOiA+ID4+PiA6ID4gOiBleGlzdGluZyBjb2RlLiBJbiB0aGF0IHdh eSwgbXkgcXVlc3Rpb24gaXMgbm90IEkyQyBzcGVjaWZpYyAtLSANCjogd2UgDQo6ID4gOiA+ID4g cnVuIA0KOiA+IDogPiA+Pj4gOiA+IDogaW50byB0aGUgc2FtZSBpc3N1ZSB3aXRoIHRoZSBPcGVu IEZpcm13YXJlIG5leHVzIG5vZGUgYW5kIA0KOiA+IDogPiA+IHBzZXVkby1kZXZpY2VzIA0KOiA+ IDogPiA+Pj4gOiA+IDogbGlrZSBjcnlwdG9zb2Z0IHRoYXQgYXR0YWNoIHRoZW1zZWx2ZXMuDQo6 ID4gOiA+ID4+PiA6ID4gDQo6ID4gOiA+ID4+PiA6ID4gWW91IGFyZSBsb29raW5nIGF0IHRoZSBw cm9ibGVtIGluY29ycmVjdGx5LiAgSW4gbmV3YnVzLCBhIGNhc2UgDQo6IGxpa2UNCjogPiA6ID4g Pj4+IDogPiB0aGlzIHRoZSBpMmMgYnVzIHNob3VsZCBiZSBhIHN1YmNsYXNzIChzYXkgaTJjX29m KSB0aGF0IGlzIA0KOiBkZXJpdmVkDQo6ID4gOiA+ID4+PiA6ID4gZnJvbSB0aGUgbm9ybWFsIGky YyBidXMgc3R1ZmYsIGJ1dCByZXBsYWNlcyB0aGUgaGludHMgaW5zZXJ0aW9uIA0KOiBvZg0KOiA+ IDogPiA+Pj4gOiA+IGRldmljZXMgd2l0aCBPRiBlbnVtZXJhdGlvbiBvZiBkZXZpY2VzLiAgVGhl IE9GIGhpZ2hlciBsZXZlbHMgDQo6IHdpbGwNCjogPiA6ID4gPj4+IDogPiBhbHJlYWR5IGtub3cg dG8gYXR0YWNoIHRoaXMga2luZCBvZiBpMmMgYnVzIHRvIGNlcnRhaW4gaTJjDQo6ID4gOiA+ID4+ PiA6ID4gY29udHJvbGxlcnMsIG9yIGFsd2F5cyBvbiBjZXJ0YWluIHBsYXRmb3Jtcy4NCjogPiA6 ID4gPj4+IDogDQo6ID4gOiA+ID4+PiA6IFllcywgdGhpcyBpcyBleGFjdGx5IHdoYXQgSSB3YW50 ZWQgdG8gZG8sIGxpa2UgaG93IG9md19wY2kgd29ya3MuDQo6ID4gOiA+ID4+PiA6IA0KOiA+IDog PiA+Pj4gOiA+IDogV2hhdCBJIHdhbnQgdG8gZG8gaXMgdG8gaGF2ZSB0aGUgSTJDIGJ1cyBhZGQg dGhlIGNoaWxkcmVuIHRoYXQgDQo6IHRoZSANCjogPiA6ID4gPj4+IDogPiA6IGZpcm13YXJlIHNh eXMgaXQgaGFzLiBXaGF0IHRoZSBmaXJtd2FyZSBjYW5ub3QgdGVsbCBpbiANCjogYWR2YW5jZSwg DQo6ID4gOiA+ID4gaG93ZXZlciwgDQo6ID4gOiA+ID4+PiA6ID4gOiBpcyB3aGljaCBGcmVlQlNE IGRyaXZlciBpcyByZXNwb25zaWJsZSBmb3IgdGhvc2UgZGV2aWNlcywgYW5kIA0KOiBzbyANCjog PiA6IHRoZSANCjogPiA6ID4gPiBJMkMgDQo6ID4gOiA+ID4+PiA6ID4gOiBidXMgZHJpdmVyIGNh bid0IGtub3cgdGhhdCB3aXRob3V0IGEgdHJhbnNsYXRpb24gdGFibGUgdGhhdCBJIA0KOiA+IDog d291bGQgDQo6ID4gOiA+ID4+PiA6ID4gOiBwcmVmZXIgbm90IHRvIGhhY2sgaW4gdG8gdGhlIGJ1 cyBkcml2ZXIuDQo6ID4gOiA+ID4+PiA6ID4gDQo6ID4gOiA+ID4+PiA6ID4gVGhpcyBpcyB0aGUg YmlnZ2VyIHByb2JsZW0uICBUb2RheSwgd2UgYXJlIHN0dWNrIHdpdGggYSBsYW1lIA0KOiB0YWJs ZQ0KOiA+IDogPiA+Pj4gOiA+IHRoYXQgd2lsbCB0cmFuc2xhdGUgdGhlIE9GIHByb3ZpZGVkIHBy b3BlcnRpZXMgaW50byBGcmVlQlNEIA0KOiBkcml2ZXINCjogPiA6ID4gPj4+IDogPiBuYW1lcy4N CjogPiA6ID4gPj4+IDogDQo6ID4gOiA+ID4+PiA6IEF0IHRoZSBtb21lbnQsIEkgZG9uJ3QgYmVs aWV2ZSBBcHBsZSB1c2VzIGFueSBvZiB0aGUgY3VycmVudCB2ZXJ5IA0KOiA+IDogc21hbGwgDQo6 ID4gOiA+ID4+PiA6IG51bWJlciBvZiBJMkMgZGV2aWNlIGRyaXZlcnMgaW4gdHJlZS4gU28gSSBt YXkgc2tpcCB0aGUgdGFibGUgZm9yIA0KOiB0aGUgDQo6ID4gOiA+ID4+PiA6IHRpbWUgYmVpbmcs IGFzc3VtaW5nIHRoZSBoYWNrIGJlbG93IGlzIE9LLiBJbiBmdXR1cmUsIHRoaXMgbWF5IA0KOiBj aGFuZ2UsIA0KOiA+IDogPiA+Pj4gOiBzaW5jZSBHNSBzeXN0ZW1zIHJlcXVpcmUgc29mdHdhcmUg dGhlcm1hbCBjb250cm9sLiBCdXQgdGhhdCB3aWxsIA0KOiBiZSANCjogPiA6IHRoZSANCjogPiA6 ID4gPj4+IDogc3ViamVjdCBvZiBhbm90aGVyIG1haWwgdG8gdGhpcyBsaXN0Li4uDQo6ID4gOiA+ ID4+PiA6IA0KOiA+IDogPiA+Pj4gOiA+IDogSXQgc2VlbXMgcmVhc29uYWJsZSB0byBhbGxvdyBk ZXZpY2VzIHRvIHVzZSBhIHJlYWwgcHJvYmUgDQo6IHJvdXRpbmUgDQo6ID4gOiB0byANCjogPiA6 ID4gPiBsb29rIA0KOiA+IDogPiA+Pj4gOiA+IDogYXQgdGhlIGZpcm13YXJlJ3MgbmFtZSBhbmQg Y29tcGF0aWJsZSBwcm9wZXJ0aWVzLCBsaWtlIHdlIA0KOiBhbGxvdyBvbiANCjogPiA6ID4gPiBv dGhlciANCjogPiA6ID4gPj4+IDogPiA6IE9wZW4gRmlybXdhcmUgYnVzc2VzLiBUaGUgdHJvdWJs ZSBpcyB0aGF0IGV4aXN0aW5nIGRyaXZlcnMgDQo6IGRvbid0IA0KOiA+IDogZG8gDQo6ID4gOiA+ ID4+PiA6ID4gOiB0aGlzLCBiZWNhdXNlIHRoZXkgZXhwZWN0IHRvIGJlIGF0dGFjaGVkIHdpdGgg aGludHMsIHNvIHRoZXkgDQo6IHdpbGwgDQo6ID4gOiA+ID4gYXR0YWNoIA0KOiA+IDogPiA+Pj4g OiA+IDogdG8gYWxsIGRldmljZXMuIEknbSB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gYXZv aWQgdGhpcy4NCjogPiA6ID4gPj4+IDogPiA6IA0KOiA+IDogPiA+Pj4gOiA+IDogTXkgYmFzaWMg cXVlc3Rpb24gY29tZXMgZG93biB0byB3aGV0aGVyIHRoZXJlIGlzIGEgZ29vZCB3YXkgaW4gDQo6 ID4gOiA+ID4gbmV3YnVzIHRvIA0KOiA+IDogPiA+Pj4gOiA+IDogaGFuZGxlIGJ1c3NlcyB0aGF0 IG1heSBiZSB3aG9sbHkgb3IgcGFydGlhbGx5IGVudW1lcmF0ZWQgYnkgDQo6ID4gOiBmaXJtd2Fy ZSANCjogPiA6ID4gPiBvciANCjogPiA6ID4gPj4+IDogPiA6IHNvbWUgb3RoZXIgbWV0aG9kLCBh bmQgbWF5IGFsc28gaGF2ZSBkZXZpY2VzIHRoYXQgY2FuIG9ubHkgDQo6IGF0dGFjaCANCjogPiA6 ID4gPj4+IDogPiA6IHRoZW1zZWx2ZXMgaWYgdG9sZCB0byBieSBoaW50cy4NCjogPiA6ID4gPj4+ IDogPiANCjogPiA6ID4gPj4+IDogPiBZZXMuICBUaGlzIGlzIGEgYml0IG9mIGEgcHJvYmxlbS4g IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIA0KOiBleGlzdGluZw0KOiA+IDogPiA+Pj4gOiA+IGhp bnRzIG1lY2hhbmlzbSBjb21iaW5lcyBkZXZpY2UgdHJlZSBhbmQgZHJpdmVyIHRyZWUgaW50byBv bmUsIA0KOiBhbmQgDQo6ID4gOiBpbg0KOiA+IDogPiA+Pj4gOiA+IHN1Y2ggYSBzY2VuYXJpbywg d2Ugd2luZCB1cCB3aXRoIHRoZSBwcm9ibGVtIHRoYXQgeW91IGhhdmUuDQo6ID4gOiA+ID4+PiA6 ID4gDQo6ID4gOiA+ID4+PiA6ID4gT25lIGNvdWxkIG1ha2UgdGhlIHByb2JlIHJvdXRpbmVzIHJl dHVybiBCVVNfUFJPQkVfR0VORVJJQywgYW5kIA0KOiB0aGF0DQo6ID4gOiA+ID4+PiA6ID4gd291 bGQgaGVscCBzb21ld2hhdC4gIE9uZSBjb3VsZCBhbHNvIGhhdmUgdGhlIHByb2JlIHJvdXRpbmUg DQo6IGNoZWNrIHRvDQo6ID4gOiA+ID4+PiA6ID4gc2VlIGlmIGEgc3BlY2lmaWMgZHJpdmVyIGlz IGFzc2lnbmVkIHRvIHRoZSBkZXZpY2Ugb3Igbm90LiAgVGhhdCANCjogPiA6IHdvdWxkDQo6ID4g OiA+ID4+PiA6ID4gYWxzbyBoZWxwLCBidXQgZG9lcyBtZWFuIGNoYW5naW5nIGFsbCB0aGUgaTJj IGJ1cyBhdHRhY2hlZCANCjogZHJpdmVycyANCjogPiA6IGluDQo6ID4gOiA+ID4+PiA6ID4gdGhl IHRyZWUuDQo6ID4gOiA+ID4+PiA6IA0KOiA+IDogPiA+Pj4gOiBJIHRoaW5rIGNoYW5naW5nIGV4 aXN0aW5nIEkyQyBkcml2ZXJzIG1heSBiZSB1bmF2b2lkYWJsZS4gV291bGQgDQo6IHRoZXJlIA0K OiA+IDogYmUgDQo6ID4gOiA+ID4+PiA6IGFueSBvYmplY3Rpb24gdG8gY2hhbmdpbmcgdGhlIE1J IGlpY2J1cyBkcml2ZXJzIHRvIHJldHVybiANCjogPiA6ID4gPj4+IDogQlVTX1BST0JFX05PV0lM RENBUkQgaW4gdGhlaXIgcHJvYmUgcm91dGluZXM/IEl0IHNlZW1zIHRvIGhhdmUgDQo6IGJlZW4g DQo6ID4gOiA+ID4+PiA6IGludHJvZHVjZWQgKGJ5IHlvdSkgdG8gc29sdmUgbW9yZSBvciBsZXNz IGV4YWN0bHkgdGhpcyBwcm9ibGVtLiBCeSANCjogbXkgDQo6ID4gOiA+ID4+PiA6IGNvdW50LCB0 aGUgcmVsZXZhbnQgZmlsZXMgYXJlOg0KOiA+IDogPiA+Pj4gOiBkZXYvaWljYnVzL2RzMTMzeC5j DQo6ID4gOiA+ID4+PiA6IGRldi9paWNidXMvaWNlZS5jDQo6ID4gOiA+ID4+PiA6IGRldi9paWNi dXMvYWQ3NDE4LmMNCjogPiA6ID4gPj4+IDogZGV2L2lpY2J1cy9paWNzbWIuYw0KOiA+IDogPiA+ Pj4gOiBkZXYvaWljYnVzL2RzMTY3Mi5jDQo6ID4gOiA+ID4+PiA6IGRldi9paWNidXMvaWZfaWMu Yw0KOiA+IDogPiA+Pj4gOiBkZXYvaWljYnVzL2lpYy5jDQo6ID4gOiA+ID4+PiA6IA0KOiA+IDog PiA+Pj4gOiBJIHdvdWxkIGFsc28gbGlrZSB0byBjaGFuZ2UgaWljYnVzX3Byb2JlIHRvIHJldHVy biAtMTAwMCBsaWtlIA0KOiA+IDogPiA+Pj4gOiBkZXYvcGNpL3BjaS5jIHRvIGFsbG93IGl0IHRv IGJlIG92ZXJyaWRkZW4gYnkgYSBzdWJjbGFzcy4gUGxlYXNlIA0KOiBsZXQgDQo6ID4gOiBtZSAN CjogPiA6ID4gPj4+IDoga25vdyBpZiB0aGlzIGlzIGEgdGVycmlibGUgaWRlYSBvciBpZiBJIGhh dmUgZm9yZ290dGVuIGFueSBJMkMgDQo6IGRldmljZSANCjogPiA6ID4gPj4+IDogZHJpdmVycy4N CjogPiA6ID4gPj4+DQo6ID4gOiA+ID4+PiBTaG9ydCB0ZXJtLCB0aGlzIGlzIHRoZSByaWdodCBm aXguICBUaGVyZSB3YXMgYW4gb2JqZWN0aW9uLCBJIHRoaW5rIA0KOiBieQ0KOiA+IDogPiA+Pj4g TWFyY2VsLCB0byB0aGlzIGFwcHJvYWNoLiAgSG93ZXZlciwgaGlzIG9iamVjdGlvbnMgd2VyZSBw YXJ0IG9mIGENCjogPiA6ID4gPj4+IGxhcmdlciBzZXQgb2Ygb2JqZWN0aW9ucyBhbmQgSSB0aGlu ayB0aGF0IHdlJ3JlIHdvcmtpbmcgdG8gc29sdmUNCjogPiA6ID4gPj4+IHRob3NlLg0KOiA+IDog PiA+Pj4NCjogPiA6ID4gPj4+IFdhcm5lcg0KOiA+IDogPiA+Pj4gICANCjogPiA6ID4gPj4gVGhp cyBpcyBub3cgaW4gdGhlIHRyZWUuIE5vdyBmb3IgcGFydCAyLCB3aGljaCBJIGhhZCBub3QgY29u c2lkZXJlZCANCjogPiA6ID4gPj4gcHJldmlvdXNseTogY29ubmVjdGluZyB0aGUgSTJDIGJ1cyBs YXllciB0byB0aGUgSTJDIGhvc3QgYWRhcHRlcnMuDQo6ID4gOiA+ID4+DQo6ID4gOiA+ID4+IFJp Z2h0IG5vdywgd2UgaGF2ZSB0aGUgZm9sbG93aW5nOg0KOiA+IDogPiA+PiBraWljL290aGVyIGky YyBhZGFwdGVycw0KOiA+IDogPiA+PiAtLS1paWNidXMNCjogPiA6ID4gPj4gLS0tb2Z3X2lpY2J1 cw0KOiA+IDogPiA+Pg0KOiA+IDogPiA+PiBTaW5jZSBraWljIHByb3ZpZGVzIGFuIE9wZW4gRmly bXdhcmUgbm9kZSwgb2Z3X2lpY2J1cyBnZXRzIHByaW9yaXR5LCANCjogPiA6ID4gPj4gYXR0YWNo ZXMsIGFuZCBldmVyeXRoaW5nIGFmdGVyIHRoYXQgaXMgd29uZGVyZnVsLiBUaGUgaXNzdWUgaXMg aG93IA0KOiBiZXN0IA0KOiA+IDogPiA+PiB0byBhdHRhY2ggdGhlIGlpY2J1cyBtb2R1bGVzIHRv IGtpaWMuIEN1cnJlbnQgSTJDIGNvbnRyb2xsZXJzIGNvbnRhaW4gDQo6IGEgDQo6ID4gOiA+ID4+ IGxpbmUgbGlrZSB0aGlzOg0KOiA+IDogPiA+PiBEUklWRVJfTU9EVUxFKGlpY2J1cywgbWUsIGlp Y2J1c19kcml2ZXIsIGlpY2J1c19kZXZjbGFzcywgMCwgMCk7DQo6ID4gOiA+ID4+DQo6ID4gOiA+ ID4+IFRoaXMgZXhwbGljaXRseSBzcGVjaWZpZXMgdGhhdCB5b3Ugd2FudCB0aGUgc3RhbmRhcmQg ZHJpdmVyLCBzbyB3ZSANCjogbmVlZCANCjogPiA6ID4gPj4gYWRkaXRpb25hbCBnbHVlIHRvIGFs bG93IHRoZSBvZndfaWljYnVzIGRyaXZlciB0byBhdHRhY2guIE9uZSANCjogc29sdXRpb24gDQo6 ID4gOiA+ID4+IGlzIHRoYXQgZWFjaCByZWxldmFudCBob3N0IGFkYXB0ZXIgY2FuIGFkZCBhbiBh ZGRpdGlvbmFsIA0KOiBEUklWRVJfTU9EVUxFIA0KOiA+IDogPiA+PiBsaW5lIHdpdGggdGhlIG9m d19paWNidXMgZHJpdmVyIGFuZCBjbGFzcywgd2hpY2ggd291bGQgaGF2ZSB0byANCjogZXhwb3J0 ZWQgDQo6ID4gOiA+ID4+IGluIGEgaGVhZGVyIHNvbWV3aGVyZS4gVGhpcyBpcyBwcmV0dHkgdWds eS4gQW5vdGhlciBzb2x1dGlvbiBpcyBmb3IgDQo6IHRoZSANCjogPiA6ID4gPj4gb2Z3X2lpY2J1 cyBtb2R1bGUgdG8gZ3JvdyBhIGxpc3Qgb2YgdGhlIG5hbWVzIG9mIGludGVyZXN0aW5nIA0KOiBh ZGFwdGVycy4gDQo6ID4gOiA+ID4+IFRoaXMgaXMgd29yc2UuDQo6ID4gOiA+ID4+DQo6ID4gOiA+ ID4+IFRoZSB0aGlyZCBvcHRpb24gaXMgdG8gZG8gd2hhdCB3ZSBkbyBmb3IgcGNpLCB3aGVyZSBh bGwgUENJIGFkYXB0ZXJzIA0KOiBhcmUgDQo6ID4gOiA+ID4+IG5hbWVkICdwY2liJy4gU28gd2Ug Y291bGQgbWFrZSBuZXcgSTJDIGhvc3QgYWRhcHRlcnMgbmFtZWQgJ2lpY2hiJyBvciANCjogPiA6 ID4gPj4gc29tZXRoaW5nLCBhbmQgdGhlbiBtb3ZlIHRoZSBEUklWRVJfTU9EVUxFIGxvZ2ljIGZv ciBuZXcgY29kZSBpbnRvIA0KOiB0aGUgDQo6ID4gOiA+ID4+IGJ1cyBtb2R1bGVzLCBhcyBpcyBk b25lIGZvciBQQ0kuIFRoaXMgZGVjcmVhc2VzIHRoZSBhbW91bnQgb2YgDQo6ID4gOiA+ID4+IGlu Zm9ybWF0aW9uIGluIHRoZSBkZXZpY2UgbmFtZXMsIGJ1dCBzZWVtcyBhIGJpdCBjbGVhbmVyLiBU aG91Z2h0cz8NCjogPiA6ID4gPj4gLU5hdGhhbg0KOiA+IDogPiA+IA0KOiA+IDogPiA+IElmIG9m d19paWNidXMgaXMgc2ltcGx5IGFuIE9GLWF3YXJlIHZlcnNpb24gb2YgaWljYnVzIChpLmUuIHNh bWUgDQo6ID4gOiA+ID4gZnVuY3Rpb25hbGl0eSkgc2ltaWxhciB0byB0aGUgT0YtYXdhcmUgUENJ IGJ1cywgdGhlbiBJIHdvdWxkIGdvIHRoZSANCjogUENJIA0KOiA+IDogcm91dGUgDQo6ID4gOiA+ ID4gYW5kIGp1c3QgY2FsbCBpdCBpaWNidXMgYnV0IGdpdmUgaXQgYSBoaWdoZXIgcHJvYmUgcHJp b3JpdHkuDQo6ID4gOiA+ID4gDQo6ID4gOiA+IA0KOiA+IDogPiBXaGljaCBpdCBpcy4gV2hhdCBJ IG1lYW50IHdhcyB0aGUgYnJpZGdlIGRldmljZXMgdG8gd2hpY2ggaWljYnVzIA0KOiA+IDogPiBh dHRhY2hlcy4gRm9yIHBjaSwgdGhleSBhbGwgZW5kIHVwIHdpdGggdGhlIHNhbWUgbmFtZSAocGNp Yikgc28gdGhhdCB0aGUgDQo6ID4gOiA+IHBjaSBsYXllciBrbm93cyB0byBhdHRhY2ggdG8gdGhl bS4gRm9yIEkyQywgdGhleSBhcmUgY2FsbGVkIA0KOiA+IDogPiBpaWNiYi9wY2YvYXQ5MV90d2kv ZXRjLiBhbmQgZWFjaCBicmlkZ2UgZGV2aWNlIGV4cGxpY2l0bHkgYXR0YWNoZXMgdGhlIA0KOiA+ IDogPiBzdGFuZGFyZCBpaWNidXMgdG8gaXRzZWxmLCBpbnN0ZWFkIG9mIGxldHRpbmcgaXQgYW5k IGFueSBmaXJtd2FyZS1hd2FyZSANCjogPiA6ID4gdmVyc2lvbnMgcHJvYmUuDQo6ID4gOiANCjog PiA6IEknbSBhIGJpdCB0b3JuIG9uIHRoYXQgb25lLCBlc3BlY2lhbGx5IHNpbmNlIHlvdSBoYXZl IHdlaXJkIGNhc2VzIGxpa2Ugb25lIA0KOiBvZiANCjogPiA6IHRoZSB2aWEgcGFydHMgdGhhdCBo YXMgYm90aCBzbWJ1cyBhbmQgaWljYnVzIGNoaWxkcmVuLg0KOiA+IDogDQo6ID4gOiBUaGUgb3Ro ZXIgb3B0aW9uIHdvdWxkIGJlIHRvIGZpeCB0aGUgYXR0YWNoaW5nIHRvIHN1YmNsYXNzZXMgdGhp bmcgKHRoYXQgDQo6ID4gOiBzaG91bGQgbWFrZSBhbGwgcGNpIGRyaXZlcnMgYXR0YWNoIHRvIGNh cmRidXMwIGRldmljZXMgc2luY2UgY2FyZGJ1cyANCjogaW5oZXJpdHMgDQo6ID4gOiBmcm9tIHBj aSwgZm9yIGV4YW1wbGUpIGFuZCB0aGVuIHlvdSBjb3VsZCBoYXZlIHdoYXQgd291bGQgYmFzaWNh bGx5IGJlIGFuIA0KOiA+IDogYWJzdHJhY3QgYmFzZSBjbGFzcyAiaWljYnJpZGdlIiB3aXRoIG5v IGRldm1ldGhvZHMgdGhhdCBhbGwgYnJpZGdlIGRyaXZlcnMgDQo6ID4gOiBpbmhlcml0IGZyb20s IGFuZCBpaWNidXMgd291bGQgYXR0YWNoIHRvIHRoYXQuDQo6ID4gDQo6ID4gUmlnaHQgbm93LCB0 aGUgb25seSBidWcgdGhhdCBJIGtub3cgYWJvdXQgd2l0aCB0aGUgY2FyZGJ1cyB2cyBwY2kNCjog PiB0aGluZyBpcyB0aGF0IGtsZGxvYWQgZG9lc24ndCBuZWNlc3NhcmlseSBwcm9iZS9hdHRhY2gg cGNpIGRyaXZlcnMgb24NCjogPiBhIGNhcmRidXMgYnVzLiAgT3RoZXJ3aXNlLCBpdCB3b3JrcyBw ZXJmZWN0bHkuICBUaGlzIGlzIHRoZSBvbmx5DQo6ID4gcmVhc29uIHRoYXQgd2UgaGF2ZSBkcml2 ZXIgbGluZXMgd2l0aCBjYXJkYnVzIGF0dGFjaG1lbnRzIGluIHRoZSBwY2kNCjogPiBkcml2ZXJz IGF0IGFsbC4uLg0KOiANCjogVGhhdCBpcyB0aGUgYnVnIHRob3VnaC4gOikgIEkndmUgbG9va2Vk IGF0IGl0IGFuZCBJIHRoaW5rIEkga25vdyBob3cgdG8gZml4IA0KOiBpdCwgSSBqdXN0IGhhdmVu J3QgZ290dGVuIGFyb3VuZCB0byBpdC4gIEkgdGhpbmsgZGV2aWNlX3Byb2JlX2FuZF9hdHRhY2go KSANCjogbmVlZHMgdG8gYWN0dWFsbHkgd2FsayB1cCB0aGUgaW5oZXJpdGFuY2UgbGlzdCBvZiB0 aGUgY3VycmVudCAnYnVzJyBkcml2ZXIsIA0KOiBidXQgb25seSBpZiBhbGwgb2YgdGhlIGRyaXZl cnMgZm9yIHRoZSBjdXJyZW50ICdidXMnIGZhaWxlZCB0byBwcm9iZSAob3IgDQo6IHRoZXJlIGFy ZSBubyBkcml2ZXJzKS4NCg0KQnV0IHdoeSB0aGVuIGRvZXMgaXQgd29yayB3aXRoIHRoZSBub3Jt YWwgcHJvYmUgYW5kIG9ubHkgZmFpbCBvbiB0aGUNCmxvYWQ/DQoNCldhcm5lcg0K From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 06:17:07 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F05CC1065677 for ; Thu, 22 Jan 2009 06:17:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 87F398FC0C for ; Thu, 22 Jan 2009 06:17:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10353 invoked by uid 399); 22 Jan 2009 05:50:26 -0000 Received: from localhost (HELO ?192.168.0.19?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Jan 2009 05:50:26 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4978093A.5060504@FreeBSD.org> Date: Wed, 21 Jan 2009 21:50:50 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andrew Hotlab References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ck@cksoft.de, freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 06:17:08 -0000 Andrew Hotlab wrote: > Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the > amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook) > # cd /usr/src > # make buildworld TARGET=i386 > # make installworld TARGET=i386 DESTDIR=/path-to-jail > # cd etc/ > # make distribution DESTDIR=/path-to-jail You can replace those last two lines with: mergemaster -i -A i386 -D /path-to-jail In previous incarnations mergemaster was less than completely effective *cough* in cross-build applications, but thanks to prodding from Sam and help from Ruslan it works now (where "now" means -current and 7-stable after the 7.1 release). hth, Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 15:42:33 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82F431065677; Thu, 22 Jan 2009 15:42:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 55A1B8FC24; Thu, 22 Jan 2009 15:42:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id D5B9546B0D; Thu, 22 Jan 2009 10:42:32 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0MFfgo7043174; Thu, 22 Jan 2009 10:42:27 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Thu, 22 Jan 2009 10:41:37 -0500 User-Agent: KMail/1.9.7 References: <200901211110.33961.jhb@freebsd.org> <200901211542.08461.jhb@freebsd.org> <20090121.162950.1552132922.imp@bsdimp.com> In-Reply-To: <20090121.162950.1552132922.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901221041.38286.jhb@freebsd.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 22 Jan 2009 10:42:27 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8892/Thu Jan 22 09:34:53 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: nwhitehorn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:42:33 -0000 On Wednesday 21 January 2009 6:29:50 pm M. Warner Losh wrote: > In message: <200901211542.08461.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 21 January 2009 3:28:05 pm M. Warner Losh wrote: > : > Right now, the only bug that I know about with the cardbus vs pci > : > thing is that kldload doesn't necessarily probe/attach pci drivers on > : > a cardbus bus. Otherwise, it works perfectly. This is the only > : > reason that we have driver lines with cardbus attachments in the pci > : > drivers at all... > : > : That is the bug though. :) I've looked at it and I think I know how to fix > : it, I just haven't gotten around to it. I think device_probe_and_attach() > : needs to actually walk up the inheritance list of the current 'bus' driver, > : but only if all of the drivers for the current 'bus' failed to probe (or > : there are no drivers). > > But why then does it work with the normal probe and only fail on the > load? I think it has to do with the fact that we attempt to store parents of devclasses and walk that tree, when instead we should probably walk the inheritance tree of the parent device's driver instead. That is, instead of doing this: for (; dc; dc = dc->parent) { } It should be something more like this: driver_t parent_driver; parent_driver = device_get_driver(bus); for (dc = driver_first_devclass(parent_driver); dc; dc = driver_next_devclass(parent_driver, dc)) { } driver_first_devclass() would be the devclass of the parent driver, and driver_next_devclass() (which may be all we really need) would have to iterate over the parent superclasses of 'parent_driver'. It might be a bit tricky to do anything more than a very simple first-pass of depth-first though for the traversal. Doing a full superclass traversal in a sane order (since kobj supports multiple inheritance) might prove very problematic. -- John Baldwin