From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 04:19:25 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E19EE61C; Sun, 2 Dec 2012 04:19:25 +0000 (UTC) (envelope-from eike@inter.net) Received: from tequila.ops.eusc.inter.net (tequila.ops.eusc.inter.net [84.23.254.157]) by mx1.freebsd.org (Postfix) with ESMTP id 925F68FC13; Sun, 2 Dec 2012 04:19:25 +0000 (UTC) X-Trace: 507c65696b6540736e6166752e64657c39332e3232302e39392e3139317c315466 3131522d30303036546e2d476f7c31333534343231393537 Received: from tequila.ops.eusc.inter.net ([10.157.10.19] helo=localhost) by tequila.ops.eusc.inter.net with esmtpsa (Exim 4.75) id 1Tf11R-0006Tn-Go; Sun, 02 Dec 2012 05:19:17 +0100 Subject: Re: [RFC] Remove i386 from bsd.cpu.mk Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eike Dierks In-Reply-To: <50BA18CB.2080001@FreeBSD.org> Date: Sun, 2 Dec 2012 05:19:16 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <50B7E2D3.6070206@FreeBSD.org> <50BA18CB.2080001@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1085) X-SA-Exim-Connect-IP: 93.220.99.191 X-SA-Exim-Mail-From: eike@inter.net X-SA-Exim-Scanned: No (on tequila.ops.eusc.inter.net); SAEximRunCond expanded to false Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 04:19:26 -0000 i386 will then still be supported by netbsd. so nothing is lost. we might even be a bit more aggressive on getting rid of that old cruft. the freebsd kernel should be tuned towards the recent cpus. Is there anyone working on transactional memory? ~eike On Dec 1, 2012, at 15:48 , Dimitry Andric wrote: > On 2012-11-29 23:33, Jung-uk Kim wrote: >> I'd like to remove i386 from bsd.cpu.mk on head. Please see the >> attachment. It is also available from here: >> >> http://people.freebsd.org/~jkim/cpu-i386.diff >> >> Any objection? > > No, please commit. Deorbit of i386 complete! ;) > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 04:22:56 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 065367FE for ; Sun, 2 Dec 2012 04:22:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by mx1.freebsd.org (Postfix) with ESMTP id AF1398FC12 for ; Sun, 2 Dec 2012 04:22:55 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id 13so2864625iea.35 for ; Sat, 01 Dec 2012 20:22:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=tJLlBtZJDMnT8rw5qOvIAJuPEaPCG+KSrTmZ4lLBHoc=; b=bxsLY79wi1YKSOMULheqqIDx8XDX9QhkmkO3UjwPkVfcnuyjo8H7aoYFZV0BDs18CP b3z9nAMdwJULDrWYGq3fgTzACKt7sQeEJa7bzXXISg4BgEHW2kR7qiLdqP+kkmW93vWZ xYvQPtyv2YTDsUh43lOEt8mUianUzdTUX/jlxUBsdJuZj9NW1HOumdijA34WaUi4PKQx jh3GND3n/zsIAyObscCTLjQp9GSt4qiwCPY3tMTkAg4qWX4W/J3xiWNeGRhvKKyzPSbm Yqlbj3gEaysNSE54dKmPVbu4GZ2/bdLwdgTZNdIp8AoeNWrfgF65B5yBwjyaR4XKeejb WUpA== Received: by 10.50.91.168 with SMTP id cf8mr2718019igb.20.1354422174574; Sat, 01 Dec 2012 20:22:54 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id yf6sm4005901igb.0.2012.12.01.20.22.50 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 20:22:52 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] Remove i386 from bsd.cpu.mk Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 1 Dec 2012 21:22:48 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7CE08ADD-F314-4912-9211-22B1BDF654E4@bsdimp.com> References: <50B7E2D3.6070206@FreeBSD.org> <50BA18CB.2080001@FreeBSD.org> To: Eike Dierks X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlAILLovUwMh0C24dcCXsA2LkxPJIOXq67g653VavIVBtSy9/TwlQDGReaksr4jIU9HIB12 Cc: Dimitry Andric , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 04:22:56 -0000 On Dec 1, 2012, at 9:19 PM, Eike Dierks wrote: > i386 will then still be supported by netbsd. > so nothing is lost. FreeBSD removed i386 support years ago. > we might even be a bit more aggressive > on getting rid of that old cruft. > > the freebsd kernel should be tuned towards > the recent cpus. This is already done. Warner > > Is there anyone working on transactional memory? > ~eike > > > > > > > > > > > > > On Dec 1, 2012, at 15:48 , Dimitry Andric wrote: > >> On 2012-11-29 23:33, Jung-uk Kim wrote: >>> I'd like to remove i386 from bsd.cpu.mk on head. Please see the >>> attachment. It is also available from here: >>> >>> http://people.freebsd.org/~jkim/cpu-i386.diff >>> >>> Any objection? >> >> No, please commit. Deorbit of i386 complete! ;) >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 16:28:15 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F9E4E2C; Sun, 2 Dec 2012 16:28:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7AC8FC1B; Sun, 2 Dec 2012 16:28:15 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D270546B17; Sun, 2 Dec 2012 11:28:14 -0500 (EST) Date: Sun, 2 Dec 2012 16:28:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Warner Losh Subject: Re: [RFC] Remove i386 from bsd.cpu.mk In-Reply-To: <7CE08ADD-F314-4912-9211-22B1BDF654E4@bsdimp.com> Message-ID: References: <50B7E2D3.6070206@FreeBSD.org> <50BA18CB.2080001@FreeBSD.org> <7CE08ADD-F314-4912-9211-22B1BDF654E4@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dimitry Andric , Eike Dierks , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 16:28:15 -0000 On Sat, 1 Dec 2012, Warner Losh wrote: > On Dec 1, 2012, at 9:19 PM, Eike Dierks wrote: >> i386 will then still be supported by netbsd. so nothing is lost. > > FreeBSD removed i386 support years ago. While this may seem pedantic, it's probably worth it for the benefit of later search engine queries and confused readers: at the time of writing, FreeBSD had removed support for 80386, rather than i386, years ago. :-) (Since we overload i386 to also mean i486 in an architecture naming sense, ...) Robert > >> we might even be a bit more aggressive >> on getting rid of that old cruft. >> >> the freebsd kernel should be tuned towards >> the recent cpus. > > This is already done. > > Warner > >> >> Is there anyone working on transactional memory? >> ~eike >> >> >> >> >> >> >> >> >> >> >> >> >> On Dec 1, 2012, at 15:48 , Dimitry Andric wrote: >> >>> On 2012-11-29 23:33, Jung-uk Kim wrote: >>>> I'd like to remove i386 from bsd.cpu.mk on head. Please see the >>>> attachment. It is also available from here: >>>> >>>> http://people.freebsd.org/~jkim/cpu-i386.diff >>>> >>>> Any objection? >>> >>> No, please commit. Deorbit of i386 complete! ;) >>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 17:11:39 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C73634E8 for ; Sun, 2 Dec 2012 17:11:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA2A8FC13 for ; Sun, 2 Dec 2012 17:11:39 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id c14so3506653ieb.0 for ; Sun, 02 Dec 2012 09:11:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=M/UOPkCiUuXMUJZDELj3qN7j9EVILsOODp5kKGratjk=; b=m0x9+FPOQTJPcSKjtI1A8Qz9n7KFP5/0WDAl2GfLW/HvkftVko6Q/TSzLgq3YN+giX WEQrCBcXfsb7Xpuft516//RJi/w07ED8sUNa9wxEsOp8/4dtbDtj/IbvswMc22uadtNs ecWaAY6OOYt3rUrn9n8g4XEME5q1gPb7+TVWhvWAtlbx43ooC10IdpgC2kr69N5AZQaH QopodoteLLwfW+CcW960syrNG/Td2DFRIN98Zy+AJgOTcpaHemAGyIKwVPXVKz8e7reo kpJvr1NYubYWtRto05w5cICBxjHfzSBVyclRWXB+vpyBxholql92T1suuKVZUShkehDe krFQ== Received: by 10.50.151.238 with SMTP id ut14mr3893638igb.72.1354467931730; Sun, 02 Dec 2012 09:05:31 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id bh3sm4850412igc.0.2012.12.02.09.05.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 09:05:30 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] Remove i386 from bsd.cpu.mk Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 2 Dec 2012 10:05:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B7E2D3.6070206@FreeBSD.org> <50BA18CB.2080001@FreeBSD.org> <7CE08ADD-F314-4912-9211-22B1BDF654E4@bsdimp.com> To: Robert Watson X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkjyAc7p4SXMwiXeMH3YiumKIiWGlBUj9lqVN+wIynbhHsiJi2Ci1rkaWGzeaxKLydJOWzi Cc: Dimitry Andric , Eike Dierks , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 17:11:40 -0000 On Dec 2, 2012, at 9:28 AM, Robert Watson wrote: >=20 > On Sat, 1 Dec 2012, Warner Losh wrote: >=20 >> On Dec 1, 2012, at 9:19 PM, Eike Dierks wrote: >>> i386 will then still be supported by netbsd. so nothing is lost. >>=20 >> FreeBSD removed i386 support years ago. >=20 > While this may seem pedantic, it's probably worth it for the benefit = of later search engine queries and confused readers: at the time of = writing, FreeBSD had removed support for 80386, rather than i386, years = ago. :-) >=20 > (Since we overload i386 to also mean i486 in an architecture naming = sense, ...) True. We removed the kernel support for the 80386SX, DX and EX and = clones years ago. We kept the userland support for 80386 since it = lacked the compare and exchange instructions for a few years more, but = that too is many years out of the tree. The name i386 is more used to = mean x86-32, ia32, or any other way to designate the 32-bit version of = the architecture. Or the family of processors starting with 80386. > Robert >=20 >=20 >>=20 >>> we might even be a bit more aggressive >>> on getting rid of that old cruft. >>>=20 >>> the freebsd kernel should be tuned towards >>> the recent cpus. >>=20 >> This is already done. >>=20 >> Warner >>=20 >>>=20 >>> Is there anyone working on transactional memory? >>> ~eike >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Dec 1, 2012, at 15:48 , Dimitry Andric wrote: >>>=20 >>>> On 2012-11-29 23:33, Jung-uk Kim wrote: >>>>> I'd like to remove i386 from bsd.cpu.mk on head. Please see the >>>>> attachment. It is also available from here: >>>>>=20 >>>>> http://people.freebsd.org/~jkim/cpu-i386.diff >>>>>=20 >>>>> Any objection? >>>>=20 >>>> No, please commit. Deorbit of i386 complete! ;) >>>>=20 >>>> _______________________________________________ >>>> freebsd-arch@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>>> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >>>=20 >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >>=20 >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >>=20 From owner-freebsd-arch@FreeBSD.ORG Mon Dec 3 19:45:47 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4067AB17 for ; Mon, 3 Dec 2012 19:45:47 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F392A8FC12 for ; Mon, 3 Dec 2012 19:45:46 +0000 (UTC) Message-ID: <50BD012E.1070706@FreeBSD.org> Date: Mon, 03 Dec 2012 14:44:46 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: [RFC] Remove i386 from bsd.cpu.mk References: <50B7E2D3.6070206@FreeBSD.org> In-Reply-To: <50B7E2D3.6070206@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:45:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-29 17:33:55 -0500, Jung-uk Kim wrote: > I'd like to remove i386 from bsd.cpu.mk on head. Please see the > attachment. It is also available from here: > > http://people.freebsd.org/~jkim/cpu-i386.diff > > Any objection? Committed (r243831). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQvQEuAAoJECXpabHZMqHO3N8H/jDkxvsobyWxjzKmJBaDka81 nhVGbFslfwZ6j9qQw2srv+gtgsS6AtwFObDbx0+qi1pSIghdQeoxUAHI/1cIOInT 39SgBR/YKTDzArjmYpKP6JMj4i5cPuCRz8DCC9Y1bTkIbLUOU6II29fwDi4AJXXl imAlSKI193GVeBYTqpbj8n6/Wbnuw2J8By0AeheQv4l8XsIKS1aKZclmXBYichWY dH/MXNPVd1ViuCncDCGCSIXtTVK3D85oSUKbQdbZYwp5yrqZ4IgokWgCl3sERtpv bqc9gMEg/Ij0TzawROlIMmEf6qdyLE8wVe7Xy+Ap+qdA4e7Q/KvDqmaiWR3JEwA= =B4a2 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 4 19:19:16 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E69B6F5F for ; Tue, 4 Dec 2012 19:19:15 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88E4D8FC0C for ; Tue, 4 Dec 2012 19:19:15 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo14so4480366vcb.13 for ; Tue, 04 Dec 2012 11:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=kOtafFHLyz8w14wZh73n4ktz7ZaaRRMvhjKQQxZrYDE=; b=sw8f9sXL97icQWxVt9eydGchh8YvXw0O/piq8f527RGnL7tHWBTlH+X2LsN7eR5NJN fADQSbk7MG9OSAUrgWrT7fKCblYidvRiiBq4F9+ngB8BmSE+Wy8cXxk4a1Nrx7YVl1cs viemytan24iD0egUNfrl5BQRD8JwJpXMh57EzkRimbObTh4uLDo+ML7w5+XfVOZae2L4 1Gj7Y9ezxFFbm00UIejwD42Arz23WE9l3tT5NA3JvGeI8pIR1jLEkUiN2MRmOOGAe2/K s/Yq5xcIM7MXrufWQSKWTLUy3zRv6Ipr/wmejac9TsdooXFTzgWGH+vq6/Zd2leCipsm VIeQ== Received: by 10.52.23.6 with SMTP id i6mr10851362vdf.100.1354648754498; Tue, 04 Dec 2012 11:19:14 -0800 (PST) Received: from [10.1.10.65] ([187.120.137.162]) by mx.google.com with ESMTPS id y7sm804335vdt.14.2012.12.04.11.19.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2012 11:19:13 -0800 (PST) From: Luiz Otavio O Souza Content-Type: multipart/mixed; boundary=Apple-Mail-16-531908476 Subject: FDT Support for GPIO (gpiobus and friends) Date: Tue, 4 Dec 2012 17:19:06 -0200 Message-Id: To: freebsd-arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:19:16 -0000 --Apple-Mail-16-531908476 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I've been playing with GPIO on RPi and found the missing support of FDT = on gpiobus very annoying. The following patch (gpio-fdt.diff) adds FDT support to GPIO (gpiobus, = gpioc, gpioled). The bcm2835_gpio.c.fdt.diff will add (a better) support of FDT on RPi = GPIO controller and the bcm2835.dts.diff has my changes on the RPi dts = for adding support of gpioled on 'ok' led (pin 16). Comments ? Thanks, Luiz --Apple-Mail-16-531908476 Content-Disposition: attachment; filename=gpio-fdt.diff Content-Type: application/octet-stream; name="gpio-fdt.diff" Content-Transfer-Encoding: 7bit Index: dev/gpio/gpiobus.c =================================================================== --- dev/gpio/gpiobus.c (revision 243614) +++ dev/gpio/gpiobus.c (working copy) @@ -46,6 +46,12 @@ #include "gpio_if.h" #include "gpiobus_if.h" +#ifdef FDT +#include +#include +#include +#endif + static void gpiobus_print_pins(struct gpiobus_ivar *); static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int); static int gpiobus_probe(device_t); @@ -169,9 +175,64 @@ return (0); } +#ifdef FDT static int +gpiobus_fdt_parse_pins(struct gpiobus_softc *sc, struct gpiobus_ivar *devi, + device_t child, phandle_t pchild) +{ + int i, len; + pcell_t *pins; + + if ((len = OF_getproplen(pchild, "pins")) == -1) + return (-1); + + pins = malloc(len, M_DEVBUF, M_NOWAIT | M_ZERO); + if (pins == NULL) + return (-1); + + if (OF_getprop(pchild, "pins", pins, len) == -1) { + free(pins, M_DEVBUF); + return (-1); + } + + devi->npins = len / sizeof(pcell_t); + devi->pins = malloc(sizeof(uint32_t) * devi->npins, M_DEVBUF, + M_NOWAIT | M_ZERO); + if (devi->pins == NULL) { + free(pins, M_DEVBUF); + return (-1); + } + + for (i = 0; i < devi->npins; i++) { + devi->pins[i] = fdt32_to_cpu(pins[i]); + + /* + * Mark pin as mapped and give warning if it's already mapped + */ + if (sc->sc_pins_mapped[devi->pins[i]]) { + device_printf(child, + "warning: pin %d is already mapped\n", + devi->pins[i]); + free(pins, M_DEVBUF); + return (-1); + } + sc->sc_pins_mapped[devi->pins[i]] = 1; + } + + free(pins, M_DEVBUF); + return (0); +} +#endif + +static int gpiobus_probe(device_t dev) { + +#ifdef FDT + if (!ofw_bus_is_compatible(dev, "gpiobus")) + return (ENXIO); +#endif + device_set_desc(dev, "GPIO bus"); return (0); } @@ -179,6 +240,11 @@ static int gpiobus_attach(device_t dev) { +#ifdef FDT + device_t dev_child; + phandle_t dt_node, dt_child; + struct gpiobus_ivar *devi; +#endif struct gpiobus_softc *sc = GPIOBUS_SOFTC(dev); int res; @@ -208,6 +274,53 @@ * Get parent's pins and mark them as unmapped */ bus_enumerate_hinted_children(dev); + +#ifdef FDT + /* + * Walk gpiobus and add direct subordinates as our children. + */ + dt_node = ofw_bus_get_node(dev); + for (dt_child = OF_child(dt_node); dt_child != 0; + dt_child = OF_peer(dt_child)) { + + /* Check and process 'status' property. */ + if (!(fdt_is_enabled(dt_child))) + continue; + + /* The GPIO pins are mandatory. */ + if (!OF_hasprop(dt_child, "pins")) + continue; + + devi = malloc(sizeof(*devi), M_DEVBUF, M_WAITOK | M_ZERO); + + if (ofw_bus_gen_setup_devinfo(&devi->ofw, dt_child) != 0) { + free(devi, M_DEVBUF); + device_printf(dev, "could not set up devinfo\n"); + continue; + } + + /* Add newbus device for this FDT node */ + dev_child = device_add_child(dev, NULL, -1); + if (dev_child == NULL) { + device_printf(dev, "could not add child: %s\n", + devi->ofw.obd_name); + /* XXX should unmap */ + ofw_bus_gen_destroy_devinfo(&devi->ofw); + free(devi, M_DEVBUF); + continue; + } + device_set_ivars(dev_child, devi); + + if (gpiobus_fdt_parse_pins(sc, + devi, dev_child, dt_child) != 0) { + device_delete_child(dev, dev_child); + ofw_bus_gen_destroy_devinfo(&devi->ofw); + free(devi, M_DEVBUF); + continue; + } + } +#endif + return (bus_generic_attach(dev)); } @@ -445,6 +558,17 @@ return GPIO_PIN_TOGGLE(sc->sc_dev, devi->pins[pin]); } +#ifdef FDT +static const struct ofw_bus_devinfo * +gpiobus_get_devinfo(device_t bus, device_t child) +{ + struct gpiobus_ivar *devi; + + devi = device_get_ivars(child); + return (&devi->ofw); +} +#endif + static device_method_t gpiobus_methods[] = { /* Device interface */ DEVMETHOD(device_probe, gpiobus_probe), @@ -473,6 +597,16 @@ DEVMETHOD(gpiobus_pin_set, gpiobus_pin_set), DEVMETHOD(gpiobus_pin_toggle, gpiobus_pin_toggle), +#ifdef FDT + /* OFW bus interface */ + DEVMETHOD(ofw_bus_get_devinfo, gpiobus_get_devinfo), + DEVMETHOD(ofw_bus_get_compat, ofw_bus_gen_get_compat), + DEVMETHOD(ofw_bus_get_model, ofw_bus_gen_get_model), + DEVMETHOD(ofw_bus_get_name, ofw_bus_gen_get_name), + DEVMETHOD(ofw_bus_get_node, ofw_bus_gen_get_node), + DEVMETHOD(ofw_bus_get_type, ofw_bus_gen_get_type), +#endif + DEVMETHOD_END }; Index: dev/gpio/gpiobusvar.h =================================================================== --- dev/gpio/gpiobusvar.h (revision 243614) +++ dev/gpio/gpiobusvar.h (working copy) @@ -34,6 +34,12 @@ #include #include +#include "opt_platform.h" + +#ifdef FDT +#include +#endif + #define GPIOBUS_IVAR(d) (struct gpiobus_ivar *) device_get_ivars(d) #define GPIOBUS_SOFTC(d) (struct gpiobus_softc *) device_get_softc(d) @@ -50,6 +56,9 @@ struct gpiobus_ivar { +#ifdef FDT + struct ofw_bus_devinfo ofw; /* FDT device info */ +#endif uint32_t npins; /* pins total */ uint32_t *pins; /* pins map */ }; Index: dev/gpio/gpioc.c =================================================================== --- dev/gpio/gpioc.c (revision 243614) +++ dev/gpio/gpioc.c (working copy) @@ -44,6 +44,13 @@ #include #include "gpio_if.h" +#include "opt_platform.h" + +#ifdef FDT +#include +#include +#endif + #undef GPIOC_DEBUG #ifdef GPIOC_DEBUG #define dprintf printf @@ -73,6 +80,11 @@ static int gpioc_probe(device_t dev) { + +#ifdef FDT + if (!ofw_bus_is_compatible(dev, "gpio-controller")) + return (ENXIO); +#endif device_set_desc(dev, "GPIO controller"); return (0); } Index: dev/gpio/gpioled.c =================================================================== --- dev/gpio/gpioled.c (revision 243614) +++ dev/gpio/gpioled.c (working copy) @@ -43,11 +43,20 @@ #include #include "gpiobus_if.h" +#include "opt_platform.h" + +#ifdef FDT +#include +#include +#endif + /* * Only one pin for led */ #define GPIOLED_PIN 0 +#define GPIOLED_MAXBUF 32 + #define GPIOLED_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) #define GPIOLED_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) #define GPIOLED_LOCK_INIT(_sc) \ @@ -85,6 +94,11 @@ static int gpioled_probe(device_t dev) { + +#ifdef FDT + if (!ofw_bus_is_compatible(dev, "gpioled")) + return (ENXIO); +#endif device_set_desc(dev, "GPIO led"); return (0); } @@ -92,16 +106,27 @@ static int gpioled_attach(device_t dev) { +#ifdef FDT + phandle_t node; +#endif struct gpioled_softc *sc; - const char *name; + char *name; sc = device_get_softc(dev); sc->sc_dev = dev; sc->sc_busdev = device_get_parent(dev); GPIOLED_LOCK_INIT(sc); + +#ifdef FDT + node = ofw_bus_get_node(dev); + name = malloc(GPIOLED_MAXBUF + 1, M_DEVBUF, M_NOWAIT | M_ZERO); + if (OF_getprop(node, "label", name, GPIOLED_MAXBUF) == -1) + OF_getprop(node, "name", name, GPIOLED_MAXBUF); +#else if (resource_string_value(device_get_name(dev), device_get_unit(dev), "name", &name)) name = NULL; +#endif GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, GPIOLED_PIN, GPIO_PIN_OUTPUT); @@ -109,6 +134,9 @@ sc->sc_leddev = led_create(gpioled_control, sc, name ? name : device_get_nameunit(dev)); +#ifdef FDT + free(name, M_DEVBUF); +#endif return (0); } --Apple-Mail-16-531908476 Content-Disposition: attachment; filename=bcm2835_gpio.c.fdt.diff Content-Type: application/octet-stream; name="bcm2835_gpio.c.fdt.diff" Content-Transfer-Encoding: 7bit --- arm/broadcom/bcm2835/bcm2835_gpio.c.orig 2012-12-03 15:39:23.762869715 -0200 +++ arm/broadcom/bcm2835/bcm2835_gpio.c 2012-12-04 16:22:40.133869246 -0200 @@ -689,9 +689,11 @@ bcm_gpio_attach(device_t dev) { struct bcm_gpio_softc *sc = device_get_softc(dev); + struct ofw_bus_devinfo *di_ofw; + device_t dev_child; uint32_t func; int i, j, rid; - phandle_t gpio; + phandle_t child, gpio; sc->sc_dev = dev; @@ -747,8 +749,39 @@ bcm_gpio_sysctl_init(sc); - device_add_child(dev, "gpioc", device_get_unit(dev)); - device_add_child(dev, "gpiobus", device_get_unit(dev)); + /* + * Walkthrough our node and add direct subordinates as our children. + */ + for (child = OF_child(gpio); child != 0; child = OF_peer(child)) { + + /* Check and process 'status' property. */ + if (!(fdt_is_enabled(child))) + continue; + + if (!OF_hasprop(child, "compatible")) + continue; + + di_ofw = malloc(sizeof(*di_ofw), M_DEVBUF, M_WAITOK | M_ZERO); + + if (ofw_bus_gen_setup_devinfo(di_ofw, child) != 0) { + free(di_ofw, M_DEVBUF); + device_printf(dev, "could not set up devinfo\n"); + continue; + } + + /* Add newbus device for this FDT node */ + dev_child = device_add_child(dev, NULL, -1); + if (dev_child == NULL) { + device_printf(dev, "could not add child: %s\n", + di_ofw->obd_name); + /* XXX should unmap */ + ofw_bus_gen_destroy_devinfo(di_ofw); + free(di_ofw, M_DEVBUF); + continue; + } + device_set_ivars(dev_child, di_ofw); + } + return (bus_generic_attach(dev)); fail: @@ -766,6 +799,13 @@ return (EBUSY); } +static const struct ofw_bus_devinfo * +bcm_gpio_get_devinfo(device_t bus, device_t child) +{ + + return (device_get_ivars(child)); +} + static device_method_t bcm_gpio_methods[] = { /* Device interface */ DEVMETHOD(device_probe, bcm_gpio_probe), @@ -782,6 +822,14 @@ DEVMETHOD(gpio_pin_set, bcm_gpio_pin_set), DEVMETHOD(gpio_pin_toggle, bcm_gpio_pin_toggle), + /* OFW bus interface */ + DEVMETHOD(ofw_bus_get_devinfo, bcm_gpio_get_devinfo), + DEVMETHOD(ofw_bus_get_compat, ofw_bus_gen_get_compat), + DEVMETHOD(ofw_bus_get_model, ofw_bus_gen_get_model), + DEVMETHOD(ofw_bus_get_name, ofw_bus_gen_get_name), + DEVMETHOD(ofw_bus_get_node, ofw_bus_gen_get_node), + DEVMETHOD(ofw_bus_get_type, ofw_bus_gen_get_type), + DEVMETHOD_END }; --Apple-Mail-16-531908476 Content-Disposition: attachment; filename=bcm2835.dts.diff Content-Type: application/octet-stream; name="bcm2835.dts.diff" Content-Transfer-Encoding: 7bit Index: boot/fdt/dts/bcm2835-rpi-b.dts =================================================================== --- boot/fdt/dts/bcm2835-rpi-b.dts (revision 243614) +++ boot/fdt/dts/bcm2835-rpi-b.dts (working copy) @@ -173,6 +173,21 @@ */ broadcom,read-only = <46>, <47>, <48>, <49>, <50>, <51>, <52>, <53>; + gpioc { + compatible = "gpio-controller"; + }; + + gpiobus { + compatible = "gpiobus"; + + /* Ok led */ + led { + compatible = "gpioled"; + label = "ok"; + pins = <16>; + }; + }; + /* BSC0 */ pins_bsc0_a: bsc0_a { broadcom,pins = <0>, <1>; --Apple-Mail-16-531908476-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 4 20:27:58 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12A6DB89 for ; Tue, 4 Dec 2012 20:27:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id C1FB58FC13 for ; Tue, 4 Dec 2012 20:27:57 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id c11so7664111ieb.33 for ; Tue, 04 Dec 2012 12:27:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=VvZS9si8Bgx1dyQCmOu8t3S3a3BWR9WtPs4HQVXmUj4=; b=dOqIkc5OoiajS6p21Lu4XQ1IaCAPeqPJPjbbG+k345mInvx9nwCm4FJq80ydoN9ieA /YfbNpRTtpgwrwKhVJK/iMyCsCVQHU5nXNPrfPMFoZlzSUkwYt1Rw3lsnH+uwSGLY/UN A2VrZcSe6oZB0OtOsBajtbk6dhRdbTmYVkos+KExJrFCd5e4p9BGZ27vtlxhIP0yVVrt LuSNANO09zMKBKX9zuqODB2w2sLvC6CPGmljnR10GTea42cKWxWCPWBf1ev2Nc1VdDeZ RhqSCxdd3/erUggEKGIPmVb4i32YanvU1MHvzIHZuhmxNpvulf6zGaCC+2ag13dl/0P8 CoPg== Received: by 10.50.76.195 with SMTP id m3mr4023165igw.64.1354652871177; Tue, 04 Dec 2012 12:27:51 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id xn10sm10696365igb.4.2012.12.04.12.27.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2012 12:27:50 -0800 (PST) Sender: Warner Losh Subject: Re: FDT Support for GPIO (gpiobus and friends) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 4 Dec 2012 13:27:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQm/OAxVzkf8ZUTJhQ/Sp5uJlnlFfcB/W1RwWZns3KELnEhrEXkl+tsYcF0A8COC61R9a22P Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 20:27:58 -0000 Does this implement the standard DTS info for these things? Linux has = extensive support for all things GPIO that tends to be reflected in the = FDT standards... I'm interested in getting support for pinctl and = pinmux, for example... Regardless, this is cool! Warner On Dec 4, 2012, at 12:19 PM, Luiz Otavio O Souza wrote: > Hi, >=20 > I've been playing with GPIO on RPi and found the missing support of = FDT on gpiobus very annoying. >=20 > The following patch (gpio-fdt.diff) adds FDT support to GPIO (gpiobus, = gpioc, gpioled). >=20 > The bcm2835_gpio.c.fdt.diff will add (a better) support of FDT on RPi = GPIO controller and the bcm2835.dts.diff has my changes on the RPi dts = for adding support of gpioled on 'ok' led (pin 16). >=20 > Comments ? >=20 > Thanks, > Luiz >=20 > = ________________= _______________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Dec 4 21:01:35 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D5B6DA3 for ; Tue, 4 Dec 2012 21:01:35 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id A94568FC14 for ; Tue, 4 Dec 2012 21:01:34 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qB4L1HoG008298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2012 06:01:27 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qB4L1FVW023151; Wed, 5 Dec 2012 06:01:17 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 05 Dec 2012 06:00:56 +0900 (JST) Message-Id: <20121205.060056.592894859995638978.hrs@allbsd.org> To: loos.br@gmail.com Subject: Re: FDT Support for GPIO (gpiobus and friends) From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Dec__5_06_00_56_2012_562)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 05 Dec 2012 06:01:27 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 21:01:35 -0000 ----Security_Multipart(Wed_Dec__5_06_00_56_2012_562)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Luiz Otavio O Souza wrote in : lo> Hi, lo> lo> I've been playing with GPIO on RPi and found the missing support of lo> FDT on gpiobus very annoying. lo> lo> The following patch (gpio-fdt.diff) adds FDT support to GPIO (gpiobus, lo> gpioc, gpioled). lo> lo> The bcm2835_gpio.c.fdt.diff will add (a better) support of FDT on RPi lo> GPIO controller and the bcm2835.dts.diff has my changes on the RPi dts lo> for adding support of gpioled on 'ok' led (pin 16). lo> lo> Comments ? I like this idea, but it should be consistent with standard device tree bindings. For example, + gpiobus { + compatible = "gpiobus"; + + /* Ok led */ + led { + compatible = "gpioled"; + label = "ok"; + pins = <16>; + }; + }; should be something like the following: led { compatible = "gpio-leds"; ok { gpios = <&foo 16 1>; label = "ok"; }; }; A node using GPIOs must have gpios property for the gpio-controller node and pin number. -- Hiroki ----Security_Multipart(Wed_Dec__5_06_00_56_2012_562)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlC+ZIgACgkQTyzT2CeTzy11aACdGlsC5wkywjh7b7i22FeEhgLU 2UUAn20D8iJiexPsVsSHTOjO8w5EbTXG =3KTu -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Dec__5_06_00_56_2012_562)---- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 4 22:10:21 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B545AA3 for ; Tue, 4 Dec 2012 22:10:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9A4A8FC18 for ; Tue, 4 Dec 2012 22:10:20 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so10828996iec.27 for ; Tue, 04 Dec 2012 14:10:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=n2SdUNQaSxl/AUq9j05su1y+TN46zE3aC2IRjVpW7/8=; b=fgharY1q7BVsgxtf5R86bi3sGSNNNpl+2sFN2ukf548+PPwYo8RyGFHuumTXvnjjUl +vUUZPDwzObinsM0EzixyjLnH1BMGae9zt2OlLv/xG9ABmxcSgymxLzVenrPTH/tsHEp amuAk8GGEFEPkQz8a8JTX2f0Qm0QXMfMB6T/GuaXgpO7NVz7llzAeWWm9VBV72extzyy iLEgIIJZVdzeHzd+4q5kgFTe8NYL9try0RaCp3KoReOWRzTzW3YgxVWu7tsfqtnu12UM Ga/DnONgmux1GNvpl1AmwR7XorXlbFfwH9GbgvhClS+aGlpD6DMhr1duKqfKWokJe8aV IHHw== Received: by 10.50.104.232 with SMTP id gh8mr4376312igb.45.1354659019580; Tue, 04 Dec 2012 14:10:19 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id uj6sm2159646igb.4.2012.12.04.14.10.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2012 14:10:18 -0800 (PST) Sender: Warner Losh Subject: Re: FDT Support for GPIO (gpiobus and friends) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20121205.060056.592894859995638978.hrs@allbsd.org> Date: Tue, 4 Dec 2012 15:10:11 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20121205.060056.592894859995638978.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk7CRt5SEntVvbByY6b0DdNmH8R38ebSRHwT4mYeP/3pZPXCiP2KER+qC1PtHDXKzCGdMwe Cc: freebsd-arch@FreeBSD.org, loos.br@gmail.com X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 22:10:21 -0000 On Dec 4, 2012, at 2:00 PM, Hiroki Sato wrote: > Luiz Otavio O Souza wrote > in : > > lo> Hi, > lo> > lo> I've been playing with GPIO on RPi and found the missing support of > lo> FDT on gpiobus very annoying. > lo> > lo> The following patch (gpio-fdt.diff) adds FDT support to GPIO (gpiobus, > lo> gpioc, gpioled). > lo> > lo> The bcm2835_gpio.c.fdt.diff will add (a better) support of FDT on RPi > lo> GPIO controller and the bcm2835.dts.diff has my changes on the RPi dts > lo> for adding support of gpioled on 'ok' led (pin 16). > lo> > lo> Comments ? > > I like this idea, but it should be consistent with standard device > tree bindings. For example, > > + gpiobus { > + compatible = "gpiobus"; > + > + /* Ok led */ > + led { > + compatible = "gpioled"; > + label = "ok"; > + pins = <16>; > + }; > + }; Yes. This was the sort of thing that I didn't like... > should be something like the following: > > led { > compatible = "gpio-leds"; > ok { > gpios = <&foo 16 1>; > label = "ok"; > }; > }; > > A node using GPIOs must have gpios property for the gpio-controller > node and pin number. Yes, this conforms much better with the FTD standards. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 14:25:37 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A524B49; Fri, 7 Dec 2012 14:25:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DFE698FC08; Fri, 7 Dec 2012 14:25:36 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so282495wey.13 for ; Fri, 07 Dec 2012 06:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=snEVFON7T9m19p2rfo6bveHgW0MIv5AtdLqJAaPDKSc=; b=lxw1PXrjhI+9eEepErl6WqvG/JavM3kvPo8VskzhKJqyLI0xn4QZOFoOYxNne1NMNH OcSkLcOFgmNFkesicIstqb6uuTjsG7Yh4ynxSN2PlGt9HgsAVfWjn9unQa7jDMCzJ6Ns oBb/h8XqYXAXpWyitpDFaf/4RcFM0TcDQTmwUkc4MMiXUj5Oz6cGwnyd3G414Pj4l/py e3eUj/RurC+yuwwr5LGdTFrOEnkc67TL71VvHbKRtP0rFlH/Cpostpw7+j45D1kmuHhg SjMXLLusSAHDnVTU3S3psCA/2NYtM5WSoGQgDAyGkcGdkXvf1IlFAD4b6mD+Huy+WaqA /jaA== MIME-Version: 1.0 Received: by 10.180.104.69 with SMTP id gc5mr15308785wib.13.1354890335533; Fri, 07 Dec 2012 06:25:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 7 Dec 2012 06:25:35 -0800 (PST) In-Reply-To: <201212070825.qB78P9rY055786@svn.freebsd.org> References: <201212070825.qB78P9rY055786@svn.freebsd.org> Date: Fri, 7 Dec 2012 06:25:35 -0800 X-Google-Sender-Auth: 1XeWfSWxS9_Af2C4V2xD5orcuGg Message-ID: Subject: Re: svn commit: r243980 - in head/sys: kern sys From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:25:37 -0000 Ok, so can we now please split 'panic during debugging but we do handle the case' and 'panic during live runs as it really does mean we're hosed' assert checks, so coders can choose which is appropriate? Or does that now exist? Adrian On 7 December 2012 00:25, Alfred Perlstein wrote: > Author: alfred > Date: Fri Dec 7 08:25:08 2012 > New Revision: 243980 > URL: http://svnweb.freebsd.org/changeset/base/243980 > > Log: > Allow KASSERT to log instead of panic. > > This is to allow debug images to be used without taking down the > system when non-fatal asserts are hit. > > The following sysctls are added: > > debug.kassert.warn_only: 1 = log, 0 = panic > > debug.kassert.do_ktr: set to a ktr mask for logging via KTR > > debug.kassert.do_log: 1 = log, 0 = quiet > > debug.kassert.warnings: stats, number of kasserts hit > > debug.kassert.log_panic_at: > number of kasserts before we actually panic, 0 = never > > debug.kassert.log_pps_limit: pps limit for log messages > > debug.kassert.log_mute_at: stop warning after N kasserts, 0 = never stop > > debug.kassert.kassert: set this sysctl to trigger a kassert > > Discussed with: scottl, gnn, marcel > Sponsored by: iXsystems > > Modified: > head/sys/kern/kern_shutdown.c > head/sys/sys/systm.h > > Modified: head/sys/kern/kern_shutdown.c > ============================================================================== > --- head/sys/kern/kern_shutdown.c Fri Dec 7 07:24:15 2012 (r243979) > +++ head/sys/kern/kern_shutdown.c Fri Dec 7 08:25:08 2012 (r243980) > @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -150,6 +151,7 @@ static void poweroff_wait(void *, int); > static void shutdown_halt(void *junk, int howto); > static void shutdown_panic(void *junk, int howto); > static void shutdown_reset(void *junk, int howto); > +static void vpanic(const char *fmt, va_list ap) __dead2; > > /* register various local shutdown events */ > static void > @@ -538,6 +540,120 @@ shutdown_reset(void *junk, int howto) > /* NOTREACHED */ /* assuming reset worked */ > } > > +#ifdef INVARIANTS > +static int kassert_warn_only = 0; > +#ifdef KTR > +static int kassert_do_ktr = 0; > +#endif > +static int kassert_do_log = 1; > +static int kassert_log_pps_limit = 4; > +static int kassert_log_mute_at = 0; > +static int kassert_log_panic_at = 0; > +static int kassert_warnings = 0; > + > +SYSCTL_NODE(_debug, OID_AUTO, kassert, CTLFLAG_RW, NULL, "kassert options"); > + > +SYSCTL_INT(_debug_kassert, OID_AUTO, warn_only, CTLFLAG_RW | CTLFLAG_TUN, > + &kassert_warn_only, 0, > + "KASSERT triggers a panic (1) or just a warning (0)"); > +TUNABLE_INT("debug.kassert.warn_only", &kassert_warn_only); > + > +#ifdef KTR > +SYSCTL_UINT(_debug_kassert, OID_AUTO, do_ktr, CTLFLAG_RW | CTLFLAG_TUN, > + &kassert_do_ktr, 0, > + "KASSERT does a KTR, set this to the KTRMASK you want"); > +TUNABLE_INT("debug.kassert.do_ktr", &kassert_do_ktr); > +#endif > + > +SYSCTL_INT(_debug_kassert, OID_AUTO, do_log, CTLFLAG_RW | CTLFLAG_TUN, > + &kassert_do_log, 0, "KASSERT triggers a panic (1) or just a warning (0)"); > +TUNABLE_INT("debug.kassert.do_log", &kassert_do_log); > + > +SYSCTL_INT(_debug_kassert, OID_AUTO, warnings, CTLFLAG_RW | CTLFLAG_TUN, > + &kassert_warnings, 0, "number of KASSERTs that have been triggered"); > +TUNABLE_INT("debug.kassert.warnings", &kassert_warnings); > + > +SYSCTL_INT(_debug_kassert, OID_AUTO, log_panic_at, CTLFLAG_RW | CTLFLAG_TUN, > + &kassert_log_panic_at, 0, "max number of KASSERTS before we will panic"); > +TUNABLE_INT("debug.kassert.log_panic_at", &kassert_log_panic_at); > + > +SYSCTL_INT(_debug_kassert, OID_AUTO, log_pps_limit, CTLFLAG_RW | CTLFLAG_TUN, > + &kassert_log_pps_limit, 0, "limit number of log messages per second"); > +TUNABLE_INT("debug.kassert.log_pps_limit", &kassert_log_pps_limit); > + > +SYSCTL_INT(_debug_kassert, OID_AUTO, log_mute_at, CTLFLAG_RW | CTLFLAG_TUN, > + &kassert_log_mute_at, 0, "max number of KASSERTS to log"); > +TUNABLE_INT("debug.kassert.log_mute_at", &kassert_log_mute_at); > + > +static int kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS); > + > +SYSCTL_PROC(_debug_kassert, OID_AUTO, kassert, > + CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_SECURE, NULL, 0, > + kassert_sysctl_kassert, "I", "set to trigger a test kassert"); > + > +static int > +kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS) > +{ > + int error, i; > + > + error = sysctl_wire_old_buffer(req, sizeof(int)); > + if (error == 0) { > + i = 0; > + error = sysctl_handle_int(oidp, &i, 0, req); > + } > + if (error != 0 || req->newptr == NULL) > + return (error); > + KASSERT(0, ("kassert_sysctl_kassert triggered kassert %d", i)); > + return (0); > +} > + > +/* > + * Called by KASSERT, this decides if we will panic > + * or if we will log via printf and/or ktr. > + */ > +void > +kassert_panic(const char *fmt, ...) > +{ > + static char buf[256]; > + va_list ap; > + > + va_start(ap, fmt); > + (void)vsnprintf(buf, sizeof(buf), fmt, ap); > + va_end(ap); > + > + /* > + * panic if we're not just warning, or if we've exceeded > + * kassert_log_panic_at warnings. > + */ > + if (!kassert_warn_only || > + (kassert_log_panic_at > 0 && > + kassert_warnings >= kassert_log_panic_at)) { > + va_start(ap, fmt); > + vpanic(fmt, ap); > + /* NORETURN */ > + } > +#ifdef KTR > + if (kassert_do_ktr) > + CTR0(ktr_mask, buf); > +#endif /* KTR */ > + /* > + * log if we've not yet met the mute limit. > + */ > + if (kassert_do_log && > + (kassert_log_mute_at == 0 || > + kassert_warnings < kassert_log_mute_at)) { > + static struct timeval lasterr; > + static int curerr; > + > + if (ppsratecheck(&lasterr, &curerr, kassert_log_pps_limit)) { > + printf("KASSERT failed: %s\n", buf); > + kdb_backtrace(); > + } > + } > + atomic_add_int(&kassert_warnings, 1); > +} > +#endif > + > /* > * Panic is called on unresolvable fatal errors. It prints "panic: mesg", > * and then reboots. If we are called twice, then we avoid trying to sync > @@ -546,12 +662,20 @@ shutdown_reset(void *junk, int howto) > void > panic(const char *fmt, ...) > { > + va_list ap; > + > + va_start(ap, fmt); > + vpanic(fmt, ap); > +} > + > +static void > +vpanic(const char *fmt, va_list ap) > +{ > #ifdef SMP > cpuset_t other_cpus; > #endif > struct thread *td = curthread; > int bootopt, newpanic; > - va_list ap; > static char buf[256]; > > spinlock_enter(); > @@ -587,7 +711,6 @@ panic(const char *fmt, ...) > newpanic = 1; > } > > - va_start(ap, fmt); > if (newpanic) { > (void)vsnprintf(buf, sizeof(buf), fmt, ap); > panicstr = buf; > @@ -598,7 +721,6 @@ panic(const char *fmt, ...) > vprintf(fmt, ap); > printf("\n"); > } > - va_end(ap); > #ifdef SMP > printf("cpuid = %d\n", PCPU_GET(cpuid)); > #endif > > Modified: head/sys/sys/systm.h > ============================================================================== > --- head/sys/sys/systm.h Fri Dec 7 07:24:15 2012 (r243979) > +++ head/sys/sys/systm.h Fri Dec 7 08:25:08 2012 (r243980) > @@ -73,14 +73,16 @@ extern int vm_guest; /* Running as virt > enum VM_GUEST { VM_GUEST_NO = 0, VM_GUEST_VM, VM_GUEST_XEN }; > > #ifdef INVARIANTS /* The option is always available */ > +void kassert_panic(const char *fmt, ...); > + > #define KASSERT(exp,msg) do { \ > if (__predict_false(!(exp))) \ > - panic msg; \ > + kassert_panic msg; \ > } while (0) > #define VNASSERT(exp, vp, msg) do { \ > if (__predict_false(!(exp))) { \ > vn_printf(vp, "VNASSERT failed\n"); \ > - panic msg; \ > + kassert_panic msg; \ > } \ > } while (0) > #else From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 15:12:54 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55BB0220; Fri, 7 Dec 2012 15:12:54 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id D28118FC08; Fri, 7 Dec 2012 15:12:53 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so256873dad.13 for ; Fri, 07 Dec 2012 07:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XOJf/SfUwTcXeWoEovkUU86L1U17j5jrwB+WWCxcWXc=; b=Yt6rZv2MYBFWwhUhZLgs1wEv2wE7BULq3Vwk7LDBeqegirQCmsRew2+eWW/s1MZKLL tsKcuYmQXOUmMVHxegikfA9q8dCWuHuT2VWCD8EFD7B7/RVFlSNMTNgzz/knLfjm6Sk9 bBbdJh+hyu0AHOsSt3vZi5B42YKYZwz48Nvcrv26Az53dzLGVKy+Weo5YYQ1Kzdb81zf 0YRkuJe1RyToZI1+j3KncUIOvRPvgeFhL0y5hN/N3uO7A8EXTy/Y2ukxPnzjAuQelqyb lXDcj4Z2FcSGmxkY9Y5jqHHbzHSmvFKNHXsqZVSEGIbtY1lea2jrfYFARHUlkFEIl6TA Zx8A== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr16265829pbc.105.1354893173350; Fri, 07 Dec 2012 07:12:53 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.55.166 with HTTP; Fri, 7 Dec 2012 07:12:53 -0800 (PST) In-Reply-To: References: <201212070825.qB78P9rY055786@svn.freebsd.org> Date: Fri, 7 Dec 2012 07:12:53 -0800 X-Google-Sender-Auth: CACxnUcA_WpyFS8lx-NctwSciyE Message-ID: Subject: Re: svn commit: r243980 - in head/sys: kern sys From: mdf@FreeBSD.org To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Alfred Perlstein , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:12:54 -0000 On Fri, Dec 7, 2012 at 6:25 AM, Adrian Chadd wrote: > Ok, so can we now please split 'panic during debugging but we do > handle the case' and 'panic during live runs as it really does mean > we're hosed' assert checks, so coders can choose which is appropriate? > > Or does that now exist? This should already exist, as KASSERT was only for INVARIANTS and presumably no one runs that code in production. At $work we have an ugly macro but a flexible system for this -- checks are grouped into areas, and each one has a set of sysctl nodes defining at what level they're checked (production, debug, never), which is compared to the global check level (off, production, debug), and what the action is on failure (ignore, log, panic, etc.) It's flexible but it's also a bit awkward to work with when you don't know if one of those VERIFY_ASSERTS will panic or not -- especially since the error can be ignored. Perhaps we made it too flexible. Since KASSERT was always INVARIANTS only this is probably a step in the right direction (though the rate check means that if one error fires, other errors of a different type will be ignored). Making it more fine grained so individual checks can be enabled at runtime instead of compile time, etc., would be useful to some vendors. But all that flexibility has a cost in object code and runtime for the embedded world, so it's a tradeoff too. Cheers, matthew > On 7 December 2012 00:25, Alfred Perlstein wrote: >> Author: alfred >> Date: Fri Dec 7 08:25:08 2012 >> New Revision: 243980 >> URL: http://svnweb.freebsd.org/changeset/base/243980 >> >> Log: >> Allow KASSERT to log instead of panic. >> >> This is to allow debug images to be used without taking down the >> system when non-fatal asserts are hit. >> >> The following sysctls are added: >> >> debug.kassert.warn_only: 1 = log, 0 = panic >> >> debug.kassert.do_ktr: set to a ktr mask for logging via KTR >> >> debug.kassert.do_log: 1 = log, 0 = quiet >> >> debug.kassert.warnings: stats, number of kasserts hit >> >> debug.kassert.log_panic_at: >> number of kasserts before we actually panic, 0 = never >> >> debug.kassert.log_pps_limit: pps limit for log messages >> >> debug.kassert.log_mute_at: stop warning after N kasserts, 0 = never stop >> >> debug.kassert.kassert: set this sysctl to trigger a kassert >> >> Discussed with: scottl, gnn, marcel >> Sponsored by: iXsystems >> >> Modified: >> head/sys/kern/kern_shutdown.c >> head/sys/sys/systm.h >> >> Modified: head/sys/kern/kern_shutdown.c >> ============================================================================== >> --- head/sys/kern/kern_shutdown.c Fri Dec 7 07:24:15 2012 (r243979) >> +++ head/sys/kern/kern_shutdown.c Fri Dec 7 08:25:08 2012 (r243980) >> @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -150,6 +151,7 @@ static void poweroff_wait(void *, int); >> static void shutdown_halt(void *junk, int howto); >> static void shutdown_panic(void *junk, int howto); >> static void shutdown_reset(void *junk, int howto); >> +static void vpanic(const char *fmt, va_list ap) __dead2; >> >> /* register various local shutdown events */ >> static void >> @@ -538,6 +540,120 @@ shutdown_reset(void *junk, int howto) >> /* NOTREACHED */ /* assuming reset worked */ >> } >> >> +#ifdef INVARIANTS >> +static int kassert_warn_only = 0; >> +#ifdef KTR >> +static int kassert_do_ktr = 0; >> +#endif >> +static int kassert_do_log = 1; >> +static int kassert_log_pps_limit = 4; >> +static int kassert_log_mute_at = 0; >> +static int kassert_log_panic_at = 0; >> +static int kassert_warnings = 0; >> + >> +SYSCTL_NODE(_debug, OID_AUTO, kassert, CTLFLAG_RW, NULL, "kassert options"); >> + >> +SYSCTL_INT(_debug_kassert, OID_AUTO, warn_only, CTLFLAG_RW | CTLFLAG_TUN, >> + &kassert_warn_only, 0, >> + "KASSERT triggers a panic (1) or just a warning (0)"); >> +TUNABLE_INT("debug.kassert.warn_only", &kassert_warn_only); >> + >> +#ifdef KTR >> +SYSCTL_UINT(_debug_kassert, OID_AUTO, do_ktr, CTLFLAG_RW | CTLFLAG_TUN, >> + &kassert_do_ktr, 0, >> + "KASSERT does a KTR, set this to the KTRMASK you want"); >> +TUNABLE_INT("debug.kassert.do_ktr", &kassert_do_ktr); >> +#endif >> + >> +SYSCTL_INT(_debug_kassert, OID_AUTO, do_log, CTLFLAG_RW | CTLFLAG_TUN, >> + &kassert_do_log, 0, "KASSERT triggers a panic (1) or just a warning (0)"); >> +TUNABLE_INT("debug.kassert.do_log", &kassert_do_log); >> + >> +SYSCTL_INT(_debug_kassert, OID_AUTO, warnings, CTLFLAG_RW | CTLFLAG_TUN, >> + &kassert_warnings, 0, "number of KASSERTs that have been triggered"); >> +TUNABLE_INT("debug.kassert.warnings", &kassert_warnings); >> + >> +SYSCTL_INT(_debug_kassert, OID_AUTO, log_panic_at, CTLFLAG_RW | CTLFLAG_TUN, >> + &kassert_log_panic_at, 0, "max number of KASSERTS before we will panic"); >> +TUNABLE_INT("debug.kassert.log_panic_at", &kassert_log_panic_at); >> + >> +SYSCTL_INT(_debug_kassert, OID_AUTO, log_pps_limit, CTLFLAG_RW | CTLFLAG_TUN, >> + &kassert_log_pps_limit, 0, "limit number of log messages per second"); >> +TUNABLE_INT("debug.kassert.log_pps_limit", &kassert_log_pps_limit); >> + >> +SYSCTL_INT(_debug_kassert, OID_AUTO, log_mute_at, CTLFLAG_RW | CTLFLAG_TUN, >> + &kassert_log_mute_at, 0, "max number of KASSERTS to log"); >> +TUNABLE_INT("debug.kassert.log_mute_at", &kassert_log_mute_at); >> + >> +static int kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS); >> + >> +SYSCTL_PROC(_debug_kassert, OID_AUTO, kassert, >> + CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_SECURE, NULL, 0, >> + kassert_sysctl_kassert, "I", "set to trigger a test kassert"); >> + >> +static int >> +kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS) >> +{ >> + int error, i; >> + >> + error = sysctl_wire_old_buffer(req, sizeof(int)); >> + if (error == 0) { >> + i = 0; >> + error = sysctl_handle_int(oidp, &i, 0, req); >> + } >> + if (error != 0 || req->newptr == NULL) >> + return (error); >> + KASSERT(0, ("kassert_sysctl_kassert triggered kassert %d", i)); >> + return (0); >> +} >> + >> +/* >> + * Called by KASSERT, this decides if we will panic >> + * or if we will log via printf and/or ktr. >> + */ >> +void >> +kassert_panic(const char *fmt, ...) >> +{ >> + static char buf[256]; >> + va_list ap; >> + >> + va_start(ap, fmt); >> + (void)vsnprintf(buf, sizeof(buf), fmt, ap); >> + va_end(ap); >> + >> + /* >> + * panic if we're not just warning, or if we've exceeded >> + * kassert_log_panic_at warnings. >> + */ >> + if (!kassert_warn_only || >> + (kassert_log_panic_at > 0 && >> + kassert_warnings >= kassert_log_panic_at)) { >> + va_start(ap, fmt); >> + vpanic(fmt, ap); >> + /* NORETURN */ >> + } >> +#ifdef KTR >> + if (kassert_do_ktr) >> + CTR0(ktr_mask, buf); >> +#endif /* KTR */ >> + /* >> + * log if we've not yet met the mute limit. >> + */ >> + if (kassert_do_log && >> + (kassert_log_mute_at == 0 || >> + kassert_warnings < kassert_log_mute_at)) { >> + static struct timeval lasterr; >> + static int curerr; >> + >> + if (ppsratecheck(&lasterr, &curerr, kassert_log_pps_limit)) { >> + printf("KASSERT failed: %s\n", buf); >> + kdb_backtrace(); >> + } >> + } >> + atomic_add_int(&kassert_warnings, 1); >> +} >> +#endif >> + >> /* >> * Panic is called on unresolvable fatal errors. It prints "panic: mesg", >> * and then reboots. If we are called twice, then we avoid trying to sync >> @@ -546,12 +662,20 @@ shutdown_reset(void *junk, int howto) >> void >> panic(const char *fmt, ...) >> { >> + va_list ap; >> + >> + va_start(ap, fmt); >> + vpanic(fmt, ap); >> +} >> + >> +static void >> +vpanic(const char *fmt, va_list ap) >> +{ >> #ifdef SMP >> cpuset_t other_cpus; >> #endif >> struct thread *td = curthread; >> int bootopt, newpanic; >> - va_list ap; >> static char buf[256]; >> >> spinlock_enter(); >> @@ -587,7 +711,6 @@ panic(const char *fmt, ...) >> newpanic = 1; >> } >> >> - va_start(ap, fmt); >> if (newpanic) { >> (void)vsnprintf(buf, sizeof(buf), fmt, ap); >> panicstr = buf; >> @@ -598,7 +721,6 @@ panic(const char *fmt, ...) >> vprintf(fmt, ap); >> printf("\n"); >> } >> - va_end(ap); >> #ifdef SMP >> printf("cpuid = %d\n", PCPU_GET(cpuid)); >> #endif >> >> Modified: head/sys/sys/systm.h >> ============================================================================== >> --- head/sys/sys/systm.h Fri Dec 7 07:24:15 2012 (r243979) >> +++ head/sys/sys/systm.h Fri Dec 7 08:25:08 2012 (r243980) >> @@ -73,14 +73,16 @@ extern int vm_guest; /* Running as virt >> enum VM_GUEST { VM_GUEST_NO = 0, VM_GUEST_VM, VM_GUEST_XEN }; >> >> #ifdef INVARIANTS /* The option is always available */ >> +void kassert_panic(const char *fmt, ...); >> + >> #define KASSERT(exp,msg) do { \ >> if (__predict_false(!(exp))) \ >> - panic msg; \ >> + kassert_panic msg; \ >> } while (0) >> #define VNASSERT(exp, vp, msg) do { \ >> if (__predict_false(!(exp))) { \ >> vn_printf(vp, "VNASSERT failed\n"); \ >> - panic msg; \ >> + kassert_panic msg; \ >> } \ >> } while (0) >> #else > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 18:25:57 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB71F578; Fri, 7 Dec 2012 18:25:57 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 979548FC15; Fri, 7 Dec 2012 18:25:54 +0000 (UTC) Received: from Alfreds-MacBook-Pro-6.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 6BDA81A3C78; Fri, 7 Dec 2012 10:25:54 -0800 (PST) Message-ID: <50C234B1.6090803@mu.org> Date: Fri, 07 Dec 2012 10:25:53 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mdf@FreeBSD.org Subject: Re: svn commit: r243980 - in head/sys: kern sys References: <201212070825.qB78P9rY055786@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Alfred Perlstein , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:25:57 -0000 On 12/7/12 7:12 AM, mdf@FreeBSD.org wrote: > On Fri, Dec 7, 2012 at 6:25 AM, Adrian Chadd wrote: >> Ok, so can we now please split 'panic during debugging but we do >> handle the case' and 'panic during live runs as it really does mean >> we're hosed' assert checks, so coders can choose which is appropriate? >> >> Or does that now exist? > This should already exist, as KASSERT was only for INVARIANTS and > presumably no one runs that code in production. > > At $work we have an ugly macro but a flexible system for this -- > checks are grouped into areas, and each one has a set of sysctl nodes > defining at what level they're checked (production, debug, never), > which is compared to the global check level (off, production, debug), > and what the action is on failure (ignore, log, panic, etc.) > > It's flexible but it's also a bit awkward to work with when you don't > know if one of those VERIFY_ASSERTS will panic or not -- especially > since the error can be ignored. Perhaps we made it too flexible. > > Since KASSERT was always INVARIANTS only this is probably a step in > the right direction (though the rate check means that if one error > fires, other errors of a different type will be ignored). Making it > more fine grained so individual checks can be enabled at runtime > instead of compile time, etc., would be useful to some vendors. But > all that flexibility has a cost in object code and runtime for the > embedded world, so it's a tradeoff too. Yes! :) I've done something in the past for debug where each assert/whatever was under a "subsystem" so you would have ASSERT(subsystem, cond, "message",...). I started thinking about passing __FILE__ in and allowing a table (modifiable via sysctl) of strings to compare against to decide "panic" "log" "ignore", but then I realized that should wait for another day after the community looks at the current facility. If people have more ideas I'd love to hear them. -Alfred > > Cheers, > matthew > >> On 7 December 2012 00:25, Alfred Perlstein wrote: >>> Author: alfred >>> Date: Fri Dec 7 08:25:08 2012 >>> New Revision: 243980 >>> URL: http://svnweb.freebsd.org/changeset/base/243980 >>> >>> Log: >>> Allow KASSERT to log instead of panic. >>> >>> This is to allow debug images to be used without taking down the >>> system when non-fatal asserts are hit. >>> >>> The following sysctls are added: >>> >>> debug.kassert.warn_only: 1 = log, 0 = panic >>> >>> debug.kassert.do_ktr: set to a ktr mask for logging via KTR >>> >>> debug.kassert.do_log: 1 = log, 0 = quiet >>> >>> debug.kassert.warnings: stats, number of kasserts hit >>> >>> debug.kassert.log_panic_at: >>> number of kasserts before we actually panic, 0 = never >>> >>> debug.kassert.log_pps_limit: pps limit for log messages >>> >>> debug.kassert.log_mute_at: stop warning after N kasserts, 0 = never stop >>> >>> debug.kassert.kassert: set this sysctl to trigger a kassert >>> >>> Discussed with: scottl, gnn, marcel >>> Sponsored by: iXsystems >>> >>> Modified: >>> head/sys/kern/kern_shutdown.c >>> head/sys/sys/systm.h >>> >>> Modified: head/sys/kern/kern_shutdown.c >>> ============================================================================== >>> --- head/sys/kern/kern_shutdown.c Fri Dec 7 07:24:15 2012 (r243979) >>> +++ head/sys/kern/kern_shutdown.c Fri Dec 7 08:25:08 2012 (r243980) >>> @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -150,6 +151,7 @@ static void poweroff_wait(void *, int); >>> static void shutdown_halt(void *junk, int howto); >>> static void shutdown_panic(void *junk, int howto); >>> static void shutdown_reset(void *junk, int howto); >>> +static void vpanic(const char *fmt, va_list ap) __dead2; >>> >>> /* register various local shutdown events */ >>> static void >>> @@ -538,6 +540,120 @@ shutdown_reset(void *junk, int howto) >>> /* NOTREACHED */ /* assuming reset worked */ >>> } >>> >>> +#ifdef INVARIANTS >>> +static int kassert_warn_only = 0; >>> +#ifdef KTR >>> +static int kassert_do_ktr = 0; >>> +#endif >>> +static int kassert_do_log = 1; >>> +static int kassert_log_pps_limit = 4; >>> +static int kassert_log_mute_at = 0; >>> +static int kassert_log_panic_at = 0; >>> +static int kassert_warnings = 0; >>> + >>> +SYSCTL_NODE(_debug, OID_AUTO, kassert, CTLFLAG_RW, NULL, "kassert options"); >>> + >>> +SYSCTL_INT(_debug_kassert, OID_AUTO, warn_only, CTLFLAG_RW | CTLFLAG_TUN, >>> + &kassert_warn_only, 0, >>> + "KASSERT triggers a panic (1) or just a warning (0)"); >>> +TUNABLE_INT("debug.kassert.warn_only", &kassert_warn_only); >>> + >>> +#ifdef KTR >>> +SYSCTL_UINT(_debug_kassert, OID_AUTO, do_ktr, CTLFLAG_RW | CTLFLAG_TUN, >>> + &kassert_do_ktr, 0, >>> + "KASSERT does a KTR, set this to the KTRMASK you want"); >>> +TUNABLE_INT("debug.kassert.do_ktr", &kassert_do_ktr); >>> +#endif >>> + >>> +SYSCTL_INT(_debug_kassert, OID_AUTO, do_log, CTLFLAG_RW | CTLFLAG_TUN, >>> + &kassert_do_log, 0, "KASSERT triggers a panic (1) or just a warning (0)"); >>> +TUNABLE_INT("debug.kassert.do_log", &kassert_do_log); >>> + >>> +SYSCTL_INT(_debug_kassert, OID_AUTO, warnings, CTLFLAG_RW | CTLFLAG_TUN, >>> + &kassert_warnings, 0, "number of KASSERTs that have been triggered"); >>> +TUNABLE_INT("debug.kassert.warnings", &kassert_warnings); >>> + >>> +SYSCTL_INT(_debug_kassert, OID_AUTO, log_panic_at, CTLFLAG_RW | CTLFLAG_TUN, >>> + &kassert_log_panic_at, 0, "max number of KASSERTS before we will panic"); >>> +TUNABLE_INT("debug.kassert.log_panic_at", &kassert_log_panic_at); >>> + >>> +SYSCTL_INT(_debug_kassert, OID_AUTO, log_pps_limit, CTLFLAG_RW | CTLFLAG_TUN, >>> + &kassert_log_pps_limit, 0, "limit number of log messages per second"); >>> +TUNABLE_INT("debug.kassert.log_pps_limit", &kassert_log_pps_limit); >>> + >>> +SYSCTL_INT(_debug_kassert, OID_AUTO, log_mute_at, CTLFLAG_RW | CTLFLAG_TUN, >>> + &kassert_log_mute_at, 0, "max number of KASSERTS to log"); >>> +TUNABLE_INT("debug.kassert.log_mute_at", &kassert_log_mute_at); >>> + >>> +static int kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS); >>> + >>> +SYSCTL_PROC(_debug_kassert, OID_AUTO, kassert, >>> + CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_SECURE, NULL, 0, >>> + kassert_sysctl_kassert, "I", "set to trigger a test kassert"); >>> + >>> +static int >>> +kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS) >>> +{ >>> + int error, i; >>> + >>> + error = sysctl_wire_old_buffer(req, sizeof(int)); >>> + if (error == 0) { >>> + i = 0; >>> + error = sysctl_handle_int(oidp, &i, 0, req); >>> + } >>> + if (error != 0 || req->newptr == NULL) >>> + return (error); >>> + KASSERT(0, ("kassert_sysctl_kassert triggered kassert %d", i)); >>> + return (0); >>> +} >>> + >>> +/* >>> + * Called by KASSERT, this decides if we will panic >>> + * or if we will log via printf and/or ktr. >>> + */ >>> +void >>> +kassert_panic(const char *fmt, ...) >>> +{ >>> + static char buf[256]; >>> + va_list ap; >>> + >>> + va_start(ap, fmt); >>> + (void)vsnprintf(buf, sizeof(buf), fmt, ap); >>> + va_end(ap); >>> + >>> + /* >>> + * panic if we're not just warning, or if we've exceeded >>> + * kassert_log_panic_at warnings. >>> + */ >>> + if (!kassert_warn_only || >>> + (kassert_log_panic_at > 0 && >>> + kassert_warnings >= kassert_log_panic_at)) { >>> + va_start(ap, fmt); >>> + vpanic(fmt, ap); >>> + /* NORETURN */ >>> + } >>> +#ifdef KTR >>> + if (kassert_do_ktr) >>> + CTR0(ktr_mask, buf); >>> +#endif /* KTR */ >>> + /* >>> + * log if we've not yet met the mute limit. >>> + */ >>> + if (kassert_do_log && >>> + (kassert_log_mute_at == 0 || >>> + kassert_warnings < kassert_log_mute_at)) { >>> + static struct timeval lasterr; >>> + static int curerr; >>> + >>> + if (ppsratecheck(&lasterr, &curerr, kassert_log_pps_limit)) { >>> + printf("KASSERT failed: %s\n", buf); >>> + kdb_backtrace(); >>> + } >>> + } >>> + atomic_add_int(&kassert_warnings, 1); >>> +} >>> +#endif >>> + >>> /* >>> * Panic is called on unresolvable fatal errors. It prints "panic: mesg", >>> * and then reboots. If we are called twice, then we avoid trying to sync >>> @@ -546,12 +662,20 @@ shutdown_reset(void *junk, int howto) >>> void >>> panic(const char *fmt, ...) >>> { >>> + va_list ap; >>> + >>> + va_start(ap, fmt); >>> + vpanic(fmt, ap); >>> +} >>> + >>> +static void >>> +vpanic(const char *fmt, va_list ap) >>> +{ >>> #ifdef SMP >>> cpuset_t other_cpus; >>> #endif >>> struct thread *td = curthread; >>> int bootopt, newpanic; >>> - va_list ap; >>> static char buf[256]; >>> >>> spinlock_enter(); >>> @@ -587,7 +711,6 @@ panic(const char *fmt, ...) >>> newpanic = 1; >>> } >>> >>> - va_start(ap, fmt); >>> if (newpanic) { >>> (void)vsnprintf(buf, sizeof(buf), fmt, ap); >>> panicstr = buf; >>> @@ -598,7 +721,6 @@ panic(const char *fmt, ...) >>> vprintf(fmt, ap); >>> printf("\n"); >>> } >>> - va_end(ap); >>> #ifdef SMP >>> printf("cpuid = %d\n", PCPU_GET(cpuid)); >>> #endif >>> >>> Modified: head/sys/sys/systm.h >>> ============================================================================== >>> --- head/sys/sys/systm.h Fri Dec 7 07:24:15 2012 (r243979) >>> +++ head/sys/sys/systm.h Fri Dec 7 08:25:08 2012 (r243980) >>> @@ -73,14 +73,16 @@ extern int vm_guest; /* Running as virt >>> enum VM_GUEST { VM_GUEST_NO = 0, VM_GUEST_VM, VM_GUEST_XEN }; >>> >>> #ifdef INVARIANTS /* The option is always available */ >>> +void kassert_panic(const char *fmt, ...); >>> + >>> #define KASSERT(exp,msg) do { \ >>> if (__predict_false(!(exp))) \ >>> - panic msg; \ >>> + kassert_panic msg; \ >>> } while (0) >>> #define VNASSERT(exp, vp, msg) do { \ >>> if (__predict_false(!(exp))) { \ >>> vn_printf(vp, "VNASSERT failed\n"); \ >>> - panic msg; \ >>> + kassert_panic msg; \ >>> } \ >>> } while (0) >>> #else >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 18:31:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F19CB675; Fri, 7 Dec 2012 18:31:09 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D0A9E8FC12; Fri, 7 Dec 2012 18:31:09 +0000 (UTC) Received: from Alfreds-MacBook-Pro-6.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 880C81A3CD6; Fri, 7 Dec 2012 10:31:09 -0800 (PST) Message-ID: <50C235EC.2050903@mu.org> Date: Fri, 07 Dec 2012 10:31:08 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r243980 - in head/sys: kern sys References: <201212070825.qB78P9rY055786@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:31:10 -0000 On 12/7/12 6:25 AM, Adrian Chadd wrote: > Ok, so can we now please split 'panic during debugging but we do > handle the case' and 'panic during live runs as it really does mean > we're hosed' assert checks, so coders can choose which is appropriate? > > Or does that now exist? I'm not sure I'm understanding the requirement. We have places in the code that explicitly call panic that I know of that a KASSERT is not right because if the condition is caught then the kernel will die badly. Example (from subr_turnstile.c): > /* > * If the thread is asleep, then we are probably about > * to deadlock. To make debugging this easier, just > * panic and tell the user which thread misbehaved so > * they can hopefully get a stack trace from the truly > * misbehaving thread. > */ > if (TD_IS_SLEEPING(td)) { > printf( > "Sleeping thread (tid %d, pid %d) owns a non-sleepable > lock\n", > td->td_tid, td->td_proc->p_pid); > kdb_backtrace_thread(td); > panic("sleeping thread"); > } Or do you mean something else? Propose an API! :) Let's see where this goes. -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 23:03:31 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B123ACC2; Fri, 7 Dec 2012 23:03:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDDE48FC0C; Fri, 7 Dec 2012 23:03:30 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so524696wey.13 for ; Fri, 07 Dec 2012 15:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oKX30tmFUpX/N2jwBuxGyy4Lw+mmVzZ/L4AF+bvRv/I=; b=d6zRvOe9foldER2Vh4Oh6bfbYuTFD7UCbOvstHEEaKau4CZqpIHO2l24HVekH0HVR8 lTzy9MydorK/OMamEsFg+tB4rvYpKamC6WnjSq9njj3h3Jy/X8FgE/rQmVyif2QAFTR0 X7oylmYU/I80tXjkd84DHyNmA04EFpJKBuiN57iwnWtX+myAhf4tLnWpwonqzAb8s+JT itEdA+Sa7QxcxvLX/RKcLyWiHLmJFweD8X6xZYVsWx3+JlKGpTzDWsW/hoj9jduhdN4V jgx4PINZB089Fy9M54mQIWVnhlWa4syo7sxOBqEw7OqvjkQQPgnHyVMgXBECWn9Gt7AR zvXw== MIME-Version: 1.0 Received: by 10.180.88.71 with SMTP id be7mr871410wib.17.1354921403986; Fri, 07 Dec 2012 15:03:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 7 Dec 2012 15:03:23 -0800 (PST) In-Reply-To: <50C26BF9.1050106@mu.org> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> Date: Fri, 7 Dec 2012 15:03:23 -0800 X-Google-Sender-Auth: CxMjfG0ovpuiIxrNIk-UGoCjUpA Message-ID: Subject: Re: svn commit: r243594 - head/sys/netinet From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: Alfred Perlstein , Andre Oppermann , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:03:31 -0000 Alfred, I can make the same argument about "out of the box" experiences with Linux and FreeBSD on embedded. If the embedded experience out of the box "isn't as good or better" than Linux, people will go with Linux. I think you're only really considering the server space. The bigger issue here is "people who are changing the algorithms are making different but same mistakes as the earlier algorithms", which is "works for me,". Solving a lot of this stuff for both small and large scale doesn't _have_ to be too difficult. The current attempt at making things nicer for the server space has shown it doesn't work for the non-server space. That means the problem isn't fully understood. Honestly, I'd rather see a lot of this auto-tuning be done at run-time rather than compile or boot time, with some relatively smart tools that can look at the system specifications and current mbuf/allocator configuration, look at some historical information about allocations, and make suggestions about what can be tuned. You can _also_ make the defaults work well on the low end and the high end. The tool(s) shouldn't be _instead_ of that, it should be _with_ that. Let's try to understand the problem space a bit better before we start changing things some more. It's obvious from the recent changes that people don't understand the bigger picture. Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 23:16:00 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2572AEEB; Fri, 7 Dec 2012 23:16:00 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 002818FC0C; Fri, 7 Dec 2012 23:15:59 +0000 (UTC) Received: from Alfreds-MacBook-Pro-6.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id C089D1A3C31; Fri, 7 Dec 2012 15:15:59 -0800 (PST) Message-ID: <50C278B0.3040107@mu.org> Date: Fri, 07 Dec 2012 15:16:00 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r243594 - head/sys/netinet References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , Andre Oppermann , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:16:00 -0000 I'm sorry Adrian, the difference between installing a server OS with a CDROM/USBkey is vastly different than the type of user that is using an embedded board. The embedded user will be doing so over some weird install media, using serial and all kinds of other things. If you have tunables or compile time options you want to distribute on MIPS/arm, then by all means force TCBHASH to 512. You can easily make a "small memory kernel include file" for this. Please do it. Please make ARM/MIPS/whatever better for you. As far as some pipe-dream runtime tuning, all singing/dancing thingy to make everything happy, well that doesn't exist. So either write it, or take a pragmatic approach and fix your platforms and please stop standing in the way of server OS. -Alfred On 12/7/12 3:03 PM, Adrian Chadd wrote: > Alfred, > > I can make the same argument about "out of the box" experiences with > Linux and FreeBSD on embedded. > > If the embedded experience out of the box "isn't as good or better" > than Linux, people will go with Linux. > > I think you're only really considering the server space. The bigger > issue here is "people who are changing the algorithms are making > different but same mistakes as the earlier algorithms", which is > "works for me,". > > Solving a lot of this stuff for both small and large scale doesn't > _have_ to be too difficult. The current attempt at making things nicer > for the server space has shown it doesn't work for the non-server > space. That means the problem isn't fully understood. > > Honestly, I'd rather see a lot of this auto-tuning be done at run-time > rather than compile or boot time, with some relatively smart tools > that can look at the system specifications and current mbuf/allocator > configuration, look at some historical information about allocations, > and make suggestions about what can be tuned. > > You can _also_ make the defaults work well on the low end and the high > end. The tool(s) shouldn't be _instead_ of that, it should be _with_ > that. > > Let's try to understand the problem space a bit better before we start > changing things some more. It's obvious from the recent changes that > people don't understand the bigger picture. > > > > Adrian > From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 23:32:00 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AB7A3F2 for ; Fri, 7 Dec 2012 23:32:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id D81B18FC12 for ; Fri, 7 Dec 2012 23:31:59 +0000 (UTC) Received: by mail-gg0-f182.google.com with SMTP id e5so190443ggh.13 for ; Fri, 07 Dec 2012 15:31:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IBvJx6VLpqkCSwWKaXfzaoehWSsfi+6ZE3uxqJ1iNnU=; b=VC+gi8VbaCE/y0WfoRc7pvclyR10dzNs0IEn3Zl5grRrUXMDcmzKb1wgzAHkED5mRU n9p30gJIpWIiky7LsDo+hMcIfpGVeWDh0skK3zZYYR5mFTI1e9HDoKjO4hx4yBIeySsG tnufyL5hxdStxxt6RI+aCgR86VOINfSJ4x0YnQs0Wo4QWSmk6WXd+oh0Uj2mG+UTTTbl NbeHRA63zmbhDkL9h1xXZtWtYj/OLvEZEPb2SgHwb8v6VpUfJ7QjjPs+W6GQ2etxAGr6 Usqd0R19k7d7eJspfVJStRHHWtIOaRmcQeVEWuEgehCJI+bEJ/6OjUWKGBYOnQw/9nGF FslA== Received: by 10.236.130.106 with SMTP id j70mr10740521yhi.0.1354923118783; Fri, 07 Dec 2012 15:31:58 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id u22sm15393185yhl.2.2012.12.07.15.31.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 15:31:57 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r243594 - head/sys/netinet Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50C278B0.3040107@mu.org> Date: Fri, 7 Dec 2012 16:31:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk3n2UmiaG0OfOAyxCwQkTrVPcj7Nd1XU90CKBV0Kh5giFCk6vFwqqAMRmvd7CYuuVg5RRu Cc: Adrian Chadd , Alfred Perlstein , Andre Oppermann , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:32:00 -0000 On Dec 7, 2012, at 4:16 PM, Alfred Perlstein wrote: > I'm sorry Adrian, the difference between installing a server OS with a = CDROM/USBkey is vastly different than the type of user that is using an = embedded board. >=20 > The embedded user will be doing so over some weird install media, = using serial and all kinds of other things. >=20 > If you have tunables or compile time options you want to distribute on = MIPS/arm, then by all means force TCBHASH to 512. >=20 > You can easily make a "small memory kernel include file" for this. >=20 > Please do it. Please make ARM/MIPS/whatever better for you. >=20 > As far as some pipe-dream runtime tuning, all singing/dancing thingy = to make everything happy, well that doesn't exist. >=20 > So either write it, or take a pragmatic approach and fix your = platforms and please stop standing in the way of server OS. Nobody is standing in the way of the server OS when we point out that = the tuning for the server actively breaks small systems. That's called = bug reporting, something any sane organization would reply with "oh, = let's fix the bug" rather than a raft of finger pointing. The bug here = is that the system will not boot at all for lower memory configurations. = "Tuning for servers" isn't a get-out-of-jail-free card for this bug. Seriously though, we should have these kinds of tuning in files that = different platforms include or not depending on what the system is being = tuned for. We can even put them in GENERIC for amd64 if you want, = that's fine so the out-of-the-box experience is tuned for big-iron = servers. But to require all hardware that isn't big iron to hand-tune = dozens of parameters (or even just a dozen) is going to end in tears. To summarize: we agree on the goal, and disagree that the current = approach is sane, Warner > -Alfred >=20 > On 12/7/12 3:03 PM, Adrian Chadd wrote: >> Alfred, >>=20 >> I can make the same argument about "out of the box" experiences with >> Linux and FreeBSD on embedded. >>=20 >> If the embedded experience out of the box "isn't as good or better" >> than Linux, people will go with Linux. >>=20 >> I think you're only really considering the server space. The bigger >> issue here is "people who are changing the algorithms are making >> different but same mistakes as the earlier algorithms", which is >> "works for me,". >>=20 >> Solving a lot of this stuff for both small and large scale doesn't >> _have_ to be too difficult. The current attempt at making things = nicer >> for the server space has shown it doesn't work for the non-server >> space. That means the problem isn't fully understood. >>=20 >> Honestly, I'd rather see a lot of this auto-tuning be done at = run-time >> rather than compile or boot time, with some relatively smart tools >> that can look at the system specifications and current mbuf/allocator >> configuration, look at some historical information about allocations, >> and make suggestions about what can be tuned. >>=20 >> You can _also_ make the defaults work well on the low end and the = high >> end. The tool(s) shouldn't be _instead_ of that, it should be _with_ >> that. >>=20 >> Let's try to understand the problem space a bit better before we = start >> changing things some more. It's obvious from the recent changes that >> people don't understand the bigger picture. >>=20 >>=20 >>=20 >> Adrian >>=20 >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 23:38:38 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E9BE61E; Fri, 7 Dec 2012 23:38:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D0DBE8FC08; Fri, 7 Dec 2012 23:38:37 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so534695wey.13 for ; Fri, 07 Dec 2012 15:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JFjpZ+zLZsyfmV0mQ6xlY7zIrHzdhrJ4H3KoiNnH2xc=; b=aATVNXSBjJeB4MlNxH6CmspSa8O5fxZ4nGhIBJQLy37y8t08r1Dj9rPvyucNI7KeiN +9ZFOjycZc6YsNyEtvVKAZyUCOGNJSwbSygu4wuknAQO2pVKwQM/l/IllNllJ45eVBNJ F8WV/YM3SwrA8xf5rakzslA6W4oGq16DQhzRwGS8J4YRztPOIm4hFVyYA4K1GdJI1dqV gkhocxYY8jECSgG0Z4eQj+FULo19qQr+IyQgFpJBzx3VZxVGZqaowuz1S7RVW8WBOFmw tkh/3VK5OrkkTOLIttIyUB29k355/MdLcPg52kr9ZQGF8oi/Ou53q5oIkxabrVARpPGr cNSQ== MIME-Version: 1.0 Received: by 10.180.97.137 with SMTP id ea9mr991300wib.13.1354923516865; Fri, 07 Dec 2012 15:38:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 7 Dec 2012 15:38:36 -0800 (PST) In-Reply-To: <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> Date: Fri, 7 Dec 2012 15:38:36 -0800 X-Google-Sender-Auth: U2Zh6KxyZrBcJK8cPE_HPjNrEQE Message-ID: Subject: Re: svn commit: r243594 - head/sys/netinet From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Alfred Perlstein , Andre Oppermann , Alfred Perlstein , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:38:38 -0000 ..right. I could spin the argument back to you Alfred and say "make the default compile time settings for i386/amd64/sparc64 GENERIC to have bigger TCP hash sizes, default mbuf tuning, larger kernel dmesg buffer sizes, increased mutex hash table sizes, etc, and leave the defaults as they are. What I'm trying to say/encourage is some more even-handed ways of doing this, rather than "hey, it works in the server world, that's all that matters, right?" And FYI - installation on embedded devices these days is "open device web page, upload firmware image, hit "flash", reboot." That's what openwrt and dd-wrt do for the majority of their platforms. No serial console required. As I said, I don't think everyone invested in this is seeing the bigger picture and trying to work out whether we can solve this in a better fashion. The peeps in the Linux world _have_ come up with _a_ solution that seems to work. So it's not that its intractable. Adrian From owner-freebsd-arch@FreeBSD.ORG Sat Dec 8 00:02:35 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D490EA4; Sat, 8 Dec 2012 00:02:35 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 483CD8FC17; Sat, 8 Dec 2012 00:02:34 +0000 (UTC) Received: from Alfreds-MacBook-Pro-6.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 668E71A3C31; Fri, 7 Dec 2012 16:02:34 -0800 (PST) Message-ID: <50C2839B.30709@mu.org> Date: Fri, 07 Dec 2012 16:02:35 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r243594 - head/sys/netinet References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , Andre Oppermann , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 00:02:35 -0000 On 12/7/12 3:38 PM, Adrian Chadd wrote: > ..right. I could spin the argument back to you Alfred and say "make > the default compile time settings for i386/amd64/sparc64 GENERIC to > have bigger TCP hash sizes, default mbuf tuning, larger kernel dmesg > buffer sizes, increased mutex hash table sizes, etc, and leave the > defaults as they are. > > What I'm trying to say/encourage is some more even-handed ways of > doing this, rather than "hey, it works in the server world, that's all > that matters, right?" > > And FYI - installation on embedded devices these days is "open device > web page, upload firmware image, hit "flash", reboot." That's what > openwrt and dd-wrt do for the majority of their platforms. No serial > console required. > > As I said, I don't think everyone invested in this is seeing the > bigger picture and trying to work out whether we can solve this in a > better fashion. The peeps in the Linux world _have_ come up with _a_ > solution that seems to work. So it's not that its intractable. Adrian, then tell me what to do other than "wait". Figure it out, let's iterate and shake out the issues already. -Alfred From owner-freebsd-arch@FreeBSD.ORG Sat Dec 8 00:43:41 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF6F9236 for ; Sat, 8 Dec 2012 00:43:41 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9C08FC12 for ; Sat, 8 Dec 2012 00:43:41 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id qB80hdST015233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 7 Dec 2012 18:43:39 -0600 Resent-Message-Id: <201212080043.qB80hdST015233@ltcfislmsgpa03.fnfis.com> Received: from [10.0.0.102] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 7 Dec 2012 18:43:38 -0600 Subject: PR conf/121064 -- [patch] sys/boot/forth -- Use ASCII characters for box/line characters in frames.4th MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske Resent-Cc: Adrian Chadd , Garrett Cooper , Devin Teske Resent-From: Devin Teske Date: Fri, 7 Dec 2012 13:39:11 -0800 Resent-Date: Fri, 7 Dec 2012 16:43:37 -0800 Resent-To: Message-ID: To: Adrian Chadd X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-12-07_04:2012-12-07,2012-12-07,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Devin Teske , Garrett Cooper X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 00:43:41 -0000 Hi -arch, Eitan brought PR conf/121064 to my attention. This particular PR appears to be ~5 years old and addresses an ~10 year old= issue introduced by SVN r115410 Below is the commit message and patch that I'm proposing to commit for this= PR (also, I amended said patch to the PR audit trail; see conf/121064). I asked gcooper to review the working/tested patch. Here's a before/after shot (courtesy of jh) -- against 9.0-R: http://twitpic.com/bjxfcz Please let me know if you have any objections, feature-requests, nagging fe= elings, etc. --=20 Cheers, Devin =3D=3D=3D Use ASCII characters for box/line characters in frames.4th Committed with changes to support the following from loader.conf(5): + console=3D"vidconsole comconsole" (not just console=3D"comconsole") + boot_serial=3D"anything" (not just boot_serial=3D"YES") + boot_multicons=3D"anything" (unsupported in originally-submitted patch) PR: conf/121064 Submitted by: koitsu Reviewed by: gcooper, adrian (co-mentor) [pending your review] Approved by: adrian (co-mentor) [pending your approval] Obtained from: MFC after: Security: --This line, and those below, will be ignored-- > Description of fields to fill in above: 76 columns --| > PR: If a GNATS PR is affected by the change. > Submitted by: If someone else sent in the change. > Reviewed by: If someone else reviewed your modification. > Approved by: If you needed approval for this commit. > Obtained from: If the change is from a third party. > MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. > Security: Vulnerability reference (one per line) or description. > Empty fields above will be automatically removed. M forth/support.4th M forth/frames.4th _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Sat Dec 8 06:33:46 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B098059A; Sat, 8 Dec 2012 06:33:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id E0F298FC08; Sat, 8 Dec 2012 06:33:45 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so702868wgh.31 for ; Fri, 07 Dec 2012 22:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wItnmHsEWFIzU3ZwqU3MXJrvQbRi1gRtVwKb3+iIo8U=; b=WJK7vU3pqQU4Ji93dSI16egznue7TCW24rJLIWxjrOA8pL0tuTHeIKPVwS4D+Y+hbE GjRBAkU0+UdIz2hUSNJkPkfsYbeJH+3dGvGLzFoA1eCUG+G2Pzj4lPK/UOG11RjirS/V UWb+tazDkF44wI/B3KP9qWCSTWVl0dg09hhhHCJvavj6Dq6Xrnu8v0MmrV0Eua1sC5LD ikrTCqajVmiwAPuorO+GPURlD0EjaLWV5AWDD8s1Q2pooKcttwjnJJ9O4w2ecWQFNjDp 5NRQ8hoqEwEmzU9u604J+Yud+Ke/ndm/Fa14DKwaF2H7uSELH/535WYaKSVAw4Q6B7JE YLKw== MIME-Version: 1.0 Received: by 10.216.200.160 with SMTP id z32mr2915611wen.53.1354948419014; Fri, 07 Dec 2012 22:33:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 7 Dec 2012 22:33:38 -0800 (PST) In-Reply-To: <50C2839B.30709@mu.org> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> <50C2839B.30709@mu.org> Date: Fri, 7 Dec 2012 22:33:38 -0800 X-Google-Sender-Auth: SA7H2x4SjygOqLC00KCSILBU4oQ Message-ID: Subject: Re: svn commit: r243594 - head/sys/netinet From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: Alfred Perlstein , Andre Oppermann , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 06:33:46 -0000 I suggest something with some numbers/figures that we can look at and plot. Specifically: * Let's map out what the inputs are (eg total memory, total VM space) * Let's map out what the outputs are (eg UMA zone sizing, total mbufs allowed, etc) * Let's plot what the current, pre-latest-fiddling-in-current code does; * Let's plot what you and Andre think it should be, and then we can see how that works on the RAM constrained platforms; * Let's have a bit of a chat about it. Until Oleksandr and Andre figure out exactly why Andre's tweaks have broken memory allocation on ARM (and until he and I stare at MIPS a bit more, especially on the RAM constrained AP platforms) we can only guess what the underlying reasons for his issues are. Oleksandr thinks "fragmentation", but we just don't know. So that's worth figuring out. You don't have to wait. There's plenty to do. Heck, I wonder what platform Oleksandr is using where an ARM board has 1GB of RAM. Maybe we should get some more of those for people to play with. Adrian From owner-freebsd-arch@FreeBSD.ORG Sat Dec 8 20:54:06 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83977C8F for ; Sat, 8 Dec 2012 20:54:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DA8E68FC0C for ; Sat, 8 Dec 2012 20:54:05 +0000 (UTC) Received: (qmail 60427 invoked from network); 8 Dec 2012 22:23:40 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Dec 2012 22:23:40 -0000 Message-ID: <50C3A8E4.3000401@freebsd.org> Date: Sat, 08 Dec 2012 21:53:56 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r243594 - head/sys/netinet References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> <50C2839B.30709@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , Alfred Perlstein , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 20:54:06 -0000 On 08.12.2012 07:33, Adrian Chadd wrote: > I suggest something with some numbers/figures that we can look at and plot. > > Specifically: > > * Let's map out what the inputs are (eg total memory, total VM space) > * Let's map out what the outputs are (eg UMA zone sizing, total mbufs > allowed, etc) > * Let's plot what the current, pre-latest-fiddling-in-current code does; > * Let's plot what you and Andre think it should be, and then we can > see how that works on the RAM constrained platforms; > * Let's have a bit of a chat about it. I think there are a couple of things being mixed up here. One is the ARM problem. This is related to maxusers. See further down. Two is setting limits for a maximal amount of mbufs in the system. This is 50% of real memory or kmem, whichever is lower, by default. Previously certain types where not limited and others were limited based on maxusers. This was overestimating on small memory configs and severely underestimating on large memory configs. Three is setting limits for maxfiles/maxsockets. This is now scaled according to memory as well. Previously it was derived from maxusers as well with the same trouble as in point two. Four is deciding on an optimal hash table size for TCP control blocks. The number of concurrent tcp connections is limited by maxsockets. The point of contention here is with which fraction of the maxsockets value the hash table should end up. The hash table chains entries when a hash bucket collision happens. So no limit there. It all ends up with a time vs. space tradeoff in the hash table. Any of the proposals being discussed is better than what we had before (fixed 512 hash buckets). > Until Oleksandr and Andre figure out exactly why Andre's tweaks have > broken memory allocation on ARM (and until he and I stare at MIPS a > bit more, especially on the RAM constrained AP platforms) we can only > guess what the underlying reasons for his issues are. Oleksandr thinks > "fragmentation", but we just don't know. So that's worth figuring out. There seems to be a problem with sf_buf kmap allocation at least on ARM which results in the kernel becoming unable to allocate a stack for threads and processes. The sf_buf kmap is derived from maxusers which is derived from phypages. Why exactly a kmap allocation of 27MB hoses the whole kernel is not yet understood. > You don't have to wait. There's plenty to do. Heck, I wonder what > platform Oleksandr is using where an ARM board has 1GB of RAM. Maybe > we should get some more of those for people to play with. Your favorite smartphone likely has 512MB-1GB of RAM. -- Andre From owner-freebsd-arch@FreeBSD.ORG Sat Dec 8 21:55:27 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D615C9BF; Sat, 8 Dec 2012 21:55:27 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 87A5C8FC08; Sat, 8 Dec 2012 21:55:27 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qB8LnPBP036937; Sat, 8 Dec 2012 21:49:26 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 34bsysu4qwekqzxsggxw42y73n; Sat, 08 Dec 2012 21:49:25 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: svn commit: r243594 - head/sys/netinet Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <50C3A8E4.3000401@freebsd.org> Date: Sat, 8 Dec 2012 13:49:24 -0800 Content-Transfer-Encoding: 7bit Message-Id: <2305DE0C-D8D0-49F0-8D69-B5091AA9D2CD@kientzle.com> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> <50C2839B.30709@mu.org> <50C3A8E4.3000401@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , Alfred Perlstein , Alfred Perlstein , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 21:55:28 -0000 On Dec 8, 2012, at 12:53 PM, Andre Oppermann wrote: > On 08.12.2012 07:33, Adrian Chadd wrote: > >> .... Heck, I wonder what >> platform Oleksandr is using where an ARM board has 1GB of RAM. Maybe >> we should get some more of those for people to play with. > > Your favorite smartphone likely has 512MB-1GB of RAM. PandaBoard has 1GB RAM. RaspberryPi has 512MB. Tim