From owner-freebsd-arch@FreeBSD.ORG Mon Apr 2 15:11:53 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EEE106564A; Mon, 2 Apr 2012 15:11:53 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 62E738FC15; Mon, 2 Apr 2012 15:11:49 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 62139D480EC; Mon, 2 Apr 2012 17:11:43 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 2AE622414; Mon, 2 Apr 2012 15:11:42 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id ED50A9978; Mon, 2 Apr 2012 15:11:41 +0000 (UTC) Date: Mon, 2 Apr 2012 17:11:41 +0200 From: Jeremie Le Hen To: Pawel Jakub Dawidek Message-ID: <20120402151141.GA14531@felucia.tataz.chchile.org> Mail-Followup-To: Pawel Jakub Dawidek , Attilio Rao , Konstantin Belousov , arch@freebsd.org References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <20120225151334.GH1344@garage.freebsd.pl> <20120225194630.GI1344@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120225194630.GI1344@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Attilio Rao , Konstantin Belousov , arch@freebsd.org Subject: Re: Prefaulting for i/o buffers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:11:53 -0000 Hi, On Sat, Feb 25, 2012 at 08:46:31PM +0100, Pawel Jakub Dawidek wrote: > > I did not implement rangelocking for ZFS. It came with ZFS when I ported > it. Until we want to merge changes from upstream (which is now IllumOS) > we don't want to make huge changes just for the sake of proving that > this is general purpose mechanism used by more than one file system. > > Attilio, don't get me wrong. In 99% cases it is good to make code more > general and more universal and reusable, but we can't ignore reality. > > There are reasons why file systems like XFS, ReiserFS and others where > never fully ported. I'm not saying VFS complexity was the only reason, > but I'm sure it was one of them. > > Our VFS is very UFS-centric. We make so many assumptions that sounds > fine only for UFS. I saw plenty of those while working on ZFS, like: > > - "Every file system needs cache. Let's make it general, so that all file > systems can use it!" Well, for VFS each file system is a separate > entity, which is not the case for ZFS. ZFS can cache one block only > once that is used by one file system, 10 clones and 100 snapshots, > which all are separate mount points from VFS perspective. > The same block would be cached 111 times by the buffer cache. > > - "rmdir(2) on a mountpoint is bad idea, let's deny it at VFS level." > It is bad idea, indeed, but in ZFS it is a nice way to remove snapshot > by rmdiring .zfs/snapshot/ directory. > > - Noone implemented rangelocking in VFS, so no file system can use it. > Even if the given file system has all the code to do it. > > etc. > > I'm also sure it will be way easier for Jeff to make VFS MP-safe if it > was less complex. > > When looking at the big picture, it would be nice to have all this > general stuff like rangelocking, quota, buffer cache, etc. as some kind > of libraries for file systems to use and not something that is > mandatory. If I develop a file system for FreeBSD only and I don't want > to reinvent the wheel, I can use those libraries. If I port file system > to FreeBSD or develop a file system that doesn't really need those > libraries I'm not forced to use them. I'm a little late on this thread, but I had to mention that there was a very interesting article on LWN a few years ago about the "midlayer mistake" design pattern, which really reminds me the subject here. http://lwn.net/Articles/336262/ Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-arch@FreeBSD.ORG Mon Apr 2 18:13:46 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2651106564A for ; Mon, 2 Apr 2012 18:13:46 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id B45298FC12 for ; Mon, 2 Apr 2012 18:13:46 +0000 (UTC) Received: from [172.25.16.174] (unknown [173.252.71.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 6F6D42841A for ; Mon, 2 Apr 2012 11:04:27 -0700 (PDT) From: Jason Evans Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 11:04:26 -0700 Message-Id: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> To: arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: Subject: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:13:46 -0000 I've been working on integrating jemalloc back into FreeBSD's libc, and = ran into the lack of TLS on ARM and MIPS. Is this something that's = likely to be addressed soon? If not, I'm going to have to modify libthr = to deal with TSD bootstrapping issues -- FreeBSD's pthreads = implementation *loves* to call malloc. =3D( While I'm asking about TLS, it's worth asking whether any of the other = platforms still lack TLS support for non-PIC binaries. If so, that will = force the TSD issue anyway. Thanks, Jason= From owner-freebsd-arch@FreeBSD.ORG Mon Apr 2 18:29:55 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 08CE2106566B for ; Mon, 2 Apr 2012 18:29:55 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id BC3148FC0A for ; Mon, 2 Apr 2012 18:29:54 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1SEm0e-000I33-Jc; Mon, 02 Apr 2012 11:29:45 -0700 Message-ID: <4F79F020.9070504@freebsd.org> Date: Mon, 02 Apr 2012 11:29:52 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> In-Reply-To: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 02/04/2012 11:04 AM, Jason Evans wrote: > I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM and MIPS. Is this something that's likely to be addressed soon? If not, I'm going to have to modify libthr to deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =( > > While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support for non-PIC binaries. If so, that will force the TSD issue anyway. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: jasone@canonware.com Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:29:55 -0000 On 02/04/2012 11:04 AM, Jason Evans wrote: > I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM and MIPS. Is this something that's likely to be addressed soon? If not, I'm going to have to modify libthr to deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =( > > While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support for non-PIC binaries. If so, that will force the TSD issue anyway. How old is your source base? TLS support for ARM and MIPS has been committed about month ago. Revisions r232577-r232582 and r233106,r233107 fixes for ARM. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 2 20: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 045F8106566B; Mon, 2 Apr 2012 20:31:10 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id D46AF8FC0C; Mon, 2 Apr 2012 20:31:09 +0000 (UTC) Received: from [192.168.168.4] (70-91-206-178-BusName-SFBA.hfc.comcastbusiness.net [70.91.206.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id DB7FA28417; Mon, 2 Apr 2012 13:31:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Jason Evans In-Reply-To: <4F79F020.9070504@freebsd.org> Date: Mon, 2 Apr 2012 13:31:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1257) Cc: freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jasone@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:31:10 -0000 On Apr 2, 2012, at 11:29 AM, Oleksandr Tymoshenko wrote: > On 02/04/2012 11:04 AM, Jason Evans wrote: >> I've been working on integrating jemalloc back into FreeBSD's libc, = and ran into the lack of TLS on ARM and MIPS. Is this something that's = likely to be addressed soon? If not, I'm going to have to modify libthr = to deal with TSD bootstrapping issues -- FreeBSD's pthreads = implementation *loves* to call malloc. =3D( >>=20 >> While I'm asking about TLS, it's worth asking whether any of the = other platforms still lack TLS support for non-PIC binaries. If so, = that will force the TSD issue anyway. >=20 > How old is your source base? >=20 > TLS support for ARM and MIPS has been committed about month ago. > Revisions r232577-r232582 and r233106,r233107 fixes for ARM. I'm currently running sources from March 24, but I don't have ARM or = MIPS hardware. Can we remove the NO_TLS definitions in = src/lib/libc/stdlib/malloc.c? I can't test the result, of course=85 Thanks, Jason= From owner-freebsd-arch@FreeBSD.ORG Mon Apr 2 21:16:07 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 56CE31065675 for ; Mon, 2 Apr 2012 21:16:07 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id F174D8FC1D for ; Mon, 2 Apr 2012 21:16:06 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1SEobO-000Ivr-Nd; Mon, 02 Apr 2012 14:15:51 -0700 Message-ID: <4F7A170E.8020209@bluezbox.com> Date: Mon, 02 Apr 2012 14:15:58 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, jasone@canonware.com References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> In-Reply-To: <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 02/04/2012 1:31 PM, Jason Evans wrote: > On Apr 2, 2012, at 11:29 AM, Oleksandr Tymoshenko wrote: >> On 02/04/2012 11:04 AM, Jason Evans wrote: >>> I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM and MIPS. Is this something that's likely to be addressed soon? If not, I'm going to have to modify libthr to deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =( >>> >>> While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support for non-PIC binaries. If so, that will force the TSD issue anyway. >> >> How old is your source base? >> >> TLS support for ARM and MIPS has been committed about month ago. >> Revisions r232577-r232582 and r233106,r233107 fixes for ARM. > > I'm currently running sources from March 24, but I don't have ARM or MIPS hardware. Can we remove the NO_TLS definitions in src/lib/libc/stdlib/malloc.c? I can't test the result, of course… [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 21:16:07 -0000 On 02/04/2012 1:31 PM, Jason Evans wrote: > On Apr 2, 2012, at 11:29 AM, Oleksandr Tymoshenko wrote: >> On 02/04/2012 11:04 AM, Jason Evans wrote: >>> I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM and MIPS. Is this something that's likely to be addressed soon? If not, I'm going to have to modify libthr to deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =( >>> >>> While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support for non-PIC binaries. If so, that will force the TSD issue anyway. >> >> How old is your source base? >> >> TLS support for ARM and MIPS has been committed about month ago. >> Revisions r232577-r232582 and r233106,r233107 fixes for ARM. > > I'm currently running sources from March 24, but I don't have ARM or MIPS hardware. Can we remove the NO_TLS definitions in src/lib/libc/stdlib/malloc.c? I can't test the result, of course… How do I test it? Will running buildword on MIPS device with these changes be sufficient? Or do we have specific tests for it? From owner-freebsd-arch@FreeBSD.ORG Mon Apr 2 21:23:14 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 B493E1065672 for ; Mon, 2 Apr 2012 21:23:14 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 909898FC17 for ; Mon, 2 Apr 2012 21:23:14 +0000 (UTC) Received: from [192.168.168.4] (70-91-206-178-BusName-SFBA.hfc.comcastbusiness.net [70.91.206.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id E0EC628417; Mon, 2 Apr 2012 14:23:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Jason Evans In-Reply-To: <4F7A170E.8020209@bluezbox.com> Date: Mon, 2 Apr 2012 14:23:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1257) Cc: freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 21:23:14 -0000 On Apr 2, 2012, at 2:15 PM, Oleksandr Tymoshenko wrote: > On 02/04/2012 1:31 PM, Jason Evans wrote: >>=20 >> Can we remove the NO_TLS definitions in src/lib/libc/stdlib/malloc.c? = I can't test the result, of course=85 >=20 > How do I test it? Will running buildword on MIPS device with > these changes be sufficient? Or do we have specific tests for it? I typically two two rounds of buildworld/installworld/reboot to make = sure that the newly installed toolchain still works. This paranoia is = mainly to catch problems with static binaries, which won't change in = this case, so one round is probably enough. Jason= From owner-freebsd-arch@FreeBSD.ORG Wed Apr 4 00:41: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 65252106564A for ; Wed, 4 Apr 2012 00:41:46 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 20BE88FC17 for ; Wed, 4 Apr 2012 00:41:46 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1SFEHx-0009fy-9l; Tue, 03 Apr 2012 17:41:31 -0700 Message-ID: <4F7B98C0.6090209@bluezbox.com> Date: Tue, 03 Apr 2012 17:41:36 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jason Evans References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 02/04/2012 2:23 PM, Jason Evans wrote: > On Apr 2, 2012, at 2:15 PM, Oleksandr Tymoshenko wrote: >> On 02/04/2012 1:31 PM, Jason Evans wrote: >>> >>> Can we remove the NO_TLS definitions in src/lib/libc/stdlib/malloc.c? I can't test the result, of course… >> >> How do I test it? Will running buildword on MIPS device with >> these changes be sufficient? Or do we have specific tests for it? > > I typically two two rounds of buildworld/installworld/reboot to make sure that the newly installed toolchain still works. This paranoia is mainly to catch problems with static binaries, which won't change in this case, so one round is probably enough. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 00:41:46 -0000 On 02/04/2012 2:23 PM, Jason Evans wrote: > On Apr 2, 2012, at 2:15 PM, Oleksandr Tymoshenko wrote: >> On 02/04/2012 1:31 PM, Jason Evans wrote: >>> >>> Can we remove the NO_TLS definitions in src/lib/libc/stdlib/malloc.c? I can't test the result, of course… >> >> How do I test it? Will running buildword on MIPS device with >> these changes be sufficient? Or do we have specific tests for it? > > I typically two two rounds of buildworld/installworld/reboot to make sure that the newly installed toolchain still works. This paranoia is mainly to catch problems with static binaries, which won't change in this case, so one round is probably enough. I tested it for MIPS - works fine. Unfortunately I don't have ARM hardware that works with HEAD so can't test ARM part of the change. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 4 16:00:14 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 DC53E106567D for ; Wed, 4 Apr 2012 16:00:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 55A358FC14 for ; Wed, 4 Apr 2012 16:00:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F27FBB9BF for ; Wed, 4 Apr 2012 12:00:12 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 4 Apr 2012 12:00:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201105021537.19507.jhb@freebsd.org> In-Reply-To: <201105021537.19507.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204041200.10773.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Apr 2012 12:00:13 -0400 (EDT) Subject: Re: [PATCH] Add ktrace records for user page faults X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:00:14 -0000 On Monday, May 02, 2011 3:37:19 pm John Baldwin wrote: > One thing I have found useful is knowing when processes are in the kernel > instead of in userland. ktrace already provides records for syscall > entry/exit. The other major source of time spent in the kernel that I've seen > is page fault handling. To that end, I have a patch that adds ktrace records > to the beginning and end of VM faults. This gives a pair of records so a user > can see how long a fault took (similar to how one can see how long a syscall > takes now). Sample output from kdump is below: > > 47565 echo CALL mmap(0x800a87000,0x179000,PROT_READ| > PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0) > 47565 echo RET mmap 34370777088/0x800a87000 > 47565 echo PFLT 0x800723000 VM_PROT_EXECUTE > 47565 echo RET KERN_SUCCESS > 47565 echo CALL munmap(0x800887000,0x179000) > 47565 echo RET munmap 0 > 47565 echo PFLT 0x800a00000 VM_PROT_WRITE > 47565 echo RET KERN_SUCCESS > > The patch is available at www.freebsd.org/~jhb/patches/ktrace_fault.patch and > included below. I've updated this based on some previous feedback. It now uses 'PRET' instead of 'RET' for return from a page fault. I've also made it possible for the MD layers to pass a non-truncated address, though those changes are not part of this patch. The updated patch is available at the URL above. I'd like to merge it in if there are no objections. If folks have other suggestions than 'PFLT' and 'PRET' for the markers for page faults that is fine with me. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 4 19:36:16 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8052106564A; Wed, 4 Apr 2012 19:36:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A185D8FC12; Wed, 4 Apr 2012 19:36:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 172F8B943; Wed, 4 Apr 2012 15:36:16 -0400 (EDT) From: John Baldwin To: phk@freebsd.org Date: Wed, 4 Apr 2012 14:33:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201204041433.05652.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Apr 2012 15:36:16 -0400 (EDT) Cc: arch@freebsd.org Subject: EVENTHANDLER()'s X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:36:16 -0000 So many years ago (2004), you removed support for "fast" EVENTHANDLER() objects. I was looking at this today and I kind of think we should actually undo that, but perhaps instead what we should do is make all EVENTHANDLER()'s "fast". No one creates eventhandlers with dynamic names (nor have they ever AFAIK), they all have static names. However, each time someone calls EVENTHANDLER_INVOKE() we do an O(n) loop with strcmp's to lookup the list by it's name via a string. It seems to me that we would do just fine with having all the eventhandler lists be global variables like the old "fast" variants and the string "tag" passed to all the EVENTHANDLER macros would just be used to set the variable name (exactly like the old "fast" variants). This would remove all the O(n) lookups, and we could further optimize _INVOKE() to not do any locking if the list is empty to avoid overhead in the case where there are no active hooks. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 4 21:03:16 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D97A21065670; Wed, 4 Apr 2012 21:03:16 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9349D8FC12; Wed, 4 Apr 2012 21:03:16 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 1EF265DBB; Wed, 4 Apr 2012 21:03:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q34L3EIv063104; Wed, 4 Apr 2012 21:03:14 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 04 Apr 2012 14:33:05 -0400." <201204041433.05652.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 04 Apr 2012 21:03:14 +0000 Message-ID: <63103.1333573394@critter.freebsd.dk> Cc: arch@freebsd.org Subject: Re: EVENTHANDLER()'s X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:03:16 -0000 In message <201204041433.05652.jhb@freebsd.org>, John Baldwin writes: You are probably right. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Apr 5 05:00:59 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2752C106564A for ; Thu, 5 Apr 2012 05:00:59 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 02B0E8FC15 for ; Thu, 5 Apr 2012 05:00:58 +0000 (UTC) Received: from [192.168.168.4] (70-91-206-178-BusName-SFBA.hfc.comcastbusiness.net [70.91.206.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 492CA28419; Wed, 4 Apr 2012 22:00:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Jason Evans In-Reply-To: <4F7B98C0.6090209@bluezbox.com> Date: Wed, 4 Apr 2012 22:00:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1257) Cc: freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 05:00:59 -0000 On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: > I tested it for MIPS - works fine. Unfortunately I don't have > ARM hardware that works with HEAD so can't test ARM part of the = change. Thanks for testing MIPS. I'm going to just assume that TLS works = everywhere. If it doesn't, we'll find out soon enough. =3D) Jason= From owner-freebsd-arch@FreeBSD.ORG Thu Apr 5 20:58:24 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2EE8106566C for ; Thu, 5 Apr 2012 20:58:24 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2368FC08 for ; Thu, 5 Apr 2012 20:58:24 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id 74A5039B; Thu, 5 Apr 2012 22:58:23 +0200 (CEST) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id EB18916FC; Thu, 5 Apr 2012 22:58:22 +0200 (CEST) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id AA2B31C281; Thu, 5 Apr 2012 22:58:22 +0200 (CEST) Date: Thu, 5 Apr 2012 22:58:22 +0200 From: Kristof Provost To: Jason Evans Message-ID: <20120405205822.GR9275@thebe.jupiter.sigsegv.be> References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Oleksandr Tymoshenko , freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:58:24 -0000 On 2012-04-04 22:00:57 (-0700), Jason Evans wrote: > On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: > > I tested it for MIPS - works fine. Unfortunately I don't have > > ARM hardware that works with HEAD so can't test ARM part of the change. > > Thanks for testing MIPS. I'm going to just assume that TLS works everywhere. > If it doesn't, we'll find out soon enough. =) > It appears to be rather broken on ARM, at least in combination with shared libraries. I'm trying to run on an OpenRD board (Kirkwood ARM core) and I see alignment faults whenever TLS is used. Considering that malloc appears to use it that'd be pretty much everywhere. A minimal test case is to have a shared library expose a __thread variable and then to write to it from outside the library. The assembly looks like this: int main(int argc, char **argv) { 8774: e52de004 push {lr} ; (str lr, [sp, #-4]!) kp_int = 4; 8778: e59f3014 ldr r3, [pc, #20] ; 8794 877c: e79f3003 ldr r3, [pc, r3] 8780: ebffff4c bl 84b8 <_init+0x58> 8784: e3a02004 mov r2, #4 ; 0x4 8788: e7802003 str r2, [r0, r3] return 0; } The faulting instruction is 0x8788. At that point r0 is 0x20036000, r3 is 0xffff1fff. Let me know if you need to know anything else. In the mean time I'll keep trying to figure out how it's supposed to be working in the first place :) Regards. Kristof From owner-freebsd-arch@FreeBSD.ORG Fri Apr 6 00:17:17 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 2FE981065670 for ; Fri, 6 Apr 2012 00:17:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 062EC8FC1F for ; Fri, 6 Apr 2012 00:17:16 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so2161503pbc.13 for ; Thu, 05 Apr 2012 17:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Pgf7WWANPJ+7a2JZv09axEAv+ZR4weqVxFZ4/Zir+ug=; b=Il1r2Gv3HJubyoQSq9HDuPzBjc5sYFeoM+QgxvY56JCaKoe5T/HGFhzLxKcfnVN3AU Uw2Wx3q9aBI9xxld1odS2ZoEbPGmEYf8dOe4XYYsoDNFKBLxqMVoem1O8gG3sAR/JGGz 4ID1kKE37CWn/OltBUFMlEbtjiAecMStH1+mEOlWOGZO4FtKqn2qeodaqAxvyDQnytq5 1JTIDUwnfc71wwNi8MXsQzUlcf7mMXGij/VWM4ajjqIISCW8mFLTUuyWfR18NvLzEA4L opFmEO4n+Ba91TPo00I+za6A1JWXzE0rRzEjOXIsn7dE567drF2vl7FtwYbLxxXr3ot4 1YYg== MIME-Version: 1.0 Received: by 10.68.202.167 with SMTP id kj7mr11119631pbc.9.1333671436681; Thu, 05 Apr 2012 17:17:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.77.5 with HTTP; Thu, 5 Apr 2012 17:17:16 -0700 (PDT) Date: Thu, 5 Apr 2012 17:17:16 -0700 X-Google-Sender-Auth: 5Q3SLmv1nHQrjW_NZe9ziXOmOm0 Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [RFC] break out 'statfoo' from wlanstats/athstats into a shared library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 00:17:17 -0000 Hi, There's a statistics library which Sam used for a variety of networking tasks: * wlanstats * mwlstats * athstats * (npestats? What's npe?) I've fixed some issues in athstats' copy of libstatfoo which I can port elsewhere. But I can also see scenarios where I'd like to use this library code in future statistics utilities that I'll write. What I'd like to do is: * break out the statfoo from these and create a libstatfoo, that's built as part of the base system; * teach wlanstats, mwlstats, athstats to use the system provided copy of libstatfoo; * migrate wlanstats out from tools into the base system. Does anyone have any particular reason not to do this? Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Apr 6 07:46:12 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F48D1065672 for ; Fri, 6 Apr 2012 07:46:12 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id DAF478FC14 for ; Fri, 6 Apr 2012 07:46:11 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so256717wib.13 for ; Fri, 06 Apr 2012 00:46:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=NbfZIcDN9XaYtrt35OwLTQwLmVj0DHzCZS2WWNcseMg=; b=IvmVdkSZSqWPt0d4ZRyRtv0gXp1rC8FE2iKTBKrdJmSRQOWwsHvCPt4jjBkU4IcdMy S7/dTeVtbFNDdHHhln2R72kIpIhcalC4QiBfCpL5mGwmo2xXXyZSaKtOTFlBGi1sVqmg iGg7ySYzGEfnTA0pDJ2zOoZ+gt2BPriv+EgaqR0fAY5qst/ZcZgwUUq7eLIeVZ5AqXs+ Uic55KsXc0b3Hsap7rKJRG3WXKNJxyBpzA+lyJ3bPWv826+wmfrWFz6WiUYY8YEEge3r BScn4tdLAXb54v3W5JGUlVt75RrrihYLm+mXBj53irgyuOy/otlJIn4gLtUQ++5NTPQv x1Qw== Received: by 10.180.107.101 with SMTP id hb5mr9830548wib.7.1333698371019; Fri, 06 Apr 2012 00:46:11 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-065-061-201.pools.arcor-ip.net. [88.65.61.201]) by mx.google.com with ESMTPS id k6sm4054571wie.9.2012.04.06.00.46.09 (version=SSLv3 cipher=OTHER); Fri, 06 Apr 2012 00:46:10 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-arch@freebsd.org Date: Fri, 6 Apr 2012 09:46:30 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204060946.30180.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQmaksquXCweLSOVlp+mZY54jY+zHrq3JthYxmv2VnWo3z0L1/UWTpzSK+qidJk2sg2zDBGz Cc: Adrian Chadd Subject: Re: [RFC] break out 'statfoo' from wlanstats/athstats into a shared library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 07:46:12 -0000 On Friday 06 April 2012 02:17:16 Adrian Chadd wrote: > Hi, > > There's a statistics library which Sam used for a variety of networking tasks: > > * wlanstats > * mwlstats > * athstats > * (npestats? What's npe?) Ethernet driver, check the xscale port. > I've fixed some issues in athstats' copy of libstatfoo which I can > port elsewhere. But I can also see scenarios where I'd like to use > this library code in future statistics utilities that I'll write. > > What I'd like to do is: > > * break out the statfoo from these and create a libstatfoo, that's > built as part of the base system; > * teach wlanstats, mwlstats, athstats to use the system provided copy > of libstatfoo; > * migrate wlanstats out from tools into the base system. > > Does anyone have any particular reason not to do this? What I'd always wanted to see is wlanstats' -i being extended to recognize not just wlanN, as in wlanstats -i wlan0 (teh default) wlanstats -i wlan1 wlanstats -i ath0 wlanstats -i mwl0 -- Bernhard From owner-freebsd-arch@FreeBSD.ORG Fri Apr 6 17:38:04 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05492106566B; Fri, 6 Apr 2012 17:38:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C58BD8FC0A; Fri, 6 Apr 2012 17:38:03 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so2951448pbc.13 for ; Fri, 06 Apr 2012 10:38:03 -0700 (PDT) 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=PeJljTR3NJcjM5qoX8MtreIx4zU9gO7N0aR30t6yKZg=; b=Nu5x/14ZCPxX5J1SkOslF6cFJpyxK7ZidFz0BC1Dm5qyZbdjCE3GLZA1uOW7Cw/fXn YuBrAQUtTjrWUbIw1E9xa4uSLWW2qn4gDjMDAT4OpoW1ZnbvRfqiN3S6t9FpZZPU8Aje 0/7pkMIABpZ6DJODfikfFPCB3p+RU4CGumdUWHzZ91Sy8h0AWeZbnUmEBYc5zIwiD+52 +euQNFW3dJiF+rjYqMH96lyLU6WeKdEZ6bV78rpj5EZhfuoa5KSe8qfqdNkAswL/zQCK 2E9Hsu056sWEncJqhX8OFmnpE6udPDdND9skeW65RBASqWdO1wTdp2FrzFRajY2I52Dg qEzQ== MIME-Version: 1.0 Received: by 10.68.200.137 with SMTP id js9mr17327755pbc.110.1333733883561; Fri, 06 Apr 2012 10:38:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.134.6 with HTTP; Fri, 6 Apr 2012 10:38:03 -0700 (PDT) In-Reply-To: <201204060946.30180.bschmidt@freebsd.org> References: <201204060946.30180.bschmidt@freebsd.org> Date: Fri, 6 Apr 2012 10:38:03 -0700 X-Google-Sender-Auth: seir-TC6TTr-mLvaZXG1DOLIao0 Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] break out 'statfoo' from wlanstats/athstats into a shared library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:38:04 -0000 On 6 April 2012 00:46, Bernhard Schmidt wrote: >> * (npestats? What's npe?) > > Ethernet driver, check the xscale port. Hm, whyw asn't that ever folded into -HEAD? >> * migrate wlanstats out from tools into the base system. >> >> Does anyone have any particular reason not to do this? > > What I'd always wanted to see is wlanstats' -i being extended to > recognize not just wlanN, as in > > wlanstats -i wlan0 (teh default) > wlanstats -i wlan1 > wlanstats -i ath0 > wlanstats -i mwl0 The trouble is finding a representation of the ioctl statistics that is portable enough to use like this. ath0/mwl0 don't export the same statistics by any means; and the athstats tool uses a couple of ioctl APIs (one for HAL, one for ath) to fetch statistics. FWIW, I'm about to extend the athstats tool and HAL diagnostic API to include more detailed interrupt statistics. This will help when diagnosing mis-behaving bus hardware. Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Apr 6 19:09:45 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 98655106564A for ; Fri, 6 Apr 2012 19:09:45 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 716CD8FC0C for ; Fri, 6 Apr 2012 19:09:45 +0000 (UTC) Received: from [172.25.16.174] (unknown [173.252.71.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id DE3B628418; Fri, 6 Apr 2012 12:09:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Jason Evans In-Reply-To: <20120405205822.GR9275@thebe.jupiter.sigsegv.be> Date: Fri, 6 Apr 2012 12:09:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F19C7EF-86D8-4165-AAF1-91424A518333@canonware.com> References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> <20120405205822.GR9275@thebe.jupiter.sigsegv.be> To: Kristof Provost X-Mailer: Apple Mail (2.1257) Cc: Oleksandr Tymoshenko , freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:09:45 -0000 On Apr 5, 2012, at 1:58 PM, Kristof Provost wrote: > On 2012-04-04 22:00:57 (-0700), Jason Evans = wrote: >> On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: >>> I tested it for MIPS - works fine. Unfortunately I don't have >>> ARM hardware that works with HEAD so can't test ARM part of the = change. >>=20 >> Thanks for testing MIPS. I'm going to just assume that TLS works = everywhere. =20 >> If it doesn't, we'll find out soon enough. =3D) >>=20 > It appears to be rather broken on ARM, at least in combination with > shared libraries. >=20 > [=85] Thanks for testing, Kristof. It's good to know that there are problems = on ARM, but now I'm not sure what to do about committing the updated = malloc. I don't have the time or the hardware to make TLS reliable on = ARM. Do I commit the malloc patch and let someone who cares about ARM = fix TLS after the fact? Or do I wait an indefinite amount of time to = let solid TLS support materialize? Jason= From owner-freebsd-arch@FreeBSD.ORG Fri Apr 6 19:19: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 B1F4F106566C for ; Fri, 6 Apr 2012 19:19:00 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 61E358FC0A for ; Fri, 6 Apr 2012 19:19:00 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1SGEgE-000CIo-6l; Fri, 06 Apr 2012 12:18:42 -0700 Message-ID: <4F7F4198.2010705@bluezbox.com> Date: Fri, 06 Apr 2012 12:18:48 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> <20120405205822.GR9275@thebe.jupiter.sigsegv.be> <3F19C7EF-86D8-4165-AAF1-91424A518333@canonware.com> In-Reply-To: <3F19C7EF-86D8-4165-AAF1-91424A518333@canonware.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 06/04/2012 12:09 PM, Jason Evans wrote: > On Apr 5, 2012, at 1:58 PM, Kristof Provost wrote: >> On 2012-04-04 22:00:57 (-0700), Jason Evans wrote: >>> On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: >>>> I tested it for MIPS - works fine. Unfortunately I don't have >>>> ARM hardware that works with HEAD so can't test ARM part of the change. >>> >>> Thanks for testing MIPS. I'm going to just assume that TLS works everywhere. >>> If it doesn't, we'll find out soon enough. =) >>> >> It appears to be rather broken on ARM, at least in combination with >> shared libraries. >> >> […] > > > Thanks for testing, Kristof. It's good to know that there are problems on ARM, but now I'm not sure what to do about committing the updated malloc. I don't have the time or the hardware to make TLS reliable on ARM. Do I commit the malloc patch and let someone who cares about ARM fix TLS after the fact? Or do I wait an indefinite amount of time to let solid TLS support materialize? [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: Kristof Provost , Jason Evans Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:19:00 -0000 On 06/04/2012 12:09 PM, Jason Evans wrote: > On Apr 5, 2012, at 1:58 PM, Kristof Provost wrote: >> On 2012-04-04 22:00:57 (-0700), Jason Evans wrote: >>> On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: >>>> I tested it for MIPS - works fine. Unfortunately I don't have >>>> ARM hardware that works with HEAD so can't test ARM part of the change. >>> >>> Thanks for testing MIPS. I'm going to just assume that TLS works everywhere. >>> If it doesn't, we'll find out soon enough. =) >>> >> It appears to be rather broken on ARM, at least in combination with >> shared libraries. >> >> […] > > > Thanks for testing, Kristof. It's good to know that there are problems on ARM, but now I'm not sure what to do about committing the updated malloc. I don't have the time or the hardware to make TLS reliable on ARM. Do I commit the malloc patch and let someone who cares about ARM fix TLS after the fact? Or do I wait an indefinite amount of time to let solid TLS support materialize? I'm working on this issue. I hope it will be resolved in a matter of days. From owner-freebsd-arch@FreeBSD.ORG Fri Apr 6 19:22:04 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E847106566B for ; Fri, 6 Apr 2012 19:22:04 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id EA7B08FC08 for ; Fri, 6 Apr 2012 19:22:03 +0000 (UTC) Received: from [172.25.16.174] (unknown [173.252.71.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 8CBD028418; Fri, 6 Apr 2012 12:22:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Jason Evans In-Reply-To: <4F7F4198.2010705@bluezbox.com> Date: Fri, 6 Apr 2012 12:22:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> <20120405205822.GR9275@thebe.jupiter.sigsegv.be> <3F19C7EF-86D8-4165-AAF1-91424A518333@canonware.com> <4F7F4198.2010705@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1257) Cc: Kristof Provost , freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jasone@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:22:04 -0000 On Apr 6, 2012, at 12:18 PM, Oleksandr Tymoshenko wrote: > On 06/04/2012 12:09 PM, Jason Evans wrote: >> On Apr 5, 2012, at 1:58 PM, Kristof Provost wrote: >>> It appears to be rather broken on ARM, at least in combination with >>> shared libraries. >>>=20 >>> [=85] >>=20 >> Thanks for testing, Kristof. It's good to know that there are = problems on ARM, but now I'm not sure what to do about committing the = updated malloc. I don't have the time or the hardware to make TLS = reliable on ARM. Do I commit the malloc patch and let someone who cares = about ARM fix TLS after the fact? Or do I wait an indefinite amount of = time to let solid TLS support materialize? >=20 > I'm working on this issue. I hope it will be resolved in a matter of > days. Awesome, that's great news. Thank you. Jason= From owner-freebsd-arch@FreeBSD.ORG Sat Apr 7 02:19:40 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 6A9221065677 for ; Sat, 7 Apr 2012 02:19:40 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mailfilter13.ihug.co.nz (mailfilter13.ihug.co.nz [203.109.136.13]) by mx1.freebsd.org (Postfix) with ESMTP id C55BA8FC18 for ; Sat, 7 Apr 2012 02:19:39 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=kj9zAlcOel0A:10 a=f/SxzVRvWQdBqo0nlH1VRA==:17 a=WDKH2AOMAAAA:8 a=6I5d2MoRAAAA:8 a=0V1t0i4cAAAA:8 a=06sM00nGKx_BiCzJ4xcA:9 a=CjuIK1q_8ugA:10 a=rwOtc7Fk5h8A:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAJAOCif0/Ldqol/2dsb2JhbABEFrcdgXGBCIIJAQEEATocIwULCAMYLjkeBhOICQQMujOQUASVawGBEY8lgnw X-IronPort-AV: E=Sophos;i="4.75,384,1330858800"; d="scan'208";a="215005007" Received: from 203-118-170-37.adsl.ihug.co.nz (HELO localhost) ([203.118.170.37]) by cust.filter3.content.vf.net.nz with SMTP; 07 Apr 2012 14:18:30 +1200 Date: Sat, 7 Apr 2012 14:18:21 +1200 From: Andrew Turner To: Kristof Provost Message-ID: <20120407141821.4ece0331@fubar.geek.nz> In-Reply-To: <20120405205822.GR9275@thebe.jupiter.sigsegv.be> References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> <20120405205822.GR9275@thebe.jupiter.sigsegv.be> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.0) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, Jason Evans , Oleksandr Tymoshenko Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 02:19:40 -0000 On Thu, 5 Apr 2012 22:58:22 +0200 Kristof Provost wrote: > On 2012-04-04 22:00:57 (-0700), Jason Evans > wrote: > > On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: > > > I tested it for MIPS - works fine. Unfortunately I don't have > > > ARM hardware that works with HEAD so can't test ARM part of the > > > change. > > > > Thanks for testing MIPS. I'm going to just assume that TLS works > > everywhere. If it doesn't, we'll find out soon enough. =) > > > It appears to be rather broken on ARM, at least in combination with > shared libraries. > > I'm trying to run on an OpenRD board (Kirkwood ARM core) and I see > alignment faults whenever TLS is used. Considering that malloc appears > to use it that'd be pretty much everywhere. > > A minimal test case is to have a shared library expose a __thread > variable and then to write to it from outside the library. > > The assembly looks like this: > int main(int argc, char **argv) > { > 8774: e52de004 push {lr} ; (str lr, > [sp, #-4]!) > kp_int = 4; > 8778: e59f3014 ldr r3, [pc, #20] ; 8794 > > 877c: e79f3003 ldr r3, [pc, r3] > 8780: ebffff4c bl 84b8 <_init+0x58> This is a call to __aeabi_read_tp. It is specified in the ARM EABI documentation to be special and preserve r1-r3 unlike other functions. The current implementation of __aeabi_read_tp trashes r3 as this is normally safe. In this case however it uses it when loading the ARM tp address. This then causes the fault you are seeing. > 8784: e3a02004 mov r2, #4 ; 0x4 > 8788: e7802003 str r2, [r0, r3] > > return 0; > } > > The faulting instruction is 0x8788. At that point r0 is 0x20036000, r3 > is 0xffff1fff. > > Let me know if you need to know anything else. > In the mean time I'll keep trying to figure out how it's supposed to > be working in the first place :) Can you try the patch at [1]. It should fix the issue you are seeing. It appears to create a correct version of __aeabi_read_tp but I'm waiting on buildworld/installworld to finish. Andrew [1] http://people.freebsd.org/~andrew/arm_tls_2.diff -- Andrew Turner WhiteQueue Consulting http://whitequeue.com/ Custom FreeBSD and Linux development From owner-freebsd-arch@FreeBSD.ORG Sat Apr 7 07:47:59 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 82763106566B for ; Sat, 7 Apr 2012 07:47:59 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1F98FC0A for ; Sat, 7 Apr 2012 07:47:59 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id E7148356; Sat, 7 Apr 2012 09:47:57 +0200 (CEST) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 5270214B9; Sat, 7 Apr 2012 09:47:27 +0200 (CEST) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id 79B821CDBA; Sat, 7 Apr 2012 09:47:26 +0200 (CEST) Date: Sat, 7 Apr 2012 09:47:26 +0200 From: Kristof Provost To: Andrew Turner Message-ID: <20120407074725.GW9275@thebe.jupiter.sigsegv.be> References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> <20120405205822.GR9275@thebe.jupiter.sigsegv.be> <20120407141821.4ece0331@fubar.geek.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120407141821.4ece0331@fubar.geek.nz> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Oleksandr Tymoshenko , Jason Evans , freebsd-arch@freebsd.org Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 07:47:59 -0000 On 2012-04-07 14:18:21 (+1200), Andrew Turner wrote: > Can you try the patch at [1]. It should fix the issue you are seeing. > It appears to create a correct version of __aeabi_read_tp but I'm > waiting on buildworld/installworld to finish. > Yes, that works! I now get full user space, and no more alignment faults. Thanks, Kristof From owner-freebsd-arch@FreeBSD.ORG Sat Apr 7 09:37:23 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 4EAA4106566C for ; Sat, 7 Apr 2012 09:37:23 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C783B8FC12 for ; Sat, 7 Apr 2012 09:37:22 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2769423wgb.31 for ; Sat, 07 Apr 2012 02:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=x/+Dmj1cdBUBWwUjX/crRZADfKhkCI01ejwfawVlXg4=; b=nSmfZHCyt5xJvm/X9Blb5FoNBACSyhemauoyCL6ulIsYqglxnyE/AUQuFDaiY6/RoT 0DKlk2Ia1FJWbsoUnCBphI2vEZIccl4vsmj7aYEScMNzuwNKiU4c6MvDRJJAx9S6DOLa dCIhGHnOH4PQSR8nF2HTG5vQ/KRJgiZcfOo2UGEqNraHPgybU00U/h+K1X+mxFsMKoxt naXCQ4AJ/ZodN66d0XYtl7BnVlRW7OSRjNxoVMMc1QOwJX2qOO0+dTUuBma76HnZJ+Fc Mc3PrhrXKUQB2AG5rDB+ABIgwwNYtsEZgxaCRN7EYnp7nXfs+rqNjljAexY824yo1vKN cUaA== Received: by 10.180.103.35 with SMTP id ft3mr2160412wib.0.1333791441453; Sat, 07 Apr 2012 02:37:21 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-067-219-111.pools.arcor-ip.net. [88.67.219.111]) by mx.google.com with ESMTPS id 17sm14469523wis.0.2012.04.07.02.37.19 (version=SSLv3 cipher=OTHER); Sat, 07 Apr 2012 02:37:20 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Sat, 7 Apr 2012 11:37:40 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201204060946.30180.bschmidt@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204071137.40785.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQmf/bRXoLsr/mLDrhFkDhE4Ho1QX0AlSrn0pEmjz1EnRMdhHdDZnGUX6UZK1YGgbVZZ9HaL Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] break out 'statfoo' from wlanstats/athstats into a shared library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 09:37:23 -0000 On Friday 06 April 2012 19:38:03 Adrian Chadd wrote: > On 6 April 2012 00:46, Bernhard Schmidt wrote: > > >> * (npestats? What's npe?) > > > > Ethernet driver, check the xscale port. > > Hm, whyw asn't that ever folded into -HEAD? head/sys/arm/xscale/ixp425/if_npe.c > >> * migrate wlanstats out from tools into the base system. > >> > >> Does anyone have any particular reason not to do this? > > > > What I'd always wanted to see is wlanstats' -i being extended to > > recognize not just wlanN, as in > > > > wlanstats -i wlan0 (teh default) > > wlanstats -i wlan1 > > wlanstats -i ath0 > > wlanstats -i mwl0 > > The trouble is finding a representation of the ioctl statistics that > is portable enough to use like this. > > ath0/mwl0 don't export the same statistics by any means; and the > athstats tool uses a couple of ioctl APIs (one for HAL, one for ath) > to fetch statistics. Oh no, I didn't mean to display the same stats, just that the tools are merged and not scattered around the tree. > FWIW, I'm about to extend the athstats tool and HAL diagnostic API to > include more detailed interrupt statistics. This will help when > diagnosing mis-behaving bus hardware. > > > Adrian > -- Bernhard From owner-freebsd-arch@FreeBSD.ORG Sat Apr 7 20:33:08 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DAB9106566C; Sat, 7 Apr 2012 20:33:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EDBE08FC0C; Sat, 7 Apr 2012 20:33:07 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so3812117pbc.13 for ; Sat, 07 Apr 2012 13:33:07 -0700 (PDT) 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=1Jh3JJxNmWbQ+MpEaCkv2hin92vpYO7ktc4UdAJySjM=; b=Fmn41AZEZB503Hq0u+IqSUFAglp3RdLn2cuNGRdlANUFIAJdiGjQiYeLmUn0aYkslb p6z9O2lN6DAsZiTmlUNmlZl4LoYOf6RvL37bjmRo8v4nqzEyJWuqqgaKZIl+bjFXcj6i IaMdsuPpkjEWJ78zVnwWE69xsNTmKkKnKAxn9RQ69DkDbaAbndt2iCc19O4LrO87GB/G woyMcF1scesEp7H+Wq1cfsYg1bxbxgNtgncteFcWcjySPGF80MkGF5J3AGjOTOd208gz 5sJwfLwwRGSSFLJyaU2xfKLPDeSCOOJT+Q+GUmiv7FAYYXS+729jukyp6j5yRErn3oXB w9QA== MIME-Version: 1.0 Received: by 10.68.211.69 with SMTP id na5mr2559685pbc.17.1333830787783; Sat, 07 Apr 2012 13:33:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.134.6 with HTTP; Sat, 7 Apr 2012 13:33:07 -0700 (PDT) In-Reply-To: <201204071137.40785.bschmidt@freebsd.org> References: <201204060946.30180.bschmidt@freebsd.org> <201204071137.40785.bschmidt@freebsd.org> Date: Sat, 7 Apr 2012 13:33:07 -0700 X-Google-Sender-Auth: tQnIRQhc75AD64zyLGfqsmV5EqM Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] break out 'statfoo' from wlanstats/athstats into a shared library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 20:33:08 -0000 On 7 April 2012 02:37, Bernhard Schmidt wrote: [snip] > Oh no, I didn't mean to display the same stats, just that the tools > are merged and not scattered around the tree. Well, that sounds great for the general case, but for the atheros-embedded-wifi case (and the marvell-embedded-wifi case too), having the extra code is just bloat. Having them as separate tools means we can select which to include into whichever binary builds we do. Adrian