From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:15:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 359FE106566B; Sun, 22 Jul 2012 00:15:27 +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 BD6B78FC12; Sun, 22 Jul 2012 00:15:27 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so9163306pbb.13 for ; Sat, 21 Jul 2012 17:15:27 -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=MldctNpOLr9E2+8Va14QZi1+qGvsBpKuCAVwSKxzR/8=; b=g1EtFrX07mKQadgnkUS1hoYi0n3gWms4O0JYDqoPo+dG/jLAGIxoQhiNOmiblxWKBl rSDvapziLTpRkXuPXfrg/TaVuDENVXd83MVbHvJMPR6W+7Pk1gHd+EWlnQwI0ikaXmt9 k50zUonyuoKZyNTNv/nqzJhQi97Z0wY8/iv1IUn1e/Qa5UJOiat/nEO17Tmpi9WDc38W 3cl02xun8Kk9AJKKzUK2/yUiG8Z/Kwk3T9DNqYN8vrRG4CJaYWjgonNm//LjSPDjQ7F/ J2o2YMUG13/YLatsf3eNV/LW3A6/dGJqRz9nlkMpK0jrwxyabLkx4RbkuloRZV05gcLP EJJw== MIME-Version: 1.0 Received: by 10.68.201.9 with SMTP id jw9mr24589750pbc.28.1342916127418; Sat, 21 Jul 2012 17:15:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.191.138 with HTTP; Sat, 21 Jul 2012 17:15:27 -0700 (PDT) In-Reply-To: <500A0E24.80101@freebsd.org> References: <500A0E24.80101@freebsd.org> Date: Sat, 21 Jul 2012 17:15:27 -0700 X-Google-Sender-Auth: ivCYBCABYx3bCxN_R4Fcp7Gcp8A Message-ID: From: Adrian Chadd To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 00:15:28 -0000 On 20 July 2012 19:04, Julian Elischer wrote: > Is anyone looking at PCIe hotplug support? > > I'm especially interested if anyone has a strategy for device re-insertion > and reassociating > the reinserted device with its old device_t so that it gets the same unit > number.. > (assumes access to a serial number or similar) > Even if it is put back into a different slot. I'd really like PCIe hotplug support to appear, so we can also do expresscard hotplug support. It'd make my wifi hacking go a lot quicker. :) Adrian From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:23:25 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CACA106566B; Sun, 22 Jul 2012 00:23:25 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 057348FC19; Sun, 22 Jul 2012 00:23:25 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 240401E0010C; Sun, 22 Jul 2012 02:23:24 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q6M0Cnp3015125; Sun, 22 Jul 2012 02:12:49 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q6M0CnKp015124; Sun, 22 Jul 2012 02:12:49 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 22 Jul 2012 02:12:49 +0200 To: Rick Message-ID: <20120722001249.GA14907@triton8.kn-bremen.de> References: <20120721185813.GA4457@triton8.kn-bremen.de> <500B13AA.5080505@sloservers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500B13AA.5080505@sloservers.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Juergen Lock Subject: Re: Fix for grub 2.00/bzr kfreebsd to boot 9.1 kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 00:23:25 -0000 On Sat, Jul 21, 2012 at 01:40:10PM -0700, Rick wrote: > Hi Juergen, Hi! > > My email address has changed so don't be alarmed if your CC bounces. :) Ah yeah I just saw the bounce. :) > An update of grub2 is long overdue, so I'll work on that right now. > Cool, thanx! Juergen From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:37:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78AC01065670; Sun, 22 Jul 2012 00:37:22 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7608FC0C; Sun, 22 Jul 2012 00:37:22 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3345953qcs.13 for ; Sat, 21 Jul 2012 17:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=toD30UPiB670h3ODXVr5q/tkTjtNky9p8MRAxj7ymDY=; b=eNXxOn9gLxC9Il+GegPkgC8XLhK+8FJzfliBg/uRQUhqXg+L6+Y408awT2vM0OAKdr LLebzhVNujZ2iFntf2CDrVxrEA8julVwGZSz6427cJZF5dfQTix4HN3/kJj9q5tPvABU qXVrSZ1dX9AO9NtorkjUqQS2WQMgfVveF8GipmzV4L8J04avsZ8utvVf+SHTDPd/g4/9 movMuzGp1WQ12ag6Rp2PVMIu+SrytXl4dcjU1yr6zalziEUxRVFIEeO37uHdcT6Ky06I kW3TfTCOJW0d7xxJgO/STHC4Dz59mz9kkNqRDXHllt0X3O7cec2HP3r/2wCnog+F+PEm U1Rw== MIME-Version: 1.0 Received: by 10.224.59.13 with SMTP id j13mr17403404qah.44.1342917441432; Sat, 21 Jul 2012 17:37:21 -0700 (PDT) Received: by 10.229.39.12 with HTTP; Sat, 21 Jul 2012 17:37:21 -0700 (PDT) In-Reply-To: <20120721211628.GE2676@deviant.kiev.zoral.com.ua> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> Date: Sat, 21 Jul 2012 20:37:21 -0400 Message-ID: From: Kim Culhan To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 00:37:22 -0000 On Sat, Jul 21, 2012 at 5:16 PM, Konstantin Belousov wrote: > On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote: >> On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric wrote: >> > On 2012-07-20 16:49, Kim Culhan wrote: >> >> Seeing this for r:238655 >> > ... >> >> In file included from /usr/src/sys/modules/dtrace/dtrace/../../../sys/pcpu.h:44: >> >> ./machine/pcpu.h:226:13: error: indirection of non-volatile null >> >> pointer will be deleted, not trap >> >> [-Werror,-Wnull-dereference] >> >> : "m" (*(char *)OFFSETOF_CURTHREAD)); >> >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> ./machine/pcpu.h:226:13: note: consider using __builtin_trap() or >> >> qualifying pointer with 'volatile' >> > >> > That's indeed a valid warning from clang, since OFFSETOF_CURTHREAD is >> > usually zero. It's probably due to recent work on dtrace. I'm not in >> > the neighborhood of a FreeBSD box right now to verify, but can you >> > please try to change the cast to "(volatile char *)"? That should fix >> > the warning. >> >> Yes it did, I know there are many considerations wrt to this warning. > > This should be equivalent to what you tried. Can you test build and > boot resulting kernel with this patch ? > > diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h > index 5d1fd4d..7b3c934 100644 > --- a/sys/amd64/include/pcpu.h > +++ b/sys/amd64/include/pcpu.h > @@ -217,16 +217,22 @@ extern struct pcpu *pcpup; > #define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) > > #define OFFSETOF_CURTHREAD 0 > +#ifdef __clang__ > +#define VOLATILE volatile > +#else > +#define VOLATILE > +#endif > static __inline __pure2 struct thread * > __curthread(void) > { > struct thread *td; > > __asm("movq %%gs:%1,%0" : "=r" (td) > - : "m" (*(char *)OFFSETOF_CURTHREAD)); > + : "m" (*(VOLATILE char *)OFFSETOF_CURTHREAD)); > return (td); > } > #define curthread (__curthread()) > +#undef VOLATILE > > #define OFFSETOF_CURPCB 32 > static __inline __pure2 struct pcb * The resulting kernel appears to run the same as the kernel tried earlier. Hope this helps. thanks -kim From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 05:43:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E9C9106564A for ; Sun, 22 Jul 2012 05:43:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD808FC0A for ; Sun, 22 Jul 2012 05:43:55 +0000 (UTC) Received: by obbun3 with SMTP id un3so9671373obb.13 for ; Sat, 21 Jul 2012 22:43:54 -0700 (PDT) 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=MimgvChrHegjzlaDrtTfijFw3OD495FOrALTPpG3QQc=; b=E74j18XbDjhsILg89U1dq7XTQpKCwVvvMjELzIbM3MiWjAckqaTbrVy+L9qSEIS+PP ZWkzxAW2lNMeXonccDrHZMiN22hm79iOBa+QvkB/OGq6HHHOC2P9cgX+L1504o0XBeBn 3mfOncezYdzFo8ICkqWijLFPsDgUCzsyg9Bk3yj9WPRudAHBJiI6crw2mC4O0YLULJTR bfrQWlffTqovF+WYbuijw9DJ1uqurAYqoDt5OWPAMGL1oepmLKyLIci+GQvdXyqv0hYo 8FZEumwc8nYaJ69+uZg7z41/A5vbbumKhYJtKP/KbvTyrSQX3+iRSQ9Eef4LB81LTa2B CyIw== Received: by 10.42.50.17 with SMTP id y17mr2082406icf.44.1342935834441; Sat, 21 Jul 2012 22:43:54 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nh8sm4939295igc.1.2012.07.21.22.43.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Jul 2012 22:43:53 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <500A0E24.80101@freebsd.org> Date: Sat, 21 Jul 2012 23:43:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4E1BED2F-5503-428A-8935-CCB508DE284A@bsdimp.com> References: <500A0E24.80101@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnGY9SCFAkxxDEOcgSEdgHlgRjcGCWzlrAd6yigSPfbvpiHQpeQF87hidK0gx+OVry+TcQ+ Cc: FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 05:43:55 -0000 On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: > Is anyone looking at PCIe hotplug support? I have :). I did CardBus ages ago, but never have had the time, = hardware and motivation all at the same time to make progress. > I'm especially interested if anyone has a strategy for device = re-insertion and reassociating > the reinserted device with its old device_t so that it gets the same = unit number.. > (assumes access to a serial number or similar) > Even if it is put back into a different slot. That's never been supported by removable technology on FreeBSD... Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 12:44:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FF19106566C; Sun, 22 Jul 2012 12:44:17 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id C71FA8FC18; Sun, 22 Jul 2012 12:44:16 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A2F2AE6270; Sun, 22 Jul 2012 13:45:52 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=P8BjKE3Fwbth xEf0Xgp8KUUfMy0=; b=llRYc+m3PGDjMncGEG/R15V2G9ZeA3K+3PN9KPuxpG0R YttY/PI+7LLKeB1WLkRK3b4A8Bn2Z3Vj0XYOhTJlSXCYSHpVBXB6KhDcLtN2JluV aX226Akhg6xhStwUEfzBMwfi1EYCsLqTWWQlWldW23ey26LfGHGm9Ij23FyjynM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=xOHWB8 ffN0gPZTPi7LHP+V24ZW3e+95e/7PKhCl2siwfJb+fpqXWRdxq6ghHVj65WPFe6t ug//AFGWfNIKV6yejL1SGtKZsan8+nz2kqZolWMMWSFzxY5BJLw0D228IHhCnrBa 14x/swHq+ffPcJv6tzaEnDzJr3fT9/zgIK14M= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 62F1AE626F; Sun, 22 Jul 2012 13:45:52 +0100 (BST) Message-ID: <500BF598.4020207@cran.org.uk> Date: Sun, 22 Jul 2012 13:44:08 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Julian Elischer References: <500A0E24.80101@freebsd.org> In-Reply-To: <500A0E24.80101@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 12:44:17 -0000 On 21/07/2012 03:04, Julian Elischer wrote: > Is anyone looking at PCIe hotplug support? There's a (mostly empty) wiki page at http://wiki.freebsd.org/PCIHotplug . -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 16:15:31 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B021C106566C; Sun, 22 Jul 2012 16:15:31 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE6D8FC16; Sun, 22 Jul 2012 16:15:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id C3073D2CC; Sun, 22 Jul 2012 11:08:37 -0500 (CDT) Date: Sun, 22 Jul 2012 11:08:37 -0500 (CDT) From: Bryan Venteicher To: Dieter BSD Message-ID: <738102528.760.1342973317543.JavaMail.root@sage.daemoninthecloset.org> In-Reply-To: <20120722061933.298410@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.6] X-Mailer: Zimbra 7.1.4_GA_2555 (ZimbraWebClient - GC18 (Linux)/7.1.4_GA_2555) Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 16:15:31 -0000 ----- Original Message ----- > From: "Dieter BSD" > To: hackers@freebsd.org, current@freebsd.org > Sent: Sunday, July 22, 2012 1:19:32 AM > Subject: Re: Awful FreeBSD 9 block IO performance in KVM > > >>> da0: 3.300MB/s transfers > >>> da0: Command Queueing enabled > > > > root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 > > count=262144 > > > > 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) > > 1) Does a larger block size (bs=1m) help? > > 2) That's roughly the speed I'd expect without queueing. Is it really > making effective use of queueing, or is something limiting queueing to > one transfer at a time? The likely fix here is basically do vtblk_startio() in a separate kproc that vtblk_strategy() enqueues bio's to. This has been on my todo for a while, but haven't had the time. Also, the use of bioq_disksort() probably doesn't gain much for virtualized disks, but I never found much of a difference in my testing. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 17:18:21 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBB58106566B; Sun, 22 Jul 2012 17:18:21 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 92F048FC0A; Sun, 22 Jul 2012 17:18:21 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q6MHIIQN019850 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 22 Jul 2012 17:18:20 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120721211628.GE2676@deviant.kiev.zoral.com.ua> Date: Sun, 22 Jul 2012 18:18:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: Dimitry Andric , freebsd-current@FreeBSD.org, Kim Culhan Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 17:18:21 -0000 On 21 Jul 2012, at 22:16, Konstantin Belousov wrote: > On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote: >> On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric = wrote: >>> On 2012-07-20 16:49, Kim Culhan wrote: >>>> Seeing this for r:238655 >>> ... >>>> In file included from = /usr/src/sys/modules/dtrace/dtrace/../../../sys/pcpu.h:44: >>>> ./machine/pcpu.h:226:13: error: indirection of non-volatile null >>>> pointer will be deleted, not trap >>>> [-Werror,-Wnull-dereference] >>>> : "m" (*(char *)OFFSETOF_CURTHREAD)); >>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> ./machine/pcpu.h:226:13: note: consider using __builtin_trap() or >>>> qualifying pointer with 'volatile' >>>=20 >>> That's indeed a valid warning from clang, since OFFSETOF_CURTHREAD = is >>> usually zero. It's probably due to recent work on dtrace. I'm not = in >>> the neighborhood of a FreeBSD box right now to verify, but can you >>> please try to change the cast to "(volatile char *)"? That should = fix >>> the warning. >>=20 >> Yes it did, I know there are many considerations wrt to this warning. >=20 > This should be equivalent to what you tried. Can you test build and > boot resulting kernel with this patch ? >=20 > diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h > index 5d1fd4d..7b3c934 100644 > --- a/sys/amd64/include/pcpu.h > +++ b/sys/amd64/include/pcpu.h > @@ -217,16 +217,22 @@ extern struct pcpu *pcpup; > #define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) >=20 > #define OFFSETOF_CURTHREAD 0 > +#ifdef __clang__ > +#define VOLATILE volatile > +#else > +#define VOLATILE > +#endif > static __inline __pure2 struct thread * > __curthread(void) > { > struct thread *td; >=20 > __asm("movq %%gs:%1,%0" : "=3Dr" (td) > - : "m" (*(char *)OFFSETOF_CURTHREAD)); > + : "m" (*(VOLATILE char *)OFFSETOF_CURTHREAD)); > return (td); > } > #define curthread (__curthread()) > +#undef VOLATILE >=20 > #define OFFSETOF_CURPCB 32 > static __inline __pure2 struct pcb * The following will generate better code, not eliminate future = optimisation opportunities, and work correctly on both 32-bit and 64-bit = x86. =20 #define GS_RELATIVE __attribute__((address_space(256))) static __inline __pure2 struct thread * __curthread(void) { return (*(struct thread *volatile = GS_RELATIVE*)OFFSETOF_CURTHREAD); } The volatile that clang recommends is very important, because the = compiler (in this version) is not aware of changes to GS and so must = assume that it can change between calls. In this specific case it is = fine, and that's why it's a warning and not an error. Both clang and = gcc accept the volatile and both have the same behaviour. Adding the = volatile just for clang will pessimise the code to silence a warning. = This is not the correct thing to do. I have tested this with clang and gcc. With gcc, a trivial function = that calls __curthread() twice results in two gs-relativel movs either = without __pure2 or with __pure2 and volatile. With clang, both forms = produce a single one, but the inline asm one is passing inline asm = through the LLVM IR and so will be losing some other optimisation = opportunities. The presence of __pure2 does make a difference for clang = (gcc ignores it), but removing the volatile has the same effect). The = following version preserves the exact intention of the function for the = entire optimisation pipeline: #if __clang__ #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wnull-dereference" inline struct thread * __curthread2(void) { return (*(struct thread *GS_RELATIVE*)OFFSETOF_CURTHREAD); } #pragma clang diagnostic pop #endif The point of warnings is to tell you when you are doing something that = is usually wrong. The correct response is to disable them when you have = audited the code and determined that this is one of the exceptional = cases. David= From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 18:01:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CF3E106566C; Sun, 22 Jul 2012 18:01:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8BD338FC08; Sun, 22 Jul 2012 18:01:24 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6MI1WQA019355; Sun, 22 Jul 2012 21:01:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6MI1K3o062611; Sun, 22 Jul 2012 21:01:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6MI1J5T062610; Sun, 22 Jul 2012 21:01:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Jul 2012 21:01:19 +0300 From: Konstantin Belousov To: David Chisnall Message-ID: <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L7qmchFKydRS4b0B" Content-Disposition: inline In-Reply-To: <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Dimitry Andric , freebsd-current@freebsd.org, Kim Culhan Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 18:01:25 -0000 --L7qmchFKydRS4b0B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Why don't you bother to configure your mail client properly ? Answering to email with 500+ long lines is not trivial] On Sun, Jul 22, 2012 at 06:18:12PM +0100, David Chisnall wrote: >=20 > On 21 Jul 2012, at 22:16, Konstantin Belousov wrote: >=20 > > On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote: > >> On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric wro= te: > >>> On 2012-07-20 16:49, Kim Culhan wrote: > >>>> Seeing this for r:238655 > >>> ... > >>>> In file included from /usr/src/sys/modules/dtrace/dtrace/../../../sy= s/pcpu.h:44: > >>>> ./machine/pcpu.h:226:13: error: indirection of non-volatile null > >>>> pointer will be deleted, not trap > >>>> [-Werror,-Wnull-dereference] > >>>> : "m" (*(char *)OFFSETOF_CURTHREAD)); > >>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>>> ./machine/pcpu.h:226:13: note: consider using __builtin_trap() or > >>>> qualifying pointer with 'volatile' > >>>=20 > >>> That's indeed a valid warning from clang, since OFFSETOF_CURTHREAD is > >>> usually zero. It's probably due to recent work on dtrace. I'm not in > >>> the neighborhood of a FreeBSD box right now to verify, but can you > >>> please try to change the cast to "(volatile char *)"? That should fix > >>> the warning. > >>=20 > >> Yes it did, I know there are many considerations wrt to this warning. > >=20 > > This should be equivalent to what you tried. Can you test build and > > boot resulting kernel with this patch ? > >=20 > > diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h > > index 5d1fd4d..7b3c934 100644 > > --- a/sys/amd64/include/pcpu.h > > +++ b/sys/amd64/include/pcpu.h > > @@ -217,16 +217,22 @@ extern struct pcpu *pcpup; > > #define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) > >=20 > > #define OFFSETOF_CURTHREAD 0 > > +#ifdef __clang__ > > +#define VOLATILE volatile > > +#else > > +#define VOLATILE > > +#endif > > static __inline __pure2 struct thread * > > __curthread(void) > > { > > struct thread *td; > >=20 > > __asm("movq %%gs:%1,%0" : "=3Dr" (td) > > - : "m" (*(char *)OFFSETOF_CURTHREAD)); > > + : "m" (*(VOLATILE char *)OFFSETOF_CURTHREAD)); > > return (td); > > } > > #define curthread (__curthread()) > > +#undef VOLATILE > >=20 > > #define OFFSETOF_CURPCB 32 > > static __inline __pure2 struct pcb * >=20 > The following will generate better code, not eliminate future optimisatio= n opportunities, and work correctly on both 32-bit and 64-bit x86. =20 >=20 > #define GS_RELATIVE __attribute__((address_space(256))) > static __inline __pure2 struct thread * > __curthread(void) > { >=20 > return (*(struct thread *volatile GS_RELATIVE*)OFFSETOF_CURTHREAD); > } >=20 > The volatile that clang recommends is very important, because the compile= r (in this version) is not aware of changes to GS and so must assume that i= t can change between calls. In this specific case it is fine, and that's w= hy it's a warning and not an error. Both clang and gcc accept the volatile= and both have the same behaviour. Adding the volatile just for clang will= pessimise the code to silence a warning. This is not the correct thing to= do. I cannot understand what you are trying to say there. I indeed consider adding a volatile to shut down a pointless warning a waste. And on the other hand clang insist on issuing a warning which breaks the build. The function is _guaranteed_ to return the same value any time it is called in context of the current thread. In particular, 'gs changing' is completely irrelevant. First, segment index loaded into %gs itself does not change, even between threads. Second, we guarantee that the basing performed over the %gs is constant for current thread. Why should we say to clang that %gs base can change there, when it is not, is beyond me. Side note, i386 uses %fs and not %gs for pcpu basing. >=20 > I have tested this with clang and gcc. With gcc, a trivial function that= calls __curthread() twice results in two gs-relativel movs either without = __pure2 or with __pure2 and volatile. With clang, both forms produce a sin= gle one, but the inline asm one is passing inline asm through the LLVM IR a= nd so will be losing some other optimisation opportunities. The presence o= f __pure2 does make a difference for clang (gcc ignores it), but removing t= he volatile has the same effect). The following version preserves the exac= t intention of the function for the entire optimisation pipeline: >=20 > #if __clang__ > #pragma clang diagnostic push > #pragma clang diagnostic ignored "-Wnull-dereference" > inline struct thread * I wonder if there shall be static keyword as well. > __curthread2(void) > { >=20 > return (*(struct thread *GS_RELATIVE*)OFFSETOF_CURTHREAD); > } > #pragma clang diagnostic pop > #endif >=20 > The point of warnings is to tell you when you are doing something that is= usually wrong. The correct response is to disable them when you have audi= ted the code and determined that this is one of the exceptional cases. So it still cannot work without disabling the warning ? Not much different from what I noted initially. I am fine with whatever you end up under #ifdef clang, please commit a patch. --L7qmchFKydRS4b0B Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAMP+8ACgkQC3+MBN1Mb4gQMQCfV/9Vdfusv1bqUkxJ0AUGUe22 4MEAoOnO9qAbrH/8IQqSOvI5PQqB8oM1 =hmVv -----END PGP SIGNATURE----- --L7qmchFKydRS4b0B-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 02:46:34 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68048106564A; Mon, 23 Jul 2012 02:46:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2F48FC0A; Mon, 23 Jul 2012 02:46:33 +0000 (UTC) Received: from theimac.samsco.home (theimac.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q6N2MTRo080670; Sun, 22 Jul 2012 20:22:30 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <500A0E24.80101@freebsd.org> Date: Sun, 22 Jul 2012 20:22:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500A0E24.80101@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1278) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 02:46:34 -0000 On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: > Is anyone looking at PCIe hotplug support? >=20 > I'm especially interested if anyone has a strategy for device = re-insertion and reassociating > the reinserted device with its old device_t so that it gets the same = unit number.. > (assumes access to a serial number or similar) > Even if it is put back into a different slot. >=20 Would the PCI system be responsible for figuring out this serial number? = I don't think that it can, but it's a question to answer, I guess. If = it can't then it's up to the driver to generate a unique cookie that = would be stored by the PCI subsystem. This cookie would have to be = based off of data that can be retrieved from the PCI config space and/or = VPD space, since anything more would require resource allocation, which = is only allowed in the DEV_ATTACH phase, and once you've hit that phase = you've already pretty much sealed the deal on unit number assignment. So what would probably happen is that the PCI layer provides a ring = buffer of cookie storage and a set of accessors for the drivers. The = cookies would map to a key-value pair with the device unit name and = number. During probe, a driver can look at PCI config space and = generate a cookie. That cookie can then be communicated up to the PCI = layer for storage. Maybe the driver calls a match routine that returns = a unit number on match and a store on failure, then the driver calls a = set_unit_number accessor. Only the driver that wins the bid would win = the unit number reassignment or cookie storage. Or maybe the driver = passes the cookie up as part of its return code, and the match and unit = assignment happens automatically. Drivers that don't want to = participate in this simply wouldn't, and everything would continue to = operate the same way. The two sticky parts are rogue/buggy drivers that = abuse the api and cause a flood of cookies to be generated, and = questions on when a unit number is eligible for reuse. For the first = one, a ring buffer of cookies would solve the immediate problem, but you = might still have some risk of drivers selectively wrapping the buffer = for whatever accidental or evil purpose. For the second problem, maybe = a unit number stays persistent only if the PCIe hot remove mechanism = requests it, and then only until the ring-buffer wraps. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 03:12:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 865C2106564A; Mon, 23 Jul 2012 03:12:43 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17C538FC0C; Mon, 23 Jul 2012 03:12:42 +0000 (UTC) Received: by vbmv11 with SMTP id v11so5323895vbm.13 for ; Sun, 22 Jul 2012 20:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=pWffL+RJVN7NgqekEwEQ42XWM2G5MwsoGhlW8N21ph8=; b=GnVDepBsbsQNhHCnIjk1FU7VeEpZXhzAeAR8oqooFFtsG9+jlg+h12d3FL913HTRbI OvwZbBnNm5EvQ18UJvGWdIO1X9flHMbyq48yOB0GzYyozue5sXRmSRywBT/Amg9skvaJ 9iK+U6Ck+itniTknoml9hMGmCYDg0PSij/FqNIY/G/sage6zKBWUGeiLsQJr4c3Ibhnr paZI42nIKfyT4SEcik/xrD1KfyLrwJK/wZowRJeoYUACSMvgr+DUjMEMUvYbaZYvDKs3 bCW9q/EoJHA3W01c1EcvN36jw24C86BpAFNISxOipTj3MjHOcMoI0jLtnQxgJ6PkboWU z9Jw== Received: by 10.220.224.66 with SMTP id in2mr7827428vcb.51.1343013162301; Sun, 22 Jul 2012 20:12:42 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id bn5sm9308777vdb.19.2012.07.22.20.12.40 (version=SSLv3 cipher=OTHER); Sun, 22 Jul 2012 20:12:41 -0700 (PDT) Date: Sun, 22 Jul 2012 23:12:34 -0400 From: Alexander Kabaev To: Scott Long Message-ID: <20120722231234.6f748d05@kan.dyndns.org> In-Reply-To: References: <500A0E24.80101@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/2IdXL7eBHf6p+xCXoD/Wg8_"; protocol="application/pgp-signature" Cc: Julian Elischer , FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 03:12:43 -0000 --Sig_/2IdXL7eBHf6p+xCXoD/Wg8_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 22 Jul 2012 20:22:33 -0600 Scott Long wrote: >=20 > On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: >=20 > > Is anyone looking at PCIe hotplug support? > >=20 > > I'm especially interested if anyone has a strategy for device > > re-insertion and reassociating the reinserted device with its old > > device_t so that it gets the same unit number.. (assumes access to > > a serial number or similar) Even if it is put back into a different > > slot. > >=20 >=20 > Would the PCI system be responsible for figuring out this serial > number? I don't think that it can, but it's a question to answer, I > guess. If it can't then it's up to the driver to generate a unique > cookie that would be stored by the PCI subsystem. This cookie would > have to be based off of data that can be retrieved from the PCI > config space and/or VPD space, since anything more would require > resource allocation, which is only allowed in the DEV_ATTACH phase, > and once you've hit that phase you've already pretty much sealed the > deal on unit number assignment. >=20 > So what would probably happen is that the PCI layer provides a ring > buffer of cookie storage and a set of accessors for the drivers. The > cookies would map to a key-value pair with the device unit name and > number. During probe, a driver can look at PCI config space and > generate a cookie. That cookie can then be communicated up to the > PCI layer for storage. Maybe the driver calls a match routine that > returns a unit number on match and a store on failure, then the > driver calls a set_unit_number accessor. Only the driver that wins > the bid would win the unit number reassignment or cookie storage. Or > maybe the driver passes the cookie up as part of its return code, and > the match and unit assignment happens automatically. Drivers that > don't want to participate in this simply wouldn't, and everything > would continue to operate the same way. The two sticky parts are > rogue/buggy drivers that abuse the api and cause a flood of cookies > to be generated, and questions on when a unit number is eligible for > reuse. For the first one, a ring buffer of cookies would solve the > immediate problem, but you might still have some risk of drivers > selectively wrapping the buffer for whatever accidental or evil > purpose. For the second problem, maybe a unit number stays > persistent only if the PCIe hot remove mechanism requests it, and > then only until the ring-buffer wraps. >=20 > Scott >=20 I do not think the whole problem as depicted by Julian is even worth solving. Why keeping any data for the device that might _never_ come back? What if the device hierarchy just starts from the PCI-e and extends upwards and user still holds on to some vestiges of a previous device chain (say, by keeping a character control device sharing the same unit number open, common practice)? Reusing unit number is much trickier then, and might not be even possible. So, before one jumps into 'how', can we agree on 'why' first? When device goes away, it is not just this device's device_t that is disappearing, it is a whole tree rooted at that device. I see no point in trying to reconstruct that. PCI-e hotplug proper is very much orthogonal to the question of unit numbering and IS worth supporting. --=20 Alexander Kabaev --Sig_/2IdXL7eBHf6p+xCXoD/Wg8_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQDMEnQ6z1jMm+XZYRAqtHAKDF9LaUIdoXrPjDy+tbnY8BuXYhtQCgoNMt RIP0DUgeag0wKtOVtMPsB/8= =2hh9 -----END PGP SIGNATURE----- --Sig_/2IdXL7eBHf6p+xCXoD/Wg8_-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 04:11:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB831065673 for ; Mon, 23 Jul 2012 04:11:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9C48FC0C for ; Mon, 23 Jul 2012 04:11:36 +0000 (UTC) Received: by yenl8 with SMTP id l8so5933631yen.13 for ; Sun, 22 Jul 2012 21:11:35 -0700 (PDT) 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=yojWHAbzwaVOcLaPDBhXt2s2VstMkHqTXw7W/U0/v4o=; b=OpOapKBwhQZFoaRDcirbPx5+f+p2tIHNFDL83/pLKUwdaYL9fvtJR3m4zIikrNLChl er+oCfb5wMlWjxJlz4YEWZ89dEW7N3IvMaSOqFxrQmd344loNwxVW70UrwuZldq8q6tP Jv0b6xHHESvhLLsV2Uu21VFGrD+CIzXU9PgwStqmitVThCykaXy+JALtKLdFNpASjm0P wKWV+RUJzICywzj7QDsXKkfC7DrvjdDLf7xGh8q2li9uaRUsbQK8yq0O1D8tzQ5+C4Lb 7xZj5UJHdkWVcsCfi3yLKUbyq3QyfSWYl6yG8/xbx2DPTkr9ljROkbgScWUvSVd/P3fy vAZQ== Received: by 10.66.74.97 with SMTP id s1mr27816457pav.11.1343016695275; Sun, 22 Jul 2012 21:11:35 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nj4sm9109344pbc.5.2012.07.22.21.11.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jul 2012 21:11:34 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120722231234.6f748d05@kan.dyndns.org> Date: Sun, 22 Jul 2012 22:11:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500A0E24.80101@freebsd.org> <20120722231234.6f748d05@kan.dyndns.org> To: Alexander Kabaev X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQk4joN2GOQsBx/iICvt+RyxIyl0PjU7uUa2pFOtp6PQCC2LrU6AcQ6A+wcw/A8DsmuyCtaR Cc: Julian Elischer , FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 04:11:36 -0000 On Jul 22, 2012, at 9:12 PM, Alexander Kabaev wrote: > On Sun, 22 Jul 2012 20:22:33 -0600 > Scott Long wrote: >=20 >>=20 >> On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: >>=20 >>> Is anyone looking at PCIe hotplug support? >>>=20 >>> I'm especially interested if anyone has a strategy for device >>> re-insertion and reassociating the reinserted device with its old >>> device_t so that it gets the same unit number.. (assumes access to >>> a serial number or similar) Even if it is put back into a different >>> slot. >>>=20 >>=20 >> Would the PCI system be responsible for figuring out this serial >> number? I don't think that it can, but it's a question to answer, I >> guess. If it can't then it's up to the driver to generate a unique >> cookie that would be stored by the PCI subsystem. This cookie would >> have to be based off of data that can be retrieved from the PCI >> config space and/or VPD space, since anything more would require >> resource allocation, which is only allowed in the DEV_ATTACH phase, >> and once you've hit that phase you've already pretty much sealed the >> deal on unit number assignment. >>=20 >> So what would probably happen is that the PCI layer provides a ring >> buffer of cookie storage and a set of accessors for the drivers. The >> cookies would map to a key-value pair with the device unit name and >> number. During probe, a driver can look at PCI config space and >> generate a cookie. That cookie can then be communicated up to the >> PCI layer for storage. Maybe the driver calls a match routine that >> returns a unit number on match and a store on failure, then the >> driver calls a set_unit_number accessor. Only the driver that wins >> the bid would win the unit number reassignment or cookie storage. Or >> maybe the driver passes the cookie up as part of its return code, and >> the match and unit assignment happens automatically. Drivers that >> don't want to participate in this simply wouldn't, and everything >> would continue to operate the same way. The two sticky parts are >> rogue/buggy drivers that abuse the api and cause a flood of cookies >> to be generated, and questions on when a unit number is eligible for >> reuse. For the first one, a ring buffer of cookies would solve the >> immediate problem, but you might still have some risk of drivers >> selectively wrapping the buffer for whatever accidental or evil >> purpose. For the second problem, maybe a unit number stays >> persistent only if the PCIe hot remove mechanism requests it, and >> then only until the ring-buffer wraps. >>=20 >> Scott >>=20 >=20 > I do not think the whole problem as depicted by Julian is even worth > solving. Why keeping any data for the device that might _never_ come > back? What if the device hierarchy just starts from the PCI-e and > extends upwards and user still holds on to some vestiges of a previous > device chain (say, by keeping a character control device sharing the > same unit number open, common practice)? Reusing unit number is much > trickier then, and might not be even possible. So, before one jumps > into 'how', can we agree on 'why' first? When device goes away, it is > not just this device's device_t that is disappearing, it is a whole > tree rooted at that device. I see no point in trying to reconstruct > that. There's a reason that PC Card and CardBus never supported this at all. = The assumption was that reconnecting devices is so cheap that it isn't = worth the bother. This is true for all but some specialized devices = today: network information is easy to reconstruct, storage drives are = easy to reconfigure (since we already fail all in-flight transactions = when the device goes away), etc. I can see some advantage to having = storage cope, but there already geom classes that can help people code = when drives can go away. > PCI-e hotplug proper is very much orthogonal to the question of unit > numbering and IS worth supporting. Yes. totally agreed. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 07:45:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83CC5106566B for ; Mon, 23 Jul 2012 07:45:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 41E3F8FC0C for ; Mon, 23 Jul 2012 07:45:30 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q6N7jJxY030781 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 00:45:21 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <500D010A.5080808@freebsd.org> Date: Mon, 23 Jul 2012 00:45:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Warner Losh References: <500A0E24.80101@freebsd.org> <20120722231234.6f748d05@kan.dyndns.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 07:45:30 -0000 On 7/22/12 9:11 PM, Warner Losh wrote: > On Jul 22, 2012, at 9:12 PM, Alexander Kabaev wrote: > >> On Sun, 22 Jul 2012 20:22:33 -0600 >> Scott Long wrote: >> >>> On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: >>> >>>> Is anyone looking at PCIe hotplug support? >>>> >>>> I'm especially interested if anyone has a strategy for device >>>> re-insertion and reassociating the reinserted device with its old >>>> device_t so that it gets the same unit number.. (assumes access to >>>> a serial number or similar) Even if it is put back into a different >>>> slot. >>>> >>> Would the PCI system be responsible for figuring out this serial >>> number? I don't think that it can, but it's a question to answer, I >>> guess. If it can't then it's up to the driver to generate a unique >>> cookie that would be stored by the PCI subsystem. This cookie would >>> have to be based off of data that can be retrieved from the PCI >>> config space and/or VPD space, since anything more would require >>> resource allocation, which is only allowed in the DEV_ATTACH phase, >>> and once you've hit that phase you've already pretty much sealed the >>> deal on unit number assignment. >>> >>> So what would probably happen is that the PCI layer provides a ring >>> buffer of cookie storage and a set of accessors for the drivers. The >>> cookies would map to a key-value pair with the device unit name and >>> number. During probe, a driver can look at PCI config space and >>> generate a cookie. That cookie can then be communicated up to the >>> PCI layer for storage. Maybe the driver calls a match routine that >>> returns a unit number on match and a store on failure, then the >>> driver calls a set_unit_number accessor. Only the driver that wins >>> the bid would win the unit number reassignment or cookie storage. Or >>> maybe the driver passes the cookie up as part of its return code, and >>> the match and unit assignment happens automatically. Drivers that >>> don't want to participate in this simply wouldn't, and everything >>> would continue to operate the same way. The two sticky parts are >>> rogue/buggy drivers that abuse the api and cause a flood of cookies >>> to be generated, and questions on when a unit number is eligible for >>> reuse. For the first one, a ring buffer of cookies would solve the >>> immediate problem, but you might still have some risk of drivers >>> selectively wrapping the buffer for whatever accidental or evil >>> purpose. For the second problem, maybe a unit number stays >>> persistent only if the PCIe hot remove mechanism requests it, and >>> then only until the ring-buffer wraps. >>> >>> Scott >>> >> I do not think the whole problem as depicted by Julian is even worth >> solving. Why keeping any data for the device that might _never_ come >> back? What if the device hierarchy just starts from the PCI-e and >> extends upwards and user still holds on to some vestiges of a previous >> device chain (say, by keeping a character control device sharing the >> same unit number open, common practice)? Reusing unit number is much >> trickier then, and might not be even possible. So, before one jumps >> into 'how', can we agree on 'why' first? When device goes away, it is >> not just this device's device_t that is disappearing, it is a whole >> tree rooted at that device. I see no point in trying to reconstruct >> that. > There's a reason that PC Card and CardBus never supported this at all. The assumption was that reconnecting devices is so cheap that it isn't worth the bother. This is true for all but some specialized devices today: network information is easy to reconstruct, storage drives are easy to reconfigure (since we already fail all in-flight transactions when the device goes away), etc. I can see some advantage to having storage cope, but there already geom classes that can help people code when drives can go away. > >> PCI-e hotplug proper is very much orthogonal to the question of unit >> numbering and IS worth supporting. > Yes. totally agreed. I'm not saying that it's vitally important but was wondering if people had a strategy for it.. i.e. is it a question worth worrying about? In a separate forum Warner and I (yeah I know I'm answering Warner, but I'm addressing the others) discussed the feasibility of surviving an "oops pulled the wrong card" event with regards to a particular flash memory card. I was just carrying that forwards as a thought experiment (There is actually a strategy that sounds feasible). The problem of getting a serial number out of the BAR space during probe is also possibly solvable in our case but the question of how long to remember a device is legitimate an My answer would be that 1/ a particular driver would be able to specify whether it could handle this, and 2/ it might be limited to some pragmatic number such as 16 or 32, or a time limit. > > Warner > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 08:43:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0D051065688; Mon, 23 Jul 2012 08:43:02 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id AB65D8FC08; Mon, 23 Jul 2012 08:43:02 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1StEEC-0005Zf-5q>; Mon, 23 Jul 2012 10:42:56 +0200 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1StEEC-0007J4-3A>; Mon, 23 Jul 2012 10:42:56 +0200 Message-ID: <500D0EA5.4050900@zedat.fu-berlin.de> Date: Mon, 23 Jul 2012 10:43:17 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current , freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.110 Cc: Subject: portmaster and pkgng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:43:03 -0000 Hello. I'd like to try pkgng with portmaster. I see that "pkg2ng" is involving the directory /var/db/pkg, so this implies that there may implications also for usage with ports-mgmt/portmaster. portmaster is supposed to be the tool completely dependend on system's toolsets, isn't it? I know that "pkg" is supposed to be more for binary maintainance of the system, but I'd like to be "stuck" with compiling my ports. Is there an issue with that? Thanks inadvance and sorry for the (naive) noise. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 09:07:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81E181065672; Mon, 23 Jul 2012 09:07:02 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4BA98FC16; Mon, 23 Jul 2012 09:07:01 +0000 (UTC) Received: by bkcje9 with SMTP id je9so4946653bkc.13 for ; Mon, 23 Jul 2012 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wZSmjTKyxJZHcvF4JWRd5OQBZqJnF/EyYqEnnUcZVyU=; b=HcL0lRm9FgmvqhwoXKIwk0g/fIRScLw2PFejzyXaK9FmR9pmpsVHTgSgblGaka/RsT kTGUg+yGoF6fKPNKnBhkxYCZxn07sEOuFdqIpjrPlZw3vRH2ShFcvRw9pJ+wWlQjYSPj v8AN4eZKkeUiHm4u81ozh9UcDXqHHaVaDcznjjNX/LKqISGubvR3sPA6CyBa8yHzHvQ5 CVc75JYoUGcyo4mOdHOdILk2LAdJDFYFSx67OrOjUSo6DABXYTDoBl/PfSp/tfOdU/Kd nySZ6+IBIaZShMRfkjUa1B0HbQhaJ4Z3ZS1gVbFv2x7/XUDYlBGlhT7a0aulBz9v8DiR kx6Q== MIME-Version: 1.0 Received: by 10.205.127.77 with SMTP id gz13mr7257241bkc.17.1343034420643; Mon, 23 Jul 2012 02:07:00 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Mon, 23 Jul 2012 02:07:00 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Mon, 23 Jul 2012 02:07:00 -0700 (PDT) In-Reply-To: <500D0EA5.4050900@zedat.fu-berlin.de> References: <500D0EA5.4050900@zedat.fu-berlin.de> Date: Mon, 23 Jul 2012 10:07:00 +0100 Message-ID: From: Chris Rees To: "Hartmann, O." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , FreeBSD Mailing List Subject: Re: portmaster and pkgng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:07:02 -0000 On 23 Jul 2012 09:44, "Hartmann, O." wrote: > > Hello. > > I'd like to try pkgng with portmaster. I see that "pkg2ng" is involving > the directory /var/db/pkg, so this implies that there may implications > also for usage with ports-mgmt/portmaster. portmaster is supposed to be > the tool completely dependend on system's toolsets, isn't it? > > I know that "pkg" is supposed to be more for binary maintainance of the > system, but I'd like to be "stuck" with compiling my ports. Is there an > issue with that? > > Thanks inadvance and sorry for the (naive) noise. Of course you can stay with compiling your ports directly, but I think you'll be so amazed with how easy it is to make binary package sets yourself and use them that you'll use them instead :). You still have all the advantages of compiling from source. http://blog.etoilebsd.net/post/Home_made_pkgng_repo Chris From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 09:31:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F4E106564A for ; Mon, 23 Jul 2012 09:31:07 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id A98F88FC14 for ; Mon, 23 Jul 2012 09:31:06 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1StEyn-0007hl-Tx>; Mon, 23 Jul 2012 11:31:05 +0200 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1StEyn-0002Pq-RT>; Mon, 23 Jul 2012 11:31:05 +0200 Message-ID: <500D19EE.7030607@zedat.fu-berlin.de> Date: Mon, 23 Jul 2012 11:31:26 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <500D0EA5.4050900@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: 130.133.86.110 Subject: Re: portmaster and pkgng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:31:07 -0000 On 07/23/12 11:07, Chris Rees wrote: > On 23 Jul 2012 09:44, "Hartmann, O." wrote: >> >> Hello. >> >> I'd like to try pkgng with portmaster. I see that "pkg2ng" is involving >> the directory /var/db/pkg, so this implies that there may implications >> also for usage with ports-mgmt/portmaster. portmaster is supposed to be >> the tool completely dependend on system's toolsets, isn't it? >> >> I know that "pkg" is supposed to be more for binary maintainance of the >> system, but I'd like to be "stuck" with compiling my ports. Is there an >> issue with that? >> >> Thanks inadvance and sorry for the (naive) noise. > > Of course you can stay with compiling your ports directly, but I think > you'll be so amazed with how easy it is to make binary package sets > yourself and use them that you'll use them instead :). You still have all > the advantages of compiling from source. > > http://blog.etoilebsd.net/post/Home_made_pkgng_repo > > Chris Hello Chris. I need to go step by step. I installed ports-mgmt/pkg and did a pkg2ng and watched the folder /var/db/pkg has been backuped and then changed towards the pkgng usage. portmaster now is not recognizing anymore the format of the /var/db/pkg folder - for those considered the knowledged no surprise, for me simply the indication that portmaster usage isn't usable as usual. Well, if I understand it right, pkg is considered to be for binary packages and does not make portmaster obsolete, if I'm inclined compiling my ports myself, am I right? Well, I thought I read in here that pkg has now a much more sophisticated tracking of dependencies - usage of SQLite implies, that there is now a great opportunity of doing well in tracking problems and versioning (I might be wrong). I tried to follow the chat on the list about pkgng, but for the rush I didn't figured out whether portmaster is considered obsolete - I saw patches for portupgrade flushing in, so my logic has been falsified by that implicitely ... Thanks for the link, I'll see what it about, sounds promising ... Regards, Oliver -- Oliver Hartmann Freie Universität Berlin Planetologie und Fernerkundung Malteserstr. 74 - 100/Haus D D-12249 Berlin Tel.: +49 (0) 30 838 70 508 FAX: +49 (0) 30 838 70 539 From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 09:36:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42359106566B for ; Mon, 23 Jul 2012 09:36:30 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id A8DF38FC08 for ; Mon, 23 Jul 2012 09:36:29 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q6N9aQol032928 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 23 Jul 2012 10:36:27 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <500D1B1A.3030700@unsane.co.uk> Date: Mon, 23 Jul 2012 10:36:26 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <500D0EA5.4050900@zedat.fu-berlin.de> In-Reply-To: <500D0EA5.4050900@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: portmaster and pkgng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:36:30 -0000 On 23/07/2012 09:43, Hartmann, O. wrote: > Hello. > > I'd like to try pkgng with portmaster. I see that "pkg2ng" is involving > the directory /var/db/pkg, so this implies that there may implications > also for usage with ports-mgmt/portmaster. portmaster is supposed to be > the tool completely dependend on system's toolsets, isn't it? > > I know that "pkg" is supposed to be more for binary maintainance of the > system, but I'd like to be "stuck" with compiling my ports. Is there an > issue with that? > > Thanks inadvance and sorry for the (naive) noise. I believe there is a patch for portmaster at https://github.com/pkgng/pkgng/tree/master/ports I havent tried this just yet, planning to today though. I'm busy trying out pkg too. I have a repo online using poudriere and like it very much, so far my only real issue has been that when I changed repo from mine back to pkgbeta.FreeBSD.org I had to force an update (pkg update -f) I imagine due to the timestamp being older on the repo I am trying to change to. Not much of a problem as I consider using custom repos a more advanced usage and it just force me to read the manual again :) moving back the other way worked fine, while trying to use multirepo didnt work at all (but does say its experimental and dont expect it to work.) A built in equivalent to portmasters -o option (replace the installed port with a port from a different origin) would be nice as currently all my perl modules are listed as having a missing dependency since I forced an upgrade from perl5.12 to perl5.14 but then that's not in our current pkg tools so using portmaster or similar for this is reasonable enough. Vince > > Regards, > Oliver > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 09:37:17 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70F06106566B for ; Mon, 23 Jul 2012 09:37:17 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id EEFE98FC12 for ; Mon, 23 Jul 2012 09:37:16 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q6N9bCDY019290 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 23 Jul 2012 10:37:13 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q6N9bCDY019290 Authentication-Results: smtp.infracaninophile.co.uk/q6N9bCDY019290; dkim=none (no signature); dkim-adsp=none Message-ID: <500D1B3F.6070304@FreeBSD.org> Date: Mon, 23 Jul 2012 10:37:03 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <500D0EA5.4050900@zedat.fu-berlin.de> In-Reply-To: <500D0EA5.4050900@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDDAF24E714E45319150C23D2" X-Virus-Scanned: clamav-milter 0.97.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: portmaster and pkgng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:37:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDDAF24E714E45319150C23D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 23/07/2012 09:43, Hartmann, O. wrote: > I'd like to try pkgng with portmaster. I see that "pkg2ng" is involving= > the directory /var/db/pkg, so this implies that there may implications > also for usage with ports-mgmt/portmaster. portmaster is supposed to be= > the tool completely dependend on system's toolsets, isn't it? >=20 > I know that "pkg" is supposed to be more for binary maintainance of the= > system, but I'd like to be "stuck" with compiling my ports. Is there an= > issue with that? As Chris says, making your own repository with poudriere is pretty simple= =2E However, unless you're going to be using pkgng to manage several systems, you might not want even the (fairly small) bother of setting up poudriere at all. Which is fine. So long as you follow these instructions: https://github.com/pkgng/pkgng/blob/master/FAQ.md#15 you can then use portmaster(8) pretty much as usual, but with the pkgng packaging format and package database. There remains one significant chunk of portmaster functionality still missing: the ability to install from pre-built packages rather than ports. Depending on how you use portmaster, this may or may not have any day-to-day impact on you. In theory it is possible to mix usage of binary packages from external repositories with locally compiled packages, but at the moment this suffers from exactly the same compatibility problems as doing the equivalent with pkg_tools would. Fixing that is definitely coming, but it's not going to be in release-1.0. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigDDAF24E714E45319150C23D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlANG0gACgkQ8Mjk52CukIzsaQCeM63SFQLzh+4ATHOzVKcOzpJb X+MAnjAEk7cp76YYcWqolpsjSpi1qzDF =I/h0 -----END PGP SIGNATURE----- --------------enigDDAF24E714E45319150C23D2-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 09:47:55 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 070D2106564A for ; Mon, 23 Jul 2012 09:47:55 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 84DEC8FC18 for ; Mon, 23 Jul 2012 09:47:54 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q6N9lhF5019472 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 23 Jul 2012 10:47:43 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q6N9lhF5019472 Authentication-Results: smtp.infracaninophile.co.uk/q6N9lhF5019472; dkim=none (no signature); dkim-adsp=none Message-ID: <500D1DBF.6030608@FreeBSD.org> Date: Mon, 23 Jul 2012 10:47:43 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <500D0EA5.4050900@zedat.fu-berlin.de> <500D19EE.7030607@zedat.fu-berlin.de> In-Reply-To: <500D19EE.7030607@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC5E43248A711064666F0410D" X-Virus-Scanned: clamav-milter 0.97.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: portmaster and pkgng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:47:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5E43248A711064666F0410D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 23/07/2012 10:31, Hartmann, O. wrote: > portmaster now is not recognizing anymore the format of the /var/db/pkg= > folder - for those considered the knowledged no surprise, for me simply= > the indication that portmaster usage isn't usable as usual. You need to patch portmaster separately from installing pkgng. Once that is done, it doesn't complain about missing stuff in /var/db/pkg Note: use the latest version of the patch from git in preference to what is included in pkgng distfiles: the patch gets updated following portmaster's release schedule, not pkgng's. Here: https://github.com/pkgng/pkgng/raw/master/ports/patch-portmaster-pkgn= g > Well, if I understand it right, pkg is considered to be for binary > packages and does not make portmaster obsolete, if I'm inclined > compiling my ports myself, am I right? Correct. > Well, I thought I read in here that pkg has now a much more > sophisticated tracking of dependencies - usage of SQLite implies, that > there is now a great opportunity of doing well in tracking problems and= > versioning (I might be wrong). Again, correct. pkgng replaces grepping through a lot of files under /var/db/pkg with doing some fairly simple SQL queries, and is in general a much faster at that sort of thing. > I tried to follow the chat on the list about pkgng, but for the rush I > didn't figured out whether portmaster is considered obsolete - I saw > patches for portupgrade flushing in, so my logic has been falsified by > that implicitely ... portmaster is definitely not obsolete. pkgng doesn't /do/ ports at all, only packages. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigC5E43248A711064666F0410D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlANHb8ACgkQ8Mjk52CukIwd9QCfUVnK7ltcLqh8bVCwbKK7e6JI GdgAmwaJWreVD4TPeT4OZCPddX5dnNt6 =v5bv -----END PGP SIGNATURE----- --------------enigC5E43248A711064666F0410D-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 14:24:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C15D1065674 for ; Mon, 23 Jul 2012 14:24:22 +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 F02D58FC17 for ; Mon, 23 Jul 2012 14:24:21 +0000 (UTC) Received: by ggnm2 with SMTP id m2so6444940ggn.13 for ; Mon, 23 Jul 2012 07:24:21 -0700 (PDT) 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=jW10FhANvmNa9LoC5sB3gadZv/gMHHss6SiJANJv9Fs=; b=F4RUOP+096O7JuPIxVlT3/TfeWqVyx5WP/XP0KlTBcYg9KJT+OlMXHa9xzTjrMUVv6 eY4hkvkFoDq2NY3os6a2BOJK2lC7LO1hn2pcELR2Jzl7BqSgBmRewPvX3nkoReeGMCGj 6cgq/zDvftAw0Zjt4eA8VppO3RERnD56tGOOslTJr5PoRL03t3qDy0KEATLk5Zd/4/oE n4cUZFQNGLtb/s3Y1eR6LLXT2L6kRhTyJxeSgqlCWIHunSJgL3UZ7Jwmun5daunZvzr9 ghGQy4KkY6fkPW5mffMqYQz39kAkjHJSqRZLYFHaTiX+kuMJNg8IXPsru6HG9V705y59 7TwA== Received: by 10.42.189.73 with SMTP id dd9mr8512714icb.49.1343053461098; Mon, 23 Jul 2012 07:24:21 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ay5sm6098682igb.15.2012.07.23.07.24.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 07:24:19 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <500D010A.5080808@freebsd.org> Date: Mon, 23 Jul 2012 08:24:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500A0E24.80101@freebsd.org> <20120722231234.6f748d05@kan.dyndns.org> <500D010A.5080808@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQk97JhAmOd8fTBdby8KSZDvXaMRLdiC+XJvP25ICwTjeBgvlsfxE3NIg+tE+5W3UPE92y7b Cc: FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 14:24:22 -0000 On Jul 23, 2012, at 1:45 AM, Julian Elischer wrote: > On 7/22/12 9:11 PM, Warner Losh wrote: >> On Jul 22, 2012, at 9:12 PM, Alexander Kabaev wrote: >>=20 >>> On Sun, 22 Jul 2012 20:22:33 -0600 >>> Scott Long wrote: >>>=20 >>>> On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: >>>>=20 >>>>> Is anyone looking at PCIe hotplug support? >>>>>=20 >>>>> I'm especially interested if anyone has a strategy for device >>>>> re-insertion and reassociating the reinserted device with its old >>>>> device_t so that it gets the same unit number.. (assumes access to >>>>> a serial number or similar) Even if it is put back into a = different >>>>> slot. >>>>>=20 >>>> Would the PCI system be responsible for figuring out this serial >>>> number? I don't think that it can, but it's a question to answer, = I >>>> guess. If it can't then it's up to the driver to generate a unique >>>> cookie that would be stored by the PCI subsystem. This cookie = would >>>> have to be based off of data that can be retrieved from the PCI >>>> config space and/or VPD space, since anything more would require >>>> resource allocation, which is only allowed in the DEV_ATTACH phase, >>>> and once you've hit that phase you've already pretty much sealed = the >>>> deal on unit number assignment. >>>>=20 >>>> So what would probably happen is that the PCI layer provides a ring >>>> buffer of cookie storage and a set of accessors for the drivers. = The >>>> cookies would map to a key-value pair with the device unit name and >>>> number. During probe, a driver can look at PCI config space and >>>> generate a cookie. That cookie can then be communicated up to the >>>> PCI layer for storage. Maybe the driver calls a match routine that >>>> returns a unit number on match and a store on failure, then the >>>> driver calls a set_unit_number accessor. Only the driver that wins >>>> the bid would win the unit number reassignment or cookie storage. = Or >>>> maybe the driver passes the cookie up as part of its return code, = and >>>> the match and unit assignment happens automatically. Drivers that >>>> don't want to participate in this simply wouldn't, and everything >>>> would continue to operate the same way. The two sticky parts are >>>> rogue/buggy drivers that abuse the api and cause a flood of cookies >>>> to be generated, and questions on when a unit number is eligible = for >>>> reuse. For the first one, a ring buffer of cookies would solve the >>>> immediate problem, but you might still have some risk of drivers >>>> selectively wrapping the buffer for whatever accidental or evil >>>> purpose. For the second problem, maybe a unit number stays >>>> persistent only if the PCIe hot remove mechanism requests it, and >>>> then only until the ring-buffer wraps. >>>>=20 >>>> Scott >>>>=20 >>> I do not think the whole problem as depicted by Julian is even worth >>> solving. Why keeping any data for the device that might _never_ come >>> back? What if the device hierarchy just starts from the PCI-e and >>> extends upwards and user still holds on to some vestiges of a = previous >>> device chain (say, by keeping a character control device sharing the >>> same unit number open, common practice)? Reusing unit number is much >>> trickier then, and might not be even possible. So, before one jumps >>> into 'how', can we agree on 'why' first? When device goes away, it = is >>> not just this device's device_t that is disappearing, it is a whole >>> tree rooted at that device. I see no point in trying to reconstruct >>> that. >> There's a reason that PC Card and CardBus never supported this at = all. The assumption was that reconnecting devices is so cheap that it = isn't worth the bother. This is true for all but some specialized = devices today: network information is easy to reconstruct, storage = drives are easy to reconfigure (since we already fail all in-flight = transactions when the device goes away), etc. I can see some advantage = to having storage cope, but there already geom classes that can help = people code when drives can go away. >>=20 >>> PCI-e hotplug proper is very much orthogonal to the question of unit >>> numbering and IS worth supporting. >> Yes. totally agreed. >=20 > I'm not saying that it's vitally important but was wondering if people = had a strategy for it.. > i.e. is it a question worth worrying about? >=20 > In a separate forum Warner and I (yeah I know I'm answering Warner, = but I'm addressing the others) discussed the feasibility of surviving = an "oops pulled the wrong card" event with regards to a particular flash = memory card. I was just carrying that forwards as a thought experiment = (There is actually a strategy that sounds feasible). >=20 > The problem of getting a serial number out of the BAR space during = probe is also possibly solvable in our case but the question of how long = to remember a device is legitimate an My answer would be that > 1/ a particular driver would be able to specify whether it could = handle this, and > 2/ it might be limited to some pragmatic number such as 16 or 32, or a = time limit. Actually, for the case where there's expensive state to reconstruct, = you'd likely want to keep the state around for an estimated time it = would take to reconstruct it. I think that this may necessarily have to = be done outside the framework of newbus, or you'd need a new = mechanism/state that the driver could request as part of its detach = routine that says effectively 'keep this around'. Any later probe on = insert would have to be able to find this and tell newbus about it. = However, that does start to get ugly in a hurry. It would be better, imho, that if a driver wanted to keep this info = around, it would have to take responsibility for finding any such = pending state and cope appropriately. In the case of storage devices, = you'd be able to have those storage volumes on a separate bus, and then = you'd have all the control that you need. But then you start wondering = into issues with what to do with the pending transactions, what to do = with new transactions, etc before giving up. Then again, all these are nice to haves, especially since we don't have = pcie hot plug at all right now. Warner= From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 19:19:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 614161065670; Mon, 23 Jul 2012 19:19:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A70CE8FC12; Mon, 23 Jul 2012 19:19:00 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6NJJ8cX082494; Mon, 23 Jul 2012 22:19:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6NJIuSo038475; Mon, 23 Jul 2012 22:18:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6NJIu4O038474; Mon, 23 Jul 2012 22:18:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jul 2012 22:18:56 +0300 From: Konstantin Belousov To: David Chisnall Message-ID: <20120723191856.GR2676@deviant.kiev.zoral.com.ua> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxd4aqMUuikGjl19" Content-Disposition: inline In-Reply-To: <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kim Culhan , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 19:19:01 -0000 --Qxd4aqMUuikGjl19 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 22, 2012 at 09:01:19PM +0300, Konstantin Belousov wrote: > [Why don't you bother to configure your mail client properly ? > Answering to email with 500+ long lines is not trivial] >=20 > On Sun, Jul 22, 2012 at 06:18:12PM +0100, David Chisnall wrote: > >=20 > > On 21 Jul 2012, at 22:16, Konstantin Belousov wrote: > >=20 > > > On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote: > > >> On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric w= rote: > > >>> On 2012-07-20 16:49, Kim Culhan wrote: > > >>>> Seeing this for r:238655 > > >>> ... > > >>>> In file included from /usr/src/sys/modules/dtrace/dtrace/../../../= sys/pcpu.h:44: > > >>>> ./machine/pcpu.h:226:13: error: indirection of non-volatile null > > >>>> pointer will be deleted, not trap > > >>>> [-Werror,-Wnull-dereference] > > >>>> : "m" (*(char *)OFFSETOF_CURTHREAD)); > > >>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>>> ./machine/pcpu.h:226:13: note: consider using __builtin_trap() or > > >>>> qualifying pointer with 'volatile' > > >>>=20 > > >>> That's indeed a valid warning from clang, since OFFSETOF_CURTHREAD = is > > >>> usually zero. It's probably due to recent work on dtrace. I'm not= in > > >>> the neighborhood of a FreeBSD box right now to verify, but can you > > >>> please try to change the cast to "(volatile char *)"? That should = fix > > >>> the warning. > > >>=20 > > >> Yes it did, I know there are many considerations wrt to this warning. > > >=20 > > > This should be equivalent to what you tried. Can you test build and > > > boot resulting kernel with this patch ? > > >=20 > > > diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h > > > index 5d1fd4d..7b3c934 100644 > > > --- a/sys/amd64/include/pcpu.h > > > +++ b/sys/amd64/include/pcpu.h > > > @@ -217,16 +217,22 @@ extern struct pcpu *pcpup; > > > #define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) > > >=20 > > > #define OFFSETOF_CURTHREAD 0 > > > +#ifdef __clang__ > > > +#define VOLATILE volatile > > > +#else > > > +#define VOLATILE > > > +#endif > > > static __inline __pure2 struct thread * > > > __curthread(void) > > > { > > > struct thread *td; > > >=20 > > > __asm("movq %%gs:%1,%0" : "=3Dr" (td) > > > - : "m" (*(char *)OFFSETOF_CURTHREAD)); > > > + : "m" (*(VOLATILE char *)OFFSETOF_CURTHREAD)); > > > return (td); > > > } > > > #define curthread (__curthread()) > > > +#undef VOLATILE > > >=20 > > > #define OFFSETOF_CURPCB 32 > > > static __inline __pure2 struct pcb * > >=20 > > The following will generate better code, not eliminate future optimisat= ion opportunities, and work correctly on both 32-bit and 64-bit x86. =20 > >=20 > > #define GS_RELATIVE __attribute__((address_space(256))) > > static __inline __pure2 struct thread * > > __curthread(void) > > { > >=20 > > return (*(struct thread *volatile GS_RELATIVE*)OFFSETOF_CURTHREAD); > > } Did you ever looked what clang does generate for this function ? I got my bad mood immediately improved after I saw that: 0xffffffff804d0883 <+691>: mov %gs:0x0,%rax 0xffffffff804d088c <+700>: mov %gs:0x8,%rax > >=20 > > The volatile that clang recommends is very important, because the compi= ler (in this version) is not aware of changes to GS and so must assume that= it can change between calls. In this specific case it is fine, and that's= why it's a warning and not an error. Both clang and gcc accept the volati= le and both have the same behaviour. Adding the volatile just for clang wi= ll pessimise the code to silence a warning. This is not the correct thing = to do. >=20 > I cannot understand what you are trying to say there. I indeed consider > adding a volatile to shut down a pointless warning a waste. And on the > other hand clang insist on issuing a warning which breaks the build. >=20 > The function is _guaranteed_ to return the same value any time it is > called in context of the current thread. In particular, 'gs changing' is > completely irrelevant. First, segment index loaded into %gs itself does > not change, even between threads. Second, we guarantee that the basing > performed over the %gs is constant for current thread. Why should we say > to clang that %gs base can change there, when it is not, is beyond me. >=20 > Side note, i386 uses %fs and not %gs for pcpu basing. > >=20 > > I have tested this with clang and gcc. With gcc, a trivial function th= at calls __curthread() twice results in two gs-relativel movs either withou= t __pure2 or with __pure2 and volatile. With clang, both forms produce a s= ingle one, but the inline asm one is passing inline asm through the LLVM IR= and so will be losing some other optimisation opportunities. The presence= of __pure2 does make a difference for clang (gcc ignores it), but removing= the volatile has the same effect). The following version preserves the ex= act intention of the function for the entire optimisation pipeline: > >=20 > > #if __clang__ > > #pragma clang diagnostic push > > #pragma clang diagnostic ignored "-Wnull-dereference" > > inline struct thread * > I wonder if there shall be static keyword as well. >=20 > > __curthread2(void) > > { > >=20 > > return (*(struct thread *GS_RELATIVE*)OFFSETOF_CURTHREAD); > > } > > #pragma clang diagnostic pop > > #endif And there, clang generates 0xffffffff804d088c <+700>: mov %gs:0x8,%rax This is with the nice patch at the end of this reply. The code causes panic at the pmap init time. Longer description is that pc_curthread is offset 0 if %gs-based. The dereferenced pointer point to the struct thread, which contains td_proc pointer at offset 8. Instead, clang seems to dereference td_proc from offset 8 based on %gs, or something similar. pooma% clang -v FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 Target: x86_64-unknown-freebsd9.0 I am quite impressed. > >=20 > > The point of warnings is to tell you when you are doing something that = is usually wrong. The correct response is to disable them when you have au= dited the code and determined that this is one of the exceptional cases. >=20 > So it still cannot work without disabling the warning ? Not much > different from what I noted initially. I am fine with whatever you end > up under #ifdef clang, please commit a patch. diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h index 5d1fd4d..dc0d828 100644 --- a/sys/amd64/include/pcpu.h +++ b/sys/amd64/include/pcpu.h @@ -217,6 +217,34 @@ extern struct pcpu *pcpup; #define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) =20 #define OFFSETOF_CURTHREAD 0 +#define OFFSETOF_CURPCB 32 + +#ifdef __clang__ + +#define GS_BASED __attribute__((address_space(256))) + +#pragma clang diagnostic push +#pragma clang diagnostic ignored "-Wnull-dereference" + +static __inline struct thread * +__curthread(void) +{ + + return (*(struct thread *volatile GS_BASED *)OFFSETOF_CURTHREAD); +} + +static __inline struct pcb * +__curpcb(void) +{ + + return (*(struct pcb *GS_BASED *)OFFSETOF_CURPCB); +} + +#pragma clang diagnostic pop +#undef GS_RELATIVE + +#else /* __clang__ */ + static __inline __pure2 struct thread * __curthread(void) { @@ -226,9 +254,7 @@ __curthread(void) : "m" (*(char *)OFFSETOF_CURTHREAD)); return (td); } -#define curthread (__curthread()) =20 -#define OFFSETOF_CURPCB 32 static __inline __pure2 struct pcb * __curpcb(void) { @@ -237,8 +263,11 @@ __curpcb(void) __asm("movq %%gs:%1,%0" : "=3Dr" (pcb) : "m" (*(char *)OFFSETOF_CURPCB)); return (pcb); } -#define curpcb (__curpcb()) =20 +#endif /* __clang__ */ + +#define curthread (__curthread()) +#define curpcb (__curpcb()) #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) =20 #else /* !lint || defined(__GNUCLIKE_ASM) && defined(__GNUCLIKE___TYPEOF) = */ --Qxd4aqMUuikGjl19 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlANo58ACgkQC3+MBN1Mb4hr6ACgsHUzmQjA/VzkZSJwp9MPSQg6 4Z8AoNBzbtrOLSl+HIbazNudhqtA40Gz =NWSC -----END PGP SIGNATURE----- --Qxd4aqMUuikGjl19-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 19:53:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 875791065673; Mon, 23 Jul 2012 19:53:36 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6C28FC0A; Mon, 23 Jul 2012 19:53:36 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q6NJrSdM025442 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 23 Jul 2012 19:53:29 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120723191856.GR2676@deviant.kiev.zoral.com.ua> Date: Mon, 23 Jul 2012 20:53:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <088BF877-50E6-42C5-98EF-DAB0FA52C348@freebsd.org> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> <20120723191856.GR2676@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: Kim Culhan , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 19:53:36 -0000 On 23 Jul 2012, at 20:18, Konstantin Belousov wrote: > Longer description is that pc_curthread is offset 0 if %gs-based. > The dereferenced pointer point to the struct thread, which contains > td_proc pointer at offset 8. Instead, clang seems to dereference > td_proc from offset 8 based on %gs, or something similar. This appears to be a bug in the LLVM X86 back end. It is performing an = invalid fold of the two loads. I have filed this bug: http://llvm.org/bugs/show_bug.cgi?id=3D13438 David= From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 17:51:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9E151065673; Tue, 24 Jul 2012 17:51:18 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 700C88FC0A; Tue, 24 Jul 2012 17:51:18 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1StjGG-0002bg-Tr; Tue, 24 Jul 2012 13:51:08 -0400 Date: Tue, 24 Jul 2012 13:51:08 -0400 From: Gary Palmer To: Julian Elischer Message-ID: <20120724175108.GC19321@in-addr.com> References: <500A0E24.80101@freebsd.org> <20120722231234.6f748d05@kan.dyndns.org> <500D010A.5080808@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500D010A.5080808@freebsd.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: FreeBSD Current , Warner Losh Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:51:18 -0000 On Mon, Jul 23, 2012 at 12:45:14AM -0700, Julian Elischer wrote: > On 7/22/12 9:11 PM, Warner Losh wrote: > >On Jul 22, 2012, at 9:12 PM, Alexander Kabaev wrote: > > > >>On Sun, 22 Jul 2012 20:22:33 -0600 > >>Scott Long wrote: > >> > >>>On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: > >>> > >>>>Is anyone looking at PCIe hotplug support? > >>>> > >>>>I'm especially interested if anyone has a strategy for device > >>>>re-insertion and reassociating the reinserted device with its old > >>>>device_t so that it gets the same unit number.. (assumes access to > >>>>a serial number or similar) Even if it is put back into a different > >>>>slot. > >>>> > >>>Would the PCI system be responsible for figuring out this serial > >>>number? I don't think that it can, but it's a question to answer, I > >>>guess. If it can't then it's up to the driver to generate a unique > >>>cookie that would be stored by the PCI subsystem. This cookie would > >>>have to be based off of data that can be retrieved from the PCI > >>>config space and/or VPD space, since anything more would require > >>>resource allocation, which is only allowed in the DEV_ATTACH phase, > >>>and once you've hit that phase you've already pretty much sealed the > >>>deal on unit number assignment. > >>> > >>>So what would probably happen is that the PCI layer provides a ring > >>>buffer of cookie storage and a set of accessors for the drivers. The > >>>cookies would map to a key-value pair with the device unit name and > >>>number. During probe, a driver can look at PCI config space and > >>>generate a cookie. That cookie can then be communicated up to the > >>>PCI layer for storage. Maybe the driver calls a match routine that > >>>returns a unit number on match and a store on failure, then the > >>>driver calls a set_unit_number accessor. Only the driver that wins > >>>the bid would win the unit number reassignment or cookie storage. Or > >>>maybe the driver passes the cookie up as part of its return code, and > >>>the match and unit assignment happens automatically. Drivers that > >>>don't want to participate in this simply wouldn't, and everything > >>>would continue to operate the same way. The two sticky parts are > >>>rogue/buggy drivers that abuse the api and cause a flood of cookies > >>>to be generated, and questions on when a unit number is eligible for > >>>reuse. For the first one, a ring buffer of cookies would solve the > >>>immediate problem, but you might still have some risk of drivers > >>>selectively wrapping the buffer for whatever accidental or evil > >>>purpose. For the second problem, maybe a unit number stays > >>>persistent only if the PCIe hot remove mechanism requests it, and > >>>then only until the ring-buffer wraps. > >>> > >>>Scott > >>> > >>I do not think the whole problem as depicted by Julian is even worth > >>solving. Why keeping any data for the device that might _never_ come > >>back? What if the device hierarchy just starts from the PCI-e and > >>extends upwards and user still holds on to some vestiges of a previous > >>device chain (say, by keeping a character control device sharing the > >>same unit number open, common practice)? Reusing unit number is much > >>trickier then, and might not be even possible. So, before one jumps > >>into 'how', can we agree on 'why' first? When device goes away, it is > >>not just this device's device_t that is disappearing, it is a whole > >>tree rooted at that device. I see no point in trying to reconstruct > >>that. > >There's a reason that PC Card and CardBus never supported this at all. > >The assumption was that reconnecting devices is so cheap that it isn't > >worth the bother. This is true for all but some specialized devices > >today: network information is easy to reconstruct, storage drives are easy > >to reconfigure (since we already fail all in-flight transactions when the > >device goes away), etc. I can see some advantage to having storage cope, > >but there already geom classes that can help people code when drives can > >go away. > > > >>PCI-e hotplug proper is very much orthogonal to the question of unit > >>numbering and IS worth supporting. > >Yes. totally agreed. > > I'm not saying that it's vitally important but was wondering if people > had a strategy for it.. > i.e. is it a question worth worrying about? > > In a separate forum Warner and I (yeah I know I'm answering Warner, > but I'm addressing the others) discussed the feasibility of surviving > an "oops pulled the wrong card" event with regards to a particular > flash memory card. I was just carrying that forwards as a thought > experiment (There is actually a strategy that sounds feasible). > > The problem of getting a serial number out of the BAR space during > probe is also possibly solvable in our case but the question of how > long to remember a device is legitimate an My answer would be that > 1/ a particular driver would be able to specify whether it could > handle this, and > 2/ it might be limited to some pragmatic number such as 16 or 32, or a > time limit. Why not extend the geom_label idea further? If there is a serial number, can that be exposed via /dev somehow so that the problem is moved out of the kernel space? That way devd could say "this serial number gets symlinked to this disk node" (for example). Gary From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 19:34:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 910011065672; Tue, 24 Jul 2012 19:34:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1998FC08; Tue, 24 Jul 2012 19:34:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6OJJcY9070525; Tue, 24 Jul 2012 15:19:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6OJJbqJ070500; Tue, 24 Jul 2012 19:19:37 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Jul 2012 19:19:37 GMT Message-Id: <201207241919.q6OJJbqJ070500@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 19:34:01 -0000 TB --- 2012-07-24 18:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-24 18:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-24 18:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-24 18:30:00 - cleaning the object tree TB --- 2012-07-24 18:30:00 - cvsupping the source tree TB --- 2012-07-24 18:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-24 18:31:06 - building world TB --- 2012-07-24 18:31:06 - CROSS_BUILD_TESTING=YES TB --- 2012-07-24 18:31:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-24 18:31:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-24 18:31:06 - SRCCONF=/dev/null TB --- 2012-07-24 18:31:06 - TARGET=pc98 TB --- 2012-07-24 18:31:06 - TARGET_ARCH=i386 TB --- 2012-07-24 18:31:06 - TZ=UTC TB --- 2012-07-24 18:31:06 - __MAKE_CONF=/dev/null TB --- 2012-07-24 18:31:06 - cd /src TB --- 2012-07-24 18:31:06 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 24 18:31:06 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/TransGCAttrs.cpp -o TransGCAttrs.o c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/TransGCCalls.cpp -o TransGCCalls.o c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/TransProperties.cpp -o TransProperties.o /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include/clang/AST/RecursiveASTVisitor.h: In member function 'bool clang::RecursiveASTVisitor::TraverseDeclRefExpr(clang::DeclRefExpr*) [with Derived = ::PropertiesRewriter::PlusOneAssign]': /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include/clang/AST/RecursiveASTVisitor.h:1901: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libclangarcmigrate. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-24 19:19:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-24 19:19:37 - ERROR: failed to build world TB --- 2012-07-24 19:19:37 - 1996.82 user 374.08 system 2977.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 20:00:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F4751065672 for ; Tue, 24 Jul 2012 20:00:36 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 877CE8FC12 for ; Tue, 24 Jul 2012 20:00:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3331B7300A; Tue, 24 Jul 2012 22:20:19 +0200 (CEST) Date: Tue, 24 Jul 2012 22:20:19 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20120724202019.GA22927@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 20:00:36 -0000 if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt modes: EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas FAST_INTR has a custom handler that signals a taskqueue to do the job. I have no idea which actual hardware uses it (all of my Intel 1G cards use either "em" or "igb"), but "lem" is the driver used in qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet rates than the other. Any objections if i change the default to EM_LEGACY_IRQ ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 21:08:27 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 859921065674; Tue, 24 Jul 2012 21:08:27 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9308FC1C; Tue, 24 Jul 2012 21:08:27 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q6OL8I0X031248 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2012 21:08:20 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <088BF877-50E6-42C5-98EF-DAB0FA52C348@freebsd.org> Date: Tue, 24 Jul 2012 22:08:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05368BFA-F5F6-49D4-BE63-7C9360E54F54@FreeBSD.org> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> <20120723191856.GR2676@deviant.kiev.zoral.com.ua> <088BF877-50E6-42C5-98EF-DAB0FA52C348@freebsd.org> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: Dimitry Andric , freebsd-current@FreeBSD.org, Kim Culhan Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:08:27 -0000 On 23 Jul 2012, at 20:53, David Chisnall wrote: > On 23 Jul 2012, at 20:18, Konstantin Belousov wrote: >=20 >> Longer description is that pc_curthread is offset 0 if %gs-based. >> The dereferenced pointer point to the struct thread, which contains >> td_proc pointer at offset 8. Instead, clang seems to dereference >> td_proc from offset 8 based on %gs, or something similar. >=20 > This appears to be a bug in the LLVM X86 back end. It is performing = an invalid fold of the two loads. I have filed this bug: >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D13438 And fixed it in LLVM r160687. Since it's a single-line change, we can = probably pull it into our version. dim: http://llvm.org/viewvc/llvm-project?view=3Drev&revision=3D160687 David From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 22:07:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62A50106566C for ; Tue, 24 Jul 2012 22:07:53 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1AEC78FC16 for ; Tue, 24 Jul 2012 22:07:53 +0000 (UTC) Received: by qaat11 with SMTP id t11so122188qaa.13 for ; Tue, 24 Jul 2012 15:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a8YztOKiQlKWM00u2NsB7dq4oGq/bR8vm3jJY7Ya5nw=; b=uSbojpxHUfOeGbhyzuKM2ogAHC1bU+cWCgMPr8fy4rlAgZ4rZUApLP2KxO1C35hDRe vEchYiSUzkR42kCt8IL1gEDoq4PfQtDa5C7FtA+WMOZvOI6jI/vEViOWt9UBsBB8k2yf kmLiEgkj2AMzeHWsyRjqjw8UtL75ScJXrx2f0qq0Q7RjpdX2bS8v4tQwbPJNiwexeuI6 StVGyHitl79ddsrJDP1UHDdLwO6+/PsHjsx7TNPdxbOHHEEZK6P0R0zH+KBj1jCF8yu4 Urpa8NEZwdS5n25G3tSLSmSBX63VHyVccnjYg0dMzNLu3MOsgOtBKXaoqYB94iULrftv 5tFA== MIME-Version: 1.0 Received: by 10.224.59.141 with SMTP id l13mr33958523qah.91.1343167672456; Tue, 24 Jul 2012 15:07:52 -0700 (PDT) Received: by 10.49.104.227 with HTTP; Tue, 24 Jul 2012 15:07:52 -0700 (PDT) In-Reply-To: <20120724202019.GA22927@onelab2.iet.unipi.it> References: <20120724202019.GA22927@onelab2.iet.unipi.it> Date: Tue, 24 Jul 2012 15:07:52 -0700 Message-ID: From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 22:07:53 -0000 Interesting, lem is all the non-pcie hardware, and if you see better performance out of the LEGACY path then I'm OK with changing the default. Jack On Tue, Jul 24, 2012 at 1:20 PM, Luigi Rizzo wrote: > if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt modes: > EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas > FAST_INTR has a custom handler that signals a taskqueue to do the job. > > I have no idea which actual hardware uses it (all of my Intel 1G > cards use either "em" or "igb"), but "lem" is the driver used in > qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet > rates than the other. > > Any objections if i change the default to EM_LEGACY_IRQ ? > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 22:43:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 755A6106564A; Tue, 24 Jul 2012 22:43:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DEA998FC08; Tue, 24 Jul 2012 22:43:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6OMhp0u037770; Wed, 25 Jul 2012 01:43:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6OMhcKJ082718; Wed, 25 Jul 2012 01:43:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6OMhcGP082717; Wed, 25 Jul 2012 01:43:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jul 2012 01:43:38 +0300 From: Konstantin Belousov To: David Chisnall Message-ID: <20120724224338.GZ2676@deviant.kiev.zoral.com.ua> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> <20120723191856.GR2676@deviant.kiev.zoral.com.ua> <088BF877-50E6-42C5-98EF-DAB0FA52C348@freebsd.org> <05368BFA-F5F6-49D4-BE63-7C9360E54F54@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5KVt+DrA7aLR99aT" Content-Disposition: inline In-Reply-To: <05368BFA-F5F6-49D4-BE63-7C9360E54F54@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Dimitry Andric , freebsd-current@freebsd.org, Kim Culhan Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 22:43:43 -0000 --5KVt+DrA7aLR99aT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 24, 2012 at 10:08:13PM +0100, David Chisnall wrote: > On 23 Jul 2012, at 20:53, David Chisnall wrote: >=20 > > On 23 Jul 2012, at 20:18, Konstantin Belousov wrote: > >=20 > >> Longer description is that pc_curthread is offset 0 if %gs-based. > >> The dereferenced pointer point to the struct thread, which contains > >> td_proc pointer at offset 8. Instead, clang seems to dereference > >> td_proc from offset 8 based on %gs, or something similar. > >=20 > > This appears to be a bug in the LLVM X86 back end. It is performing an= invalid fold of the two loads. I have filed this bug: > >=20 > > http://llvm.org/bugs/show_bug.cgi?id=3D13438 >=20 > And fixed it in LLVM r160687. Since it's a single-line change, we can pr= obably pull it into our version. >=20 > dim: http://llvm.org/viewvc/llvm-project?view=3Drev&revision=3D160687 As kan rightfully notes, the assumption that &%fs:0 =3D=3D *%fs:0 holds for userspace on amd64, and the same is true for %gs userspace on i386. The change you committed to clang/llvm/whatever it called just breaks useful optimization for FreeBSD. Sigh. --5KVt+DrA7aLR99aT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAPJRoACgkQC3+MBN1Mb4hxxwCcCK6uhCN5jRilzaMof0VyylQp FOQAn2QaqEwCjnLidV+rYhPdgMfoOGSA =s2V6 -----END PGP SIGNATURE----- --5KVt+DrA7aLR99aT-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 08:04:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A365106566B; Wed, 25 Jul 2012 08:04:05 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0EAD38FC0C; Wed, 25 Jul 2012 08:04:04 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q6P841tK033900 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2012 08:04:03 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120724224338.GZ2676@deviant.kiev.zoral.com.ua> Date: Wed, 25 Jul 2012 09:03:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> <20120723191856.GR2676@deviant.kiev.zoral.com.ua> <088BF877-50E6-42C5-98EF-DAB0FA52C348@freebsd.org> <05368BFA-F5F6-49D4-BE63-7C9360E54F54@FreeBSD.org> <20120724224338.GZ2676@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: Kim Culhan , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 08:04:05 -0000 On 24 Jul 2012, at 23:43, Konstantin Belousov wrote: > As kan rightfully notes, the assumption that &%fs:0 =3D=3D *%fs:0 = holds for > userspace on amd64, and the same is true for %gs userspace on i386. > The change you committed to clang/llvm/whatever it called just breaks > useful optimization for FreeBSD. If you can suggest a way of differentiating the kernel and userspace = compilation targets, then I would be happy to hear it and will make the = appropriate change. Until then, I would rather have slightly = sub-optimal code in userspace than incorrect code in kernelspace. > Sigh Very helpful, thank you. David= From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 09:14:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65B5A106566C; Wed, 25 Jul 2012 09:14:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1930A8FC14; Wed, 25 Jul 2012 09:14:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6P9ERwB060250; Wed, 25 Jul 2012 05:14:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6P9ERGx060233; Wed, 25 Jul 2012 09:14:27 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Jul 2012 09:14:27 GMT Message-Id: <201207250914.q6P9ERGx060233@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:14:28 -0000 TB --- 2012-07-25 08:21:33 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-25 08:21:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-25 08:21:33 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-25 08:21:33 - cleaning the object tree TB --- 2012-07-25 08:21:33 - cvsupping the source tree TB --- 2012-07-25 08:21:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-25 08:22:39 - building world TB --- 2012-07-25 08:22:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-25 08:22:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-25 08:22:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-25 08:22:39 - SRCCONF=/dev/null TB --- 2012-07-25 08:22:39 - TARGET=powerpc TB --- 2012-07-25 08:22:39 - TARGET_ARCH=powerpc64 TB --- 2012-07-25 08:22:39 - TZ=UTC TB --- 2012-07-25 08:22:39 - __MAKE_CONF=/dev/null TB --- 2012-07-25 08:22:39 - cd /src TB --- 2012-07-25 08:22:39 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 25 08:22:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDeclCXX.cpp -o CGDeclCXX.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGException.cpp -o CGException.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp -o CGExpr.o /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp: In member function 'clang::CodeGen::LValue clang::CodeGen::CodeGenFunction::EmitLValueForFieldInitialization(clang::CodeGen::LValue, const clang::FieldDecl*)': /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp:2113: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libclangcodegen. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-25 09:14:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-25 09:14:27 - ERROR: failed to build world TB --- 2012-07-25 09:14:27 - 2367.34 user 363.77 system 3174.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 10:05:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0495106564A; Wed, 25 Jul 2012 10:05:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3BAAF8FC14; Wed, 25 Jul 2012 10:05:38 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6PA5i3r018120; Wed, 25 Jul 2012 13:05:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6PA5V0f087512; Wed, 25 Jul 2012 13:05:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6PA5VTJ087511; Wed, 25 Jul 2012 13:05:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jul 2012 13:05:31 +0300 From: Konstantin Belousov To: David Chisnall Message-ID: <20120725100531.GG2676@deviant.kiev.zoral.com.ua> References: <50097BF0.9010103@FreeBSD.org> <20120721211628.GE2676@deviant.kiev.zoral.com.ua> <6006581B-6B1C-4DFB-8662-3EB35869CA5F@FreeBSD.org> <20120722180119.GJ2676@deviant.kiev.zoral.com.ua> <20120723191856.GR2676@deviant.kiev.zoral.com.ua> <088BF877-50E6-42C5-98EF-DAB0FA52C348@freebsd.org> <05368BFA-F5F6-49D4-BE63-7C9360E54F54@FreeBSD.org> <20120724224338.GZ2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ek+w9ScjNaooOpN+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kim Culhan , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: -current build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:05:39 -0000 --Ek+w9ScjNaooOpN+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 09:03:58AM +0100, David Chisnall wrote: > On 24 Jul 2012, at 23:43, Konstantin Belousov wrote: >=20 > > As kan rightfully notes, the assumption that &%fs:0 =3D=3D *%fs:0 holds= for > > userspace on amd64, and the same is true for %gs userspace on i386. > > The change you committed to clang/llvm/whatever it called just breaks > > useful optimization for FreeBSD. >=20 > If you can suggest a way of differentiating the kernel and userspace comp= ilation targets, then I would be happy to hear it and will make the appropr= iate change. Until then, I would rather have slightly sub-optimal code i= n userspace than incorrect code in kernelspace. Try to differentiate on the memory layout model, the -mcmodel=3Dkernel thin= g. It shall be passed down to the very last stage of the backend, I believe. >=20 > > Sigh >=20 > Very helpful, thank you. >=20 > David --Ek+w9ScjNaooOpN+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAPxOoACgkQC3+MBN1Mb4haIwCdF6UFMpLCg65rKGJV+XX4KtSF sgAAn1gvHvMq/pURBJUgxnWgFL5F8i+T =knC+ -----END PGP SIGNATURE----- --Ek+w9ScjNaooOpN+-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 11:30:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7ED91065674 for ; Wed, 25 Jul 2012 11:30:31 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2998FC1E for ; Wed, 25 Jul 2012 11:30:31 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1StznS-0003n6-Io for freebsd-current@freebsd.org; Wed, 25 Jul 2012 12:30:30 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1StznS-0007nA-60 for freebsd-current@freebsd.org; Wed, 25 Jul 2012 12:30:30 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q6PBUTQ3027928 for ; Wed, 25 Jul 2012 12:30:29 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q6PBUTHn027925 for freebsd-current@freebsd.org; Wed, 25 Jul 2012 12:30:29 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 25 Jul 2012 12:30:29 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20120725113029.GA11089@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: openssl upgrade, libcrypto, libssl confusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:30:32 -0000 In /usr/src/UPDATING I see 20120712: The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are configuration changes. Make sure to merge /etc/ssl/openssl.cnf. Looking at this: # make -C /usr/src check-old-libs >>> Checking for old libraries /lib/libcrypto.so.6 /usr/lib/libssl.so.6 # Am I correct that these 2 libraries can be safely deleted? However, I can't see any version 7 of these libs. Have these libs been replaced by some other lib? Finally, I've rebuilt mail/fetchmail and mail/mutt already several times, but the binaries still use these 2 libs: TZAV> ldd /usr/local/bin/mutt /usr/local/bin/mutt: libncursesw.so.8 => /lib/libncursesw.so.8 (0x1202f6000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x1203aa000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x1203ca000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x1203e4000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x1204c6000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x120550000) libcrypto.so.6 => /lib/libcrypto.so.6 (0x120562000) ^^^^^^^^^^^^^^^ libasn1.so.11 => /usr/lib/libasn1.so.11 (0x120812000) libwind.so.11 => /usr/lib/libwind.so.11 (0x120918000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x120952000) libroken.so.11 => /usr/lib/libroken.so.11 (0x120968000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x120996000) libssl.so.6 => /usr/lib/libssl.so.6 (0x1209d0000) ^^^^^^^^^^^^^^^ libz.so.6 => /lib/libz.so.6 (0x120a72000) libintl.so.9 => /usr/local/lib/libintl.so.9 (0x120aaa000) libthr.so.3 => /lib/libthr.so.3 (0x120acc000) libc.so.7 => /lib/libc.so.7 (0x120b1a000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x120dca000) TZAV> TZAV> ldd /usr/local/bin/fetchmail /usr/local/bin/fetchmail: libopie.so.7 => /usr/lib/libopie.so.7 (0x120100000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x12011e000) libkvm.so.5 => /lib/libkvm.so.5 (0x120158000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x120178000) libssl.so.6 => /usr/lib/libssl.so.6 (0x12018a000) ^^^^^^^^^^^^^^^ libcrypto.so.6 => /lib/libcrypto.so.6 (0x12022c000) ^^^^^^^^^^^^^^^ libc.so.7 => /lib/libc.so.7 (0x1204dc000) libmd.so.6 => /lib/libmd.so.6 (0x12078c000) TZAV> Or will the new library (what is it?) will not be used unless I delete the old ones? Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 12:06:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A9981065674 for ; Wed, 25 Jul 2012 12:06:27 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id B39248FC18 for ; Wed, 25 Jul 2012 12:06:26 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Su0MD-0004Ps-Qm for freebsd-current@freebsd.org; Wed, 25 Jul 2012 13:06:25 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Su0MD-0001yo-MA for freebsd-current@freebsd.org; Wed, 25 Jul 2012 13:06:25 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q6PC6Pa8032967 for ; Wed, 25 Jul 2012 13:06:25 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q6PC6PkN032966 for freebsd-current@freebsd.org; Wed, 25 Jul 2012 13:06:25 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 25 Jul 2012 13:06:25 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20120725120624.GA32934@mech-cluster241.men.bris.ac.uk> References: <20120725113029.GA11089@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120725113029.GA11089@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: openssl upgrade, libcrypto, libssl confusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 12:06:27 -0000 On Wed, Jul 25, 2012 at 12:30:29PM +0100, Anton Shterenlikht wrote: > In /usr/src/UPDATING I see > > 20120712: > The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring > libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are > configuration changes. Make sure to merge /etc/ssl/openssl.cnf. oops.. wait a minute, I'm still on # uname -a FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 root@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 # So this change shouldn't apply to me yet. Still there are *lots* of binaries, and libs linked with /lib/libcrypto.so.6: Binaries that are linked with: /lib/libcrypto.so.6 /bin/ed /bin/red /lib/geom/geom_eli.so /sbin/hastctl /sbin/hastd /usr/bin/bdes /usr/bin/bsdcpio /usr/bin/bsdtar /usr/bin/bsnmpget /usr/bin/bsnmpset /usr/bin/bsnmpwalk /usr/bin/chkey /usr/bin/cvs /usr/bin/dc /usr/bin/dig /usr/bin/fetch /usr/bin/host /usr/bin/hxtool /usr/bin/kadmin /usr/bin/kcc /usr/bin/kdestroy /usr/bin/kf /usr/bin/kgetcred /usr/bin/kinit /usr/bin/klist /usr/bin/kpasswd /usr/bin/ksu /usr/bin/kswitch /usr/bin/newkey /usr/bin/nslookup /usr/bin/nsupdate /usr/bin/openssl /usr/bin/scp /usr/bin/sftp /usr/bin/slogin /usr/bin/ssh /usr/bin/ssh-add /usr/bin/ssh-agent /usr/bin/ssh-keygen /usr/bin/ssh-keyscan /usr/bin/string2key /usr/bin/telnet /usr/bin/verify_krb5_conf /usr/games/factor /usr/lib/libarchive.so.6 /usr/lib/libbsnmp.so.6 /usr/lib/libfetch.so.6 /usr/lib/libgssapi_krb5.so.10 /usr/lib/libgssapi_ntlm.so.10 /usr/lib/libheimntlm.so.11 /usr/lib/libhx509.so.11 /usr/lib/libkdc.so.11 /usr/lib/libkrb5.so.11 /usr/lib/libmp.so.7 /usr/lib/libradius.so.4 /usr/lib/libssh.so.5 /usr/lib/libssl.so.6 /usr/lib/pam_krb5.so.5 /usr/lib/pam_ksu.so.5 /usr/lib/pam_ssh.so.5 /usr/libexec/digest-service and so on, so is it really right that I can safely delete it? > > Looking at this: > > # make -C /usr/src check-old-libs > >>> Checking for old libraries > /lib/libcrypto.so.6 > /usr/lib/libssl.so.6 > # > -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 12:51:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2EE6106566B for ; Wed, 25 Jul 2012 12:51:45 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 784838FC0A for ; Wed, 25 Jul 2012 12:51:45 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6PCpcgx027305 for ; Wed, 25 Jul 2012 06:51:42 -0600 Date: Wed, 25 Jul 2012 19:54:08 +0700 From: Erich Dollansky To: freebsd-current@freebsd.org Message-ID: <20120725195408.732d59b6@AMD620.ovitrap.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: machine freezes when using USB disk and X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 12:51:45 -0000 Hi, I have strange problem which I can reproduce. When I copy some 100GB to a disk via USB when X is not active, it works without any problems. When I copy some 100GB to a disk via USB when X is running, the machine freezes. It does not react to keyboard, mouse and network actions. When I use only X on the same machine and do the same copy via network, the machine behaves as expected. What could I do to locate the problem? Erich PS uname says: FreeBSD AMD620.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #38: Sat Jul 21 06:58:49 WIT 2012 From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 13:15:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC4E3106564A for ; Wed, 25 Jul 2012 13:15:34 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (mail.averesystems.com [208.70.68.85]) by mx1.freebsd.org (Postfix) with ESMTP id C1CC78FC0C for ; Wed, 25 Jul 2012 13:15:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id 9755748073A; Wed, 25 Jul 2012 09:08:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tfidiPShv9O; Wed, 25 Jul 2012 09:08:45 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id 431FA480717; Wed, 25 Jul 2012 09:08:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <20120724202019.GA22927@onelab2.iet.unipi.it> Date: Wed, 25 Jul 2012 09:08:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <209163E0-F36C-4EBE-B5D5-5D538B12C95D@averesystems.com> References: <20120724202019.GA22927@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1278) Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:15:35 -0000 lem is also used under VMware. Performance and stability should be = tested there, too, before this change. -Andrew On Jul 24, 2012, at 4:20 PM, Luigi Rizzo wrote: > if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt = modes: > EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas > FAST_INTR has a custom handler that signals a taskqueue to do the job. >=20 > I have no idea which actual hardware uses it (all of my Intel 1G > cards use either "em" or "igb"), but "lem" is the driver used in > qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet > rates than the other. >=20 > Any objections if i change the default to EM_LEGACY_IRQ ? >=20 > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 13:38:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20353106566C for ; Wed, 25 Jul 2012 13:38:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D49578FC15 for ; Wed, 25 Jul 2012 13:37:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7B3927300A; Wed, 25 Jul 2012 15:57:56 +0200 (CEST) Date: Wed, 25 Jul 2012 15:57:56 +0200 From: Luigi Rizzo To: Andrew Boyer Message-ID: <20120725135756.GB32762@onelab2.iet.unipi.it> References: <20120724202019.GA22927@onelab2.iet.unipi.it> <209163E0-F36C-4EBE-B5D5-5D538B12C95D@averesystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <209163E0-F36C-4EBE-B5D5-5D538B12C95D@averesystems.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:38:00 -0000 On Wed, Jul 25, 2012 at 09:08:42AM -0400, Andrew Boyer wrote: > lem is also used under VMware. Performance and stability should be tested there, too, before this change. i do not have VMware so i cannot test it myself, but at the end of this email you can find a suitable image and instructions to test it. This said the issue of stability has nothing to do with the hypervisor (as it changes things in the guest), and regarding performance it is likely to (slightly) improve performance on all hypervisors because the legacy driver saves a couple of MMIO accesses per interrupt (and such accesses cost ~10K cycles each, even with hw support) Test case: - fetch http://info.iet.unipi.it/~luigi/netmap/20120725-netmap-picobsd-head-amd64.bin - start your favourite hypervisor, something equivalent to qemu-system-x86_64 -m 512 -hda 20120725-netmap-picobsd-head-amd64.bin - within the image login and then run dhclient em0 netsend 10.0.2.2 5678 60 0 5 cheers luigi > -Andrew > > On Jul 24, 2012, at 4:20 PM, Luigi Rizzo wrote: > > > if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt modes: > > EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas > > FAST_INTR has a custom handler that signals a taskqueue to do the job. > > > > I have no idea which actual hardware uses it (all of my Intel 1G > > cards use either "em" or "igb"), but "lem" is the driver used in > > qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet > > rates than the other. > > > > Any objections if i change the default to EM_LEGACY_IRQ ? > > > > cheers > > luigi > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 14:12:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A2AE106564A for ; Wed, 25 Jul 2012 14:12:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id E787B8FC0C for ; Wed, 25 Jul 2012 14:12:57 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 297805327; Wed, 25 Jul 2012 16:12:47 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 25 Jul 2012 16:13:04 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120725195408.732d59b6@AMD620.ovitrap.com> In-Reply-To: <20120725195408.732d59b6@AMD620.ovitrap.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207251613.04300.hselasky@c2i.net> Cc: Erich Dollansky Subject: Re: machine freezes when using USB disk and X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 14:12:58 -0000 On Wednesday 25 July 2012 14:54:08 Erich Dollansky wrote: > Hi, > > I have strange problem which I can reproduce. > > When I copy some 100GB to a disk via USB when X is not active, it works > without any problems. > > When I copy some 100GB to a disk via USB when X is running, the machine > freezes. It does not react to keyboard, mouse and network actions. > > When I use only X on the same machine and do the same copy via network, > the machine behaves as expected. > > What could I do to locate the problem? > > Erich > > PS > > uname says: > > FreeBSD AMD620.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #38: Sat > Jul 21 06:58:49 WIT 2012 You might want to check what interrupts are shared. Might be an IRQ problem. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 14:49:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B587106566B for ; Wed, 25 Jul 2012 14:49:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id B816C8FC0A for ; Wed, 25 Jul 2012 14:49:00 +0000 (UTC) Received: by lbon10 with SMTP id n10so862591lbo.13 for ; Wed, 25 Jul 2012 07:48:58 -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=V59hpLROxBClv+EqUt821Vnfp4hmAzfpgX1m2HYMql0=; b=haky0VUI4sO/28nrzpwv+WEUPichies+0DXVeuuc93gEID5AwMjstliLDu3dwcDkSB c/UOcmHp+dTeuf3FqQ0VgQHEOENvAyRgs1VcX4/eVKLdz2T4h3OjJ3nNJVmL2G5g7wtK yed5QLeMxnqBbj4uQ0pPST+qed1oPKD4/gL5V1ySvUv4sFcmAkfNjuApOBklsOWhfvkD RvvnMtaZBKMmozuJHGYLq0iWTjO9O+B5xuuci2pYHp1t8Oa2PQYvLaTFMzGFu2l8fRck bGIRfyKWqnm8ESS3cL/3LHJCRg+rmZHyWZ8ze5kRo1lQw9+8n0t4WeUK6hy2bGWek3jB t5rw== MIME-Version: 1.0 Received: by 10.112.27.226 with SMTP id w2mr11950891lbg.57.1343227737820; Wed, 25 Jul 2012 07:48:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.112.20.197 with HTTP; Wed, 25 Jul 2012 07:48:57 -0700 (PDT) In-Reply-To: <20120724202019.GA22927@onelab2.iet.unipi.it> References: <20120724202019.GA22927@onelab2.iet.unipi.it> Date: Wed, 25 Jul 2012 07:48:57 -0700 X-Google-Sender-Auth: MYnZOa5x5LAN0owgqqAGd9Fp53c Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 14:49:01 -0000 On 24 July 2012 13:20, Luigi Rizzo wrote: > if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt modes: > EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas > FAST_INTR has a custom handler that signals a taskqueue to do the job. > > I have no idea which actual hardware uses it (all of my Intel 1G > cards use either "em" or "igb"), but "lem" is the driver used in > qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet > rates than the other. > > Any objections if i change the default to EM_LEGACY_IRQ ? I suggest doing some digging to understand why. I bet we all know the answer, but it would be nice to have it documented and investigated. I bet em(4) isn't the only device that would benefit from this? 2c, Adrian From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 14:54:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD463106566C; Wed, 25 Jul 2012 14:54:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 996918FC12; Wed, 25 Jul 2012 14:54:07 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id F02D57300A; Wed, 25 Jul 2012 17:14:03 +0200 (CEST) Date: Wed, 25 Jul 2012 17:14:03 +0200 From: Luigi Rizzo To: Adrian Chadd Message-ID: <20120725151403.GA33640@onelab2.iet.unipi.it> References: <20120724202019.GA22927@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 14:54:07 -0000 On Wed, Jul 25, 2012 at 07:48:57AM -0700, Adrian Chadd wrote: > On 24 July 2012 13:20, Luigi Rizzo wrote: > > if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt modes: > > EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas > > FAST_INTR has a custom handler that signals a taskqueue to do the job. > > > > I have no idea which actual hardware uses it (all of my Intel 1G > > cards use either "em" or "igb"), but "lem" is the driver used in > > qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet > > rates than the other. > > > > Any objections if i change the default to EM_LEGACY_IRQ ? > > I suggest doing some digging to understand why. I bet we all know the > answer, but it would be nice to have it documented and investigated. I > bet em(4) isn't the only device that would benefit from this? I am not so sure i know the answer on bare iron (and my take is that the difference is more or less irrelevant there), but in the virtualized case the improvement is almost surely because the code used in FAST_INTR has a couple of MMIO accesses to disable/enable interrupts on the card while the taskqueue runs. These are expensive in a VM (such accesses cost ~10K cycles each, even with hw support) cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 15:13:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F47106566B; Wed, 25 Jul 2012 15:13:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF4108FC0A; Wed, 25 Jul 2012 15:13:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6PFDYoF095881; Wed, 25 Jul 2012 11:13:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6PFDYpc095864; Wed, 25 Jul 2012 15:13:34 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Jul 2012 15:13:34 GMT Message-Id: <201207251513.q6PFDYpc095864@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:13:36 -0000 TB --- 2012-07-25 13:31:49 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-25 13:31:49 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-25 13:31:49 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-25 13:31:49 - cleaning the object tree TB --- 2012-07-25 13:31:49 - cvsupping the source tree TB --- 2012-07-25 13:31:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-25 13:32:51 - building world TB --- 2012-07-25 13:32:51 - CROSS_BUILD_TESTING=YES TB --- 2012-07-25 13:32:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-25 13:32:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-25 13:32:51 - SRCCONF=/dev/null TB --- 2012-07-25 13:32:51 - TARGET=ia64 TB --- 2012-07-25 13:32:51 - TARGET_ARCH=ia64 TB --- 2012-07-25 13:32:51 - TZ=UTC TB --- 2012-07-25 13:32:51 - __MAKE_CONF=/dev/null TB --- 2012-07-25 13:32:51 - cd /src TB --- 2012-07-25 13:32:51 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 25 13:32:52 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 25 15:05:44 UTC 2012 TB --- 2012-07-25 15:05:44 - generating LINT kernel config TB --- 2012-07-25 15:05:44 - cd /src/sys/ia64/conf TB --- 2012-07-25 15:05:44 - /usr/bin/make -B LINT TB --- 2012-07-25 15:05:44 - cd /src/sys/ia64/conf TB --- 2012-07-25 15:05:44 - /usr/sbin/config -m LINT TB --- 2012-07-25 15:05:44 - building LINT kernel TB --- 2012-07-25 15:05:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-25 15:05:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-25 15:05:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-25 15:05:44 - SRCCONF=/dev/null TB --- 2012-07-25 15:05:44 - TARGET=ia64 TB --- 2012-07-25 15:05:44 - TARGET_ARCH=ia64 TB --- 2012-07-25 15:05:44 - TZ=UTC TB --- 2012-07-25 15:05:44 - __MAKE_CONF=/dev/null TB --- 2012-07-25 15:05:44 - cd /src TB --- 2012-07-25 15:05:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 25 15:05:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_lem.c: In function 'lem_xmit': /src/sys/dev/e1000/if_lem.c:1553: warning: nested extern declaration of 'netmap_drop' [-Wnested-externs] /src/sys/dev/e1000/if_lem.c:1732: warning: suggest parentheses around comparison in operand of & [-Wparentheses] /src/sys/dev/e1000/if_lem.c:1757: warning: nested extern declaration of 'netmap_repeat' [-Wnested-externs] /src/sys/dev/e1000/if_lem.c: In function 'lem_txeof': /src/sys/dev/e1000/if_lem.c:3018: error: 'netmap_copy' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:3018: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:3018: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-25 15:13:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-25 15:13:34 - ERROR: failed to build LINT kernel TB --- 2012-07-25 15:13:34 - 4618.95 user 716.26 system 6105.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 15:32:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 922781065673 for ; Wed, 25 Jul 2012 15:32:14 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 517978FC12 for ; Wed, 25 Jul 2012 15:32:14 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 19F4D7300A; Wed, 25 Jul 2012 17:52:11 +0200 (CEST) Date: Wed, 25 Jul 2012 17:52:11 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20120725155211.GA33971@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:32:14 -0000 During some ipfw/dummynet cleanup i noticed that the libkern version of inet_ntoa_r() is missing the buffer size argument that is present in the libc counterpart. Any objection if i fix it ? The change is trivial and the function is used only in a small number of places, see below (some of which are even commented out). # (cd ~/FreeBSD/head/sys; grep -r inet_ntoa_r .) ./libkern/inet_ntoa.c:inet_ntoa_r(struct in_addr ina, char *buf) ./net/flowtable.c: inet_ntoa_r(ssin->sin_addr, saddr); ./net/flowtable.c: inet_ntoa_r(dsin->sin_addr, daddr); ./net/flowtable.c: inet_ntoa_r(*(struct in_addr *) &dsin->sin_addr, daddr); ./net/flowtable.c: inet_ntoa_r(*(struct in_addr *) &hashkey[2], daddr); ./net/flowtable.c: inet_ntoa_r(*(struct in_addr *) &hashkey[1], saddr); ./net/if_llatbl.c: inet_ntoa_r(sin->sin_addr, l3s); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip->ip_src, src); ./netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip->ip_dst, dst); ./netinet/in.h:char *inet_ntoa_r(struct in_addr ina, char *buf); /* in libkern */ ./netinet/in_pcb.c: inet_ntoa_r(inc->inc_laddr, laddr_str); ./netinet/in_pcb.c: inet_ntoa_r(inc->inc_faddr, faddr_str); ./netinet/tcp_subr.c: inet_ntoa_r(inc->inc_faddr, sp); ./netinet/tcp_subr.c: inet_ntoa_r(inc->inc_laddr, sp); ./netinet/tcp_subr.c: inet_ntoa_r(ip->ip_src, sp); ./netinet/tcp_subr.c: inet_ntoa_r(ip->ip_dst, sp); cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 16:14:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D396106564A for ; Wed, 25 Jul 2012 16:14:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by mx1.freebsd.org (Postfix) with ESMTP id EB8E18FC0A for ; Wed, 25 Jul 2012 16:14:01 +0000 (UTC) Received: by qcab12 with SMTP id b12so667735qca.18 for ; Wed, 25 Jul 2012 09:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4/jHwbB4H/IUiF3r9JvCk/n2F5DpIwEX3mz+UZmE1Dg=; b=mRh+CFJBBG6rsW8MTT++dmlAN3u5LLAaaqMsC+i/+0LhwI8HGlir/5VyAdI3OxZGKD MEblWi+XSiRwvlgHEFqAnbNjdSauZTkZo72pDI5bkOcHKtb92I0qDo9aS9kWKHvJWC8+ zz5icRaV1layfkMhsJZ6yt5Ht/aJoo7PqgLFYPGHzR8iPWBav+peSbTzCQGhOu8qjGMQ IUFrAGwXzZq4P3pvVJqlVu8CZOYtpdClKlRtYCmcufw6yKWgcMwFo+gS+IzAycSXWP2v gnzpRqsL+rJGHxGQjJZTiSSZZzW7fYAqDfaEpl6QTD4vPwRuosPnjHW7l62piKwFM2Pj m0zw== MIME-Version: 1.0 Received: by 10.60.31.165 with SMTP id b5mr12058249oei.58.1343232841353; Wed, 25 Jul 2012 09:14:01 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Wed, 25 Jul 2012 09:14:01 -0700 (PDT) In-Reply-To: <20120725120624.GA32934@mech-cluster241.men.bris.ac.uk> References: <20120725113029.GA11089@mech-cluster241.men.bris.ac.uk> <20120725120624.GA32934@mech-cluster241.men.bris.ac.uk> Date: Wed, 25 Jul 2012 09:14:01 -0700 Message-ID: From: Garrett Cooper To: Anton Shterenlikht Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: openssl upgrade, libcrypto, libssl confusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 16:14:02 -0000 On Wed, Jul 25, 2012 at 5:06 AM, Anton Shterenlikht wrote: > On Wed, Jul 25, 2012 at 12:30:29PM +0100, Anton Shterenlikht wrote: >> In /usr/src/UPDATING I see >> >> 20120712: >> The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring >> libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are >> configuration changes. Make sure to merge /etc/ssl/openssl.cnf. > > oops.. wait a minute, I'm still on > > # uname -a > FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 root@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 > # > > So this change shouldn't apply to me yet. > > Still there are *lots* of binaries, and libs > linked with /lib/libcrypto.so.6: > > Binaries that are linked with: /lib/libcrypto.so.6 ... > and so on, > > so is it really right that I can safely delete it? Some ldd/objdump and grep magic will give you the answer you need. check-old-libs only points out candidates for removal based on existence. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 16:17:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E2B41065670 for ; Wed, 25 Jul 2012 16:17:26 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id EF6008FC08 for ; Wed, 25 Jul 2012 16:17:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,653,1336363200"; d="scan'208";a="203197595" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 25 Jul 2012 12:17:19 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 25 Jul 2012 09:17:18 -0700 From: Oleg Moskalenko To: 'Anton Shterenlikht' , "freebsd-current@freebsd.org" Date: Wed, 25 Jul 2012 09:17:17 -0700 Thread-Topic: openssl upgrade, libcrypto, libssl confusion Thread-Index: Ac1qWP/ge9oF9xGlSI6sdrGlCR2jcwAJzkrQ Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA39FE6E6@SJCPMAILBOX01.citrite.net> References: <20120725113029.GA11089@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120725113029.GA11089@mech-cluster241.men.bris.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: openssl upgrade, libcrypto, libssl confusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 16:17:26 -0000 Anton,=20 I use mostly static openssl libraries, but I suppose it applies to the dyna= mic ones, too: with any OpenSSL version (including 1.0.1c), you need libcry= pto and libssl. With the new OpenSSL version, you need the new library vers= ions, and you must recompile your binary code to use the new dynamic librar= ies (because there probably some headers incompatibilities between the vers= ions). You just misunderstood the release notes. Do not delete the library,= just re-install the new version. Regards, Oleg > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Anton Shterenlikht > Sent: Wednesday, July 25, 2012 4:30 AM > To: freebsd-current@freebsd.org > Subject: openssl upgrade, libcrypto, libssl confusion >=20 > In /usr/src/UPDATING I see >=20 > 20120712: > The OpenSSL has been upgraded to 1.0.1c. Any binaries > requiring > libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there > are > configuration changes. Make sure to merge /etc/ssl/openssl.cnf. >=20 > Looking at this: >=20 > # make -C /usr/src check-old-libs > >>> Checking for old libraries > /lib/libcrypto.so.6 > /usr/lib/libssl.so.6 > # >=20 > Am I correct that these 2 libraries can be safely deleted? >=20 > However, I can't see any version 7 of these libs. > Have these libs been replaced by some other lib? >=20 > Finally, I've rebuilt mail/fetchmail and mail/mutt > already several times, but the binaries still > use these 2 libs: >=20 > TZAV> ldd /usr/local/bin/mutt > /usr/local/bin/mutt: > libncursesw.so.8 =3D> /lib/libncursesw.so.8 (0x1202f6000) > libgssapi.so.10 =3D> /usr/lib/libgssapi.so.10 (0x1203aa000) > libheimntlm.so.11 =3D> /usr/lib/libheimntlm.so.11 (0x1203ca000) > libkrb5.so.11 =3D> /usr/lib/libkrb5.so.11 (0x1203e4000) > libhx509.so.11 =3D> /usr/lib/libhx509.so.11 (0x1204c6000) > libcom_err.so.5 =3D> /usr/lib/libcom_err.so.5 (0x120550000) > libcrypto.so.6 =3D> /lib/libcrypto.so.6 (0x120562000) > ^^^^^^^^^^^^^^^ > libasn1.so.11 =3D> /usr/lib/libasn1.so.11 (0x120812000) > libwind.so.11 =3D> /usr/lib/libwind.so.11 (0x120918000) > libheimbase.so.11 =3D> /usr/lib/libheimbase.so.11 (0x120952000) > libroken.so.11 =3D> /usr/lib/libroken.so.11 (0x120968000) > libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x120996000) > libssl.so.6 =3D> /usr/lib/libssl.so.6 (0x1209d0000) > ^^^^^^^^^^^^^^^ > libz.so.6 =3D> /lib/libz.so.6 (0x120a72000) > libintl.so.9 =3D> /usr/local/lib/libintl.so.9 (0x120aaa000) > libthr.so.3 =3D> /lib/libthr.so.3 (0x120acc000) > libc.so.7 =3D> /lib/libc.so.7 (0x120b1a000) > libiconv.so.3 =3D> /usr/local/lib/libiconv.so.3 (0x120dca000) > TZAV> >=20 > TZAV> ldd /usr/local/bin/fetchmail > /usr/local/bin/fetchmail: > libopie.so.7 =3D> /usr/lib/libopie.so.7 (0x120100000) > libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x12011e000) > libkvm.so.5 =3D> /lib/libkvm.so.5 (0x120158000) > libcom_err.so.5 =3D> /usr/lib/libcom_err.so.5 (0x120178000) > libssl.so.6 =3D> /usr/lib/libssl.so.6 (0x12018a000) > ^^^^^^^^^^^^^^^ > libcrypto.so.6 =3D> /lib/libcrypto.so.6 (0x12022c000) > ^^^^^^^^^^^^^^^ > libc.so.7 =3D> /lib/libc.so.7 (0x1204dc000) > libmd.so.6 =3D> /lib/libmd.so.6 (0x12078c000) > TZAV> >=20 > Or will the new library (what is it?) will not > be used unless I delete the old ones? >=20 > Thanks >=20 > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 331 5944 > Fax: +44 (0)117 929 4423 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 16:37:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0CBC106566B for ; Wed, 25 Jul 2012 16:37:29 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8D08FC0A for ; Wed, 25 Jul 2012 16:37:29 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Su4aW-00012z-Mg; Wed, 25 Jul 2012 17:37:28 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Su4aW-0004K4-2k; Wed, 25 Jul 2012 17:37:28 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q6PGbR4w048070; Wed, 25 Jul 2012 17:37:27 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q6PGbRVT048069; Wed, 25 Jul 2012 17:37:27 +0100 (BST) (envelope-from mexas) Date: Wed, 25 Jul 2012 17:37:27 +0100 (BST) From: Anton Shterenlikht Message-Id: <201207251637.q6PGbRVT048069@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk, yanegomi@gmail.com In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: openssl upgrade, libcrypto, libssl confusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 16:37:30 -0000 On Wed, Jul 25, 2012 at 5:06 AM, Anton Shterenlikht wrote: > On Wed, Jul 25, 2012 at 12:30:29PM +0100, Anton Shterenlikht wrote: >> In /usr/src/UPDATING I see >> >> 20120712: >> The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring >> libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are >> configuration changes. Make sure to merge /etc/ssl/openssl.cnf. > > oops.. wait a minute, I'm still on > > # uname -a > FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 root@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 > # > > So this change shouldn't apply to me yet. > > Still there are *lots* of binaries, and libs > linked with /lib/libcrypto.so.6: > > Binaries that are linked with: /lib/libcrypto.so.6 ... > and so on, > > so is it really right that I can safely delete it? Some ldd/objdump and grep magic will give you the answer you need. check-old-libs only points out candidates for removal based on existence. Cheers, -Garrett That's scary. /usr/src/Makefile calles these "obsolete", which means these can be safely deleted: # check-old-libs - List obsolete libraries. # delete-old-libs - Delete obsolete libraries. >From what you are saying, and from what I observe, the algorithm used to determine whether the libs are obsolete cannot be trusted. For example, on another ia64 box, r238540, I get: # make -C /usr/src/ check-old-libs >>> Checking for old libraries /usr/lib/libftpio.so.8 /lib/libz.so.5 /lib/libutil.so.8 # None of these are obsolete. First, the base OS programs (not ports) depend on these libs: (I usually use sysutils/libchk to check this) Binaries that are linked with: /usr/lib/libftpio.so.8 /usr/sbin/sysinstall Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat Binaries that are linked with: /lib/libutil.so.8 /usr/sbin/sysinstall Second, at least for libftpio.so.8, there is no newer version. Finally, how come I have base OS binaries linked against old libs, if I always do the orthodox make buildworld, make buildkernel, make installkernel, make installworld? This just shouldn't happen, right? # ls -al /lib/libz.so.* -r--r--r-- 1 root wheel 151200 Jul 18 2010 /lib/libz.so.5 -r--r--r-- 1 root wheel 155264 Jul 18 11:25 /lib/libz.so.6 # ldd /usr/sbin/dtrace /usr/sbin/dtrace: libdtrace.so.2 => /lib/libdtrace.so.2 (0x20000000400b2000) libproc.so.2 => /usr/lib/libproc.so.2 (0x20000000401b2000) libctf.so.2 => /lib/libctf.so.2 (0x20000000401c6000) libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000401ee000) libz.so.5 => /lib/libz.so.5 (0x200000004022e000) libthr.so.3 => /lib/libthr.so.3 (0x2000000040264000) libc.so.7 => /lib/libc.so.7 (0x20000000402b2000) # ls -al /usr/sbin/dtrace -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace Any why is dtrace so old? Something is not right here... From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:00:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2456106566C; Wed, 25 Jul 2012 17:00:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9A02F8FC14; Wed, 25 Jul 2012 17:00:10 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6PH04VM072513; Wed, 25 Jul 2012 10:00:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6PH04cn072512; Wed, 25 Jul 2012 10:00:04 -0700 (PDT) (envelope-from sgk) Date: Wed, 25 Jul 2012 10:00:04 -0700 From: Steve Kargl To: Rainer Hurling Message-ID: <20120725170004.GA72338@troutmask.apl.washington.edu> References: <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50101EDE.6030509@gwdg.de> User-Agent: Mutt/1.4.2.3i Cc: David Schultz , freebsd-current@FreeBSD.org, Bruce Evans Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:00:14 -0000 On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote: > > Many thanks to you three for implementing expl() with r238722 and r238724. > > I am not a C programmer, but would like to ask if the following example > is correct and suituable as a minimalistic test of this new C99 function? > It's not clear to me what you mean by test. If expl() is not available in libm, then linking the code would fail. So, testing for the existence of expl() (for example, in a configure script) is as simple as #include long double func(long double x) { return (expl(x)); } > //----------------------------------- > #include > #include > > int main(void) > { > double c = 2.0; > long double d = 2.0; > > double e = exp(c); > long double f = expl(d); > > printf("exp(%f) is %.*f\n", c, 90, e); > printf("expl(%Lf) is %.*Lf\n", d, 90, f); If you mean testing that the output is correct, then asking for 90 digits is of little use. The following is sufficient (and my actually produce a digit or two more than is available in number) troutmask:fvwm:kargl[203] diff -u a.c.orig a.c --- a.c.orig 2012-07-25 09:38:31.000000000 -0700 +++ a.c 2012-07-25 09:40:36.000000000 -0700 @@ -1,5 +1,6 @@ #include #include +#include int main(void) { @@ -9,8 +10,8 @@ double e = exp(c); long double f = expl(d); - printf("exp(%f) is %.*f\n", c, 90, e); - printf("expl(%Lf) is %.*Lf\n", d, 90, f); + printf("exp(%f) is %.*f\n", c, DBL_DIG+2, e); + printf("expl(%Lf) is %.*Lf\n", d, LDBL_DIG+2, f); return 0; } > > return 0; > } > //----------------------------------- > > Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards > it gives me: > > exp(2.000000) is > 7.38905609893065040 > expl(2.000000) is > 7.38905609893065022739 > > Already the sixteenth position after decimal point differs. DBL_DIG is 15 on x86 hardware and LDBL_DIG is 18. You can expect at most 15 correct digits from exp(). > Please forgive me, if this is a really stupid approach for producing > some expl() output. If you actually want to test expl() to see if it is producing a decent result, you need a reference solution that contains a higher precision. I use mpfr with 256 bits of precision. troutmask:fvwm:kargl[213] ./testl -V 2 ULP = 0.3863 x = 2.000000000000000000e+00 libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 mpfr: 7.3890560989306502272304274605750078131803155705518\ 47324087127822522573796079054e+00 mpfr: 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0 The 1st 'mpfr:' line is produced after converting the results fof mpfr_exp() to long double. The 2nd 'mpfr:' line is produced by mpfr_printf() where the number of printed digits depends on the 256-bit precision. The last 'mpfr:' line is mpfr_printf()'s hex formatting. Unfortunately, it does not normalize the hex representation to start with '0x1.', which makes comparison somewhat difficult. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:04:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3CA1106564A; Wed, 25 Jul 2012 17:04:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 46C658FC08; Wed, 25 Jul 2012 17:04:39 +0000 (UTC) Received: by laai10 with SMTP id i10so875626laa.13 for ; Wed, 25 Jul 2012 10:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iIPpTgM53dVsU1XRMgqogbRXi+kPM12x5MGHDpK5wls=; b=cNoBek6XifF1Jo6x1A8OqPv8p5zp8QTTIa4qecUeF/e7jLUD2acOxD4Ycvct/To9mw ll9pSYcKb9JSG4HgZtjk9mCWRN+jgwKyhcsWPS/mENhfm/5+PZrXnPf1Xqr/CzDG5ppt o/gh1gEjnp4+NsnZ9D1l/8jRboBplwSWMtm025AQ7HsZKsVpib82bC9exfYmJsfQZbUs yQyuUDXaH7UrFco/0Zat7v3DoqZjP0hDlJGsxyaqQSLNsPfcYOYPfvOIoXKWe5lYAEkM OW7oXKMc9yWGXSMm2S/1Zex+Cp4eDAdl5U1ekr1SRsMRO4Kj3a2BDytA3yCRS+Cuz+X+ 0dcw== MIME-Version: 1.0 Received: by 10.152.48.6 with SMTP id h6mr26700129lan.30.1343235878178; Wed, 25 Jul 2012 10:04:38 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 25 Jul 2012 10:04:37 -0700 (PDT) In-Reply-To: References: <50064FB2.3020409@entel.upc.edu> Date: Wed, 25 Jul 2012 18:04:37 +0100 X-Google-Sender-Auth: W0_UYeMtWfBKbf98-QSoUpMNL40 Message-ID: From: Attilio Rao To: Antony Mawer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?Q?Gustau_P=C3=A9rez_i_Querol?= , freebsd-current@freebsd.org, Peter Holm , FreeBSD FS , George Neville-Neil Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:04:40 -0000 On 7/21/12, Antony Mawer wrote: > On Wed, Jul 18, 2012 at 6:45 PM, Attilio Rao wrote: >> 2012/7/18, Gustau P=C3=A9rez i Querol : >>> >>> Sorry fo the delay. >>> >>> About the ntfs support, I'd go with fuse and leave the most relevan= t >>> filesystems in kernel space. In fact filesystems not particulary >>> specific and not tied our kernel would go to userspace; thinks like >>> smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace (the >>> list is incomplete and I don't really know if all of them are yet >>> implemenent in userspace) in my opinion. That would make them easier to >>> maintain (changes in the kernel would only affect fuse, once fixed all >>> the userspace filesystem would work again). >>> >>> As a bonus, we would get many working fs based on fuse. In the >>> server side gluster is a desirable thing; in the desktop things like >>> gvfs (in the linux world gvfs is used not only by gnome but also by kde >>> or xfce) or truecrypt >> >> I'm really concerned also about ntfs and smbfs at the moment. It seems >> that there is also a FUSE smbfs port, but I never used it and I'm not >> sure about its state at all. > > From what I understand, Apple have done a considerable amount of work > on the FreeBSD-drived smbfs in the latest versions of OS X, based on > the existing smbfs in tree: I've also found that there are 2 FUSE modules for smbfs but pho@ and flo@ still haven't tested them. It may make sense to do so before we commit FUSE to -CURRENT. However, thee is a plan by a $COMPANY to work on the in-kernel version of smbfs and lock it before 10.0 is shipped. In the unlikely events this doesn't happen we will came up with a different plan (assuming we will adopt anyway the FUSE module, if it proves to work well). > http://www.opensource.apple.com/source/smb/smb-552.5/ > > I imagine things like the filesystem locking are probably somewhat > different, but in terms of updating smbfs itself to support newer > features it may be a good base (licensing permitting). smbfs at the > moment lacks in some areas such as DFS support, although I do not know > if the OS X version is any different there (given the consumer focus > of their OS, probably not). There was also a version spun off by > OpenSolaris: > > http://hub.opensolaris.org/bin/view/Project+smbfs/ > > which again was based on the FreeBSD + Apple versions. > > I also have a vested interest in NWFS continuing to work - only from a > legacy point of view where we still interoperate with a number of > Netware 6 servers through this. While those will likely eventually go > away, more than likely before we move to 10.x, if there is anyone > capable of working on it we could supply a test environment. > Unfortunately the actual locking of the NWFS and NCP modules is > outside my sphere of knowledge... If you have NCP, do you think you can try this netncp I never committed because lack of testing?: http://lists.freebsd.org/pipermail/freebsd-fs/2009-January/005617.html IIRC, Apple does a similar thing for netsmb (which suffers from a similar problem as netncp). Do you know if FUSE can support NWFS in any way? Starting providing stress-tests on the current codebase for NWFS/NetNCP (and report bugs found, preparing a list) could be a good way to start the locking effort. Interested developers then can look into such a list and provide necessary insight. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:17:16 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E0B9106564A; Wed, 25 Jul 2012 17:17:16 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id DC1428FC14; Wed, 25 Jul 2012 17:17:15 +0000 (UTC) Received: from p5dc3e9ce.dip.t-dialin.net ([93.195.233.206] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Su4Sg-0000Zn-Rj; Wed, 25 Jul 2012 18:29:23 +0200 Message-ID: <50101EDE.6030509@gwdg.de> Date: Wed, 25 Jul 2012 18:29:18 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> In-Reply-To: <20120710225801.GB58778@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: David Schultz , freebsd-current@FreeBSD.ORG, Bruce Evans Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:17:16 -0000 On 11.07.2012 00:58 (UTC+2), David Schultz wrote: > On Tue, Jul 10, 2012, Rainer Hurling wrote: >> On 10.07.2012 17:11 (UTC+2), David Schultz wrote: >>> On Tue, Jul 10, 2012, Rainer Hurling wrote: >>>> On 10.07.2012 16:02 (UTC+2), Warner Losh wrote: >>>>> >>>>> On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: >>>>>> As far as I understand from discussions on R mailing list >>>>>> (r-devel@r-project.org), they plan to reduce the emulation and/or >>>>>> workaround of long and complex math functions for FreeBSD and other >>>>>> systems with their next releases of R devel. So we could really need >>>>>> some >>>>>> progress with our C99 conform math functions ;-) >>>>> >>>>> Not having R would be a bit pain in my backside. That's one of the >>>>> practical considerations that I was talking about. It is very real, and >>>>> if I have to, I'll commit the #define junk I railed against to get it >>>>> back. Please, let's get some progress. I have some time to help. >>>> >>>> Yes, thank you Warner, that is also my problem. As I wrote some weeks >>>> ago (05/28/2012) when starting this thread, I am using FreeBSD as a >>>> scientific desktop because of its good scaling properties. For some >>>> years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and >>>> some more. >>>> >>>> If I would not be able to run upcoming versions of R on FreeBSD any >>>> more, that would be really, really hard :-( >>> >>> Do you have a list of the essential functions here? There are 17 long >>> double functions and some complex functions missing, but only a >>> handful of those are of general interest. The reason I ask is that if >>> R is just looking for a few missing functions that are already mostly >>> implemented, then the best solution is probably to finish that work. >>> But if it's expecting us to have something arcane like long double >>> Bessel functions of the first kind, then we need to pursue a workaround >>> in the short term. >>> >> >> That is, what I found by grepping the sources of a recent R development >> version: >> >> expl: src/nmath/pnchisq.c Many thanks to you three for implementing expl() with r238722 and r238724. I am not a C programmer, but would like to ask if the following example is correct and suituable as a minimalistic test of this new C99 function? //----------------------------------- #include #include int main(void) { double c = 2.0; long double d = 2.0; double e = exp(c); long double f = expl(d); printf("exp(%f) is %.*f\n", c, 90, e); printf("expl(%Lf) is %.*Lf\n", d, 90, f); return 0; } //----------------------------------- Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards it gives me: exp(2.000000) is 7.389056098930650406941822438966482877731323242187500000000000000000000000000000000000000000 expl(2.000000) is 7.389056098930650227397942675366948606097139418125152587890625000000000000000000000000000000 Already the sixteenth position after decimal point differs. Please forgive me, if this is a really stupid approach for producing some expl() output. uname -a: FreeBSD xxx.xxx.xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r238740: Tue Jul 24 18:08:13 CEST 2012 xxx@xxx.xxx.xxx:/usr/obj/usr/src/sys/XXX amd64 Rainer >> logl: src/nmath/dnbeta.c >> src/nmath/pnbeta.c > > Bruce has versions of these that could be committed with some cleanup. > It's a matter of sorting through about 1200 emails from him and 3 > source trees to find the most up-to-date patches, then cleaning them > up and testing and committing them. I have no time right now, but I > will do at least the first step as soon as I can, and try to get the > patches to someone willing to do the final few steps. > >> log10l: src/extra/trio/trio.c >> >> log1pl: src/nmath/pnbeta.c > > If Bruce doesn't already have implementations of these, they are easy > wrappers around logl() or some internal k_logl in Bruce's implementation. > >> powl: src/extra/trio/triostr.c >> src/extra/trio/trio.c >> src/main/format.c > > It's hard to do a good job on powl(), but the simple approach > (exp(log(x)*y)) plus a few special cases may suffice for many uses. > >> NEWS:l2044 >> The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are >> now required. > > We have had them forever. > >> NEWS:l3032 >> The C99 double complex type is now required. >> The C99 complex trigonometric functions (such as csin) are not >> currently required (FreeBSD lacks most of them): substitutes are >> used if they are missing. > > We have these (but not the inverse trig functions). > >> NEWS:l3277 >> Complex arithmetic (notably z^n for complex z and integer n) gave >> incorrect results since R 2.10.0 on platforms without C99 complex >> support. This and some lesser issues in trigonometric functions >> have been corrected. >> Such platforms were rare (we know of Cygwin and FreeBSD). >> However, because of new compiler optimizations in the way complex >> arguments are handled, the same code was selected on x86_64 Linux >> with gcc 4.5.x at the default -O2 optimization (but not at -O). > > Not sure if this is relevant. > >> BTW: There seems to be a discrepancy about missing functions listed in >> http://wiki.freebsd.org/MissingMathStuff and in >> http://svnweb.freebsd.org/base/head/lib/msun/src/math.h?r1=227472&r2=236148&pathrev=236148. >> So the wiki is a bit outdated now? > > My list: > > REAL FUNCTIONS (17): > > long double log2l(long double); > long double logl(long double); > long double log1pl(long double); > long double acoshl(long double); > long double asinhl(long double); > long double atanhl(long double); > long double log10l(long double); > > long double expl(long double); > long double expm1l(long double); > long double coshl(long double); > long double sinhl(long double); > long double tanhl(long double); > long double erfcl(long double); > long double erfl(long double); > > long double powl(long double, long double); > > long double lgammal(long double); > long double tgammal(long double); > > > COMPLEX FUNCTIONS (37): > > long double complex cexpl(long double complex); > long double complex ccosl(long double complex); > long double complex ccoshl(long double complex); > long double complex csinl(long double complex); > long double complex csinhl(long double complex); > long double complex ctanl(long double complex); > long double complex ctanhl(long double complex); > > > float complex cacosf(float complex); > float complex cacoshf(float complex); > double complex cacos(double complex); > double complex cacosh(double complex); > long double complex cacosl(long double complex); > long double complex cacoshl(long double complex); > > float complex casinf(float complex); > float complex casinhf(float complex); > double complex casin(double complex); > double complex casinh(double complex); > long double complex casinl(long double complex); > long double complex casinhl(long double complex); > > float complex catanf(float complex); > float complex catanhf(float complex); > double complex catan(double complex); > double complex catanh(double complex); > long double complex catanl(long double complex); > long double complex catanhl(long double complex); > > float complex clogf(float complex); > double complex clog(double complex); > long double complex clogl(long double complex); > > float complex cpowf(float complex, float complex); > double complex cpow(double complex, double complex); > long double complex cpowl(long double complex, long double complex); > From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:27:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0ED106566B; Wed, 25 Jul 2012 17:27:51 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id EF8388FC0A; Wed, 25 Jul 2012 17:27:50 +0000 (UTC) Received: from [128.206.184.213] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q6PHRhQe043153; Wed, 25 Jul 2012 12:27:43 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <50102C8F.2080901@missouri.edu> Date: Wed, 25 Jul 2012 12:27:43 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rainer Hurling References: <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> In-Reply-To: <50101EDE.6030509@gwdg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Schultz , freebsd-current@freebsd.org, Bruce Evans , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:27:51 -0000 On 07/25/12 11:29, Rainer Hurling wrote: > Many thanks to you three for implementing expl() with r238722 and r238724. > > I am not a C programmer, but would like to ask if the following example > is correct and suituable as a minimalistic test of this new C99 function? > > > //----------------------------------- > #include > #include > > int main(void) > { > double c = 2.0; > long double d = 2.0; > > double e = exp(c); > long double f = expl(d); > > printf("exp(%f) is %.*f\n", c, 90, e); > printf("expl(%Lf) is %.*Lf\n", d, 90, f); > > return 0; > } > //----------------------------------- > > > Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards > it gives me: > > exp(2.000000) is > 7.389056098930650406941822438966482877731323242187500000000000000000000000000000000000000000 > > expl(2.000000) is > 7.389056098930650227397942675366948606097139418125152587890625000000000000000000000000000000 > Just as a point of comparison, here is the answer computed using Mathematica: N[Exp[2], 50] 7.3890560989306502272304274605750078131803155705518 As you can see, the expl solution has only a few digits more accuracy that exp. From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:31:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 604DA1065675; Wed, 25 Jul 2012 17:31:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 374E28FC15; Wed, 25 Jul 2012 17:31:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6PHVlFF072836; Wed, 25 Jul 2012 10:31:47 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6PHVlDX072835; Wed, 25 Jul 2012 10:31:47 -0700 (PDT) (envelope-from sgk) Date: Wed, 25 Jul 2012 10:31:47 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20120725173147.GA72824@troutmask.apl.washington.edu> References: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> <50102C8F.2080901@missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50102C8F.2080901@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: David Schultz , Bruce Evans , freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:31:48 -0000 On Wed, Jul 25, 2012 at 12:27:43PM -0500, Stephen Montgomery-Smith wrote: > On 07/25/12 11:29, Rainer Hurling wrote: > > >Many thanks to you three for implementing expl() with r238722 and r238724. > > > >I am not a C programmer, but would like to ask if the following example > >is correct and suituable as a minimalistic test of this new C99 function? > > > > (program deleted) > > > >Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards > >it gives me: > > > >exp(2.000000) is > >7.3890560989306504069 > > > >expl(2.000000) is > >7.38905609893065022739794 > > > > Just as a point of comparison, here is the answer computed using > Mathematica: > > N[Exp[2], 50] > 7.3890560989306502272304274605750078131803155705518 > > As you can see, the expl solution has only a few digits more accuracy > that exp. Unless you are using sparc64 hardware. flame:kargl[204] ./testl -V 2 ULP = 0.2670 for x = 2.000000000000000000000000000000000e+00 mpfr exp: 7.389056098930650227230427460575008e+00 libm exp: 7.389056098930650227230427460575008e+00 -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:33:11 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0CDB1065674; Wed, 25 Jul 2012 17:33:11 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 294388FC15; Wed, 25 Jul 2012 17:33:11 +0000 (UTC) Received: from p5dc3e9ce.dip.t-dialin.net ([93.195.233.206] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Su5SO-0002xV-2E; Wed, 25 Jul 2012 19:33:08 +0200 Message-ID: <50102DD3.6010700@gwdg.de> Date: Wed, 25 Jul 2012 19:33:07 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> <20120725170004.GA72338@troutmask.apl.washington.edu> In-Reply-To: <20120725170004.GA72338@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: David Schultz , freebsd-current@FreeBSD.org, Bruce Evans Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:33:11 -0000 On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote: > On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote: >> >> Many thanks to you three for implementing expl() with r238722 and r238724. >> >> I am not a C programmer, but would like to ask if the following example >> is correct and suituable as a minimalistic test of this new C99 function? >> > > It's not clear to me what you mean by test. If expl() is > not available in libm, then linking the code would fail. > So, testing for the existence of expl() (for example, > in a configure script) is as simple as Sorry for not being clear enough. I didn't mean testing for the existence, but for some comparable output between exp() and expl(), on a system with expl() available in libm. > #include > long double > func(long double x) > { > return (expl(x)); > } > >> //----------------------------------- >> #include >> #include >> >> int main(void) >> { >> double c = 2.0; >> long double d = 2.0; >> >> double e = exp(c); >> long double f = expl(d); >> >> printf("exp(%f) is %.*f\n", c, 90, e); >> printf("expl(%Lf) is %.*Lf\n", d, 90, f); > > If you mean testing that the output is correct, then > asking for 90 digits is of little use. The following > is sufficient (and my actually produce a digit or two > more than is available in number) Ok, I understand. I printed the 90 digits to be able to take a look at the decimal places, I did not expect to get valid digits in this area. > troutmask:fvwm:kargl[203] diff -u a.c.orig a.c > --- a.c.orig 2012-07-25 09:38:31.000000000 -0700 > +++ a.c 2012-07-25 09:40:36.000000000 -0700 > @@ -1,5 +1,6 @@ > #include > #include > +#include > > int main(void) > { > @@ -9,8 +10,8 @@ > double e = exp(c); > long double f = expl(d); > > - printf("exp(%f) is %.*f\n", c, 90, e); > - printf("expl(%Lf) is %.*Lf\n", d, 90, f); > + printf("exp(%f) is %.*f\n", c, DBL_DIG+2, e); > + printf("expl(%Lf) is %.*Lf\n", d, LDBL_DIG+2, f); > > return 0; > } Thanks, I was not aware of DBL_DIG and LDBL_DIG. >> return 0; >> } >> //----------------------------------- >> >> Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards >> it gives me: >> >> exp(2.000000) is >> 7.38905609893065040 >> expl(2.000000) is >> 7.38905609893065022739 >> >> Already the sixteenth position after decimal point differs. > > DBL_DIG is 15 on x86 hardware and LDBL_DIG is 18. You can > expect at most 15 correct digits from exp(). > >> Please forgive me, if this is a really stupid approach for producing >> some expl() output. > > If you actually want to test expl() to see if it is producing > a decent result, you need a reference solution that contains > a higher precision. I use mpfr with 256 bits of precision. > > troutmask:fvwm:kargl[213] ./testl -V 2 > ULP = 0.3863 > x = 2.000000000000000000e+00 > libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 > mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 > mpfr: 7.3890560989306502272304274605750078131803155705518\ > 47324087127822522573796079054e+00 > mpfr: 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0 > > The 1st 'mpfr:' line is produced after converting the results > fof mpfr_exp() to long double. The 2nd 'mpfr:' line is > produced by mpfr_printf() where the number of printed > digits depends on the 256-bit precision. The last 'mpfr:' > line is mpfr_printf()'s hex formatting. Unfortunately, it > does not normalize the hex representation to start with > '0x1.', which makes comparison somewhat difficult. > Many thanks also for this mpfr example. This helps me to understand a little bit more what is going here. So on amd64 even the expl() result is far from what mpfr provides. From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:37:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EDD6106564A; Wed, 25 Jul 2012 17:37:57 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5478FC12; Wed, 25 Jul 2012 17:37:57 +0000 (UTC) Received: from [128.206.184.213] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q6PHbube043828; Wed, 25 Jul 2012 12:37:56 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <50102EF4.2080601@missouri.edu> Date: Wed, 25 Jul 2012 12:37:56 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> <50102C8F.2080901@missouri.edu> <20120725173147.GA72824@troutmask.apl.washington.edu> In-Reply-To: <20120725173147.GA72824@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Schultz , Bruce Evans , freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:37:58 -0000 On 07/25/12 12:31, Steve Kargl wrote: > On Wed, Jul 25, 2012 at 12:27:43PM -0500, Stephen Montgomery-Smith wrote: >> On 07/25/12 11:29, Rainer Hurling wrote: >> >>> Many thanks to you three for implementing expl() with r238722 and r238724. >>> >>> I am not a C programmer, but would like to ask if the following example >>> is correct and suituable as a minimalistic test of this new C99 function? >>> >>> > > (program deleted) > >>> >>> Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards >>> it gives me: >>> >>> exp(2.000000) is >>> 7.3890560989306504069 >>> >>> expl(2.000000) is >>> 7.38905609893065022739794 >>> >> >> Just as a point of comparison, here is the answer computed using >> Mathematica: >> >> N[Exp[2], 50] >> 7.3890560989306502272304274605750078131803155705518 >> >> As you can see, the expl solution has only a few digits more accuracy >> that exp. > > Unless you are using sparc64 hardware. > > flame:kargl[204] ./testl -V 2 > ULP = 0.2670 for x = 2.000000000000000000000000000000000e+00 > mpfr exp: 7.389056098930650227230427460575008e+00 > libm exp: 7.389056098930650227230427460575008e+00 Yes. It would be nice if long on the Intel was as long as the sparc64. From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:53:28 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D7631065670; Wed, 25 Jul 2012 17:53:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBBF8FC1C; Wed, 25 Jul 2012 17:53:28 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6PHrRxa073075; Wed, 25 Jul 2012 10:53:27 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6PHrRw4073074; Wed, 25 Jul 2012 10:53:27 -0700 (PDT) (envelope-from sgk) Date: Wed, 25 Jul 2012 10:53:27 -0700 From: Steve Kargl To: Rainer Hurling Message-ID: <20120725175327.GA72991@troutmask.apl.washington.edu> References: <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> <20120725170004.GA72338@troutmask.apl.washington.edu> <50102DD3.6010700@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50102DD3.6010700@gwdg.de> User-Agent: Mutt/1.4.2.3i Cc: David Schultz , freebsd-current@FreeBSD.org, Bruce Evans Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:53:28 -0000 On Wed, Jul 25, 2012 at 07:33:07PM +0200, Rainer Hurling wrote: > On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote: > > > >If you actually want to test expl() to see if it is producing > >a decent result, you need a reference solution that contains > >a higher precision. I use mpfr with 256 bits of precision. > > > >troutmask:fvwm:kargl[213] ./testl -V 2 > >ULP = 0.3863 > > x = 2.000000000000000000e+00 > >libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 > >mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 > >mpfr: 7.3890560989306502272304274605750078131803155705518\ > > 47324087127822522573796079054e+00 > >mpfr: > >0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0 > > > >The 1st 'mpfr:' line is produced after converting the results > >fof mpfr_exp() to long double. The 2nd 'mpfr:' line is > >produced by mpfr_printf() where the number of printed > >digits depends on the 256-bit precision. The last 'mpfr:' > >line is mpfr_printf()'s hex formatting. Unfortunately, it > >does not normalize the hex representation to start with > >'0x1.', which makes comparison somewhat difficult. > > > > Many thanks also for this mpfr example. This helps me to understand a > little bit more what is going here. So on amd64 even the expl() result > is far from what mpfr provides. Of course!. MPFR is a multiple precision library. One specifies the precision, and mpfr returns a value with that precision. #include int main(void) { int i, j[5] = {24, 53, 64, 113, 256}; mpfr_t x, f; for (i = 0; i < 5; i++) { /* Set working precision to j[i]. */ mpfr_inits2(j[i], x, f, MPFR_RNDN); mpfr_set_ui(x, 2, MPFR_RNDN); mpfr_exp(f, x, MPFR_RNDN); mpfr_printf("exp(%Re) = %Re\n", x, f); mpfr_clears(x, f, NULL); } } troutmask:fvwm:kargl[222] cc -o z -I/usr/local/include a.c -L/usr/local/lib\ -lmpfr -lgmp troutmask:fvwm:kargl[223] ./z exp(2e+00) = 7.38905621e+00 exp(2e+00) = 7.3890560989306504e+00 exp(2e+00) = 7.3890560989306502274e+00 exp(2e+00) = 7.38905609893065022723042746057500802e+00 exp(2e+00) = 7.38905609893065022723042746057500781\ 3180315570551847324087127822522573796079054e+00 -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 19:46:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BC59106564A; Wed, 25 Jul 2012 19:46:41 +0000 (UTC) (envelope-from yanegomi@gmail.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 E4C818FC08; Wed, 25 Jul 2012 19:46:40 +0000 (UTC) Received: by ggnm2 with SMTP id m2so1369831ggn.13 for ; Wed, 25 Jul 2012 12:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wf7PRUOHt/8ame6wHLMaNPcvriEO8/ssoQq6dLt0ko8=; b=Iekdb2Sk1iaLKaBGTqQ94yEeFjwwyQROs3+QaDsc+DmetIc7LObh3t5gjliydBp5+h Go60BRjEidRS7uFiY+ofA7Te5ZeYLQ2KAgsOkPjMQKC9IyuMBnFEelny7aOUjIcJTFIk 0Q7SUUOotnQDd0frqZv9xOIq54yGDWyfE3eOzBFS8NMZ1ApgJ7y9qoDLQQcc/eL4y5AJ Bdm846wLvmSt4M0xlkoBB16mX3w6q9IILRkyQJwX8WeNAitc3Wufm21CPfkCBTRd2Tdw sTM4AgihVx1Z/V7SRdCLDCoD3jo7PcGJPXq75he5oKmdJLb1fE4xG7gWTqbCdrraFkOw 5qug== MIME-Version: 1.0 Received: by 10.60.24.7 with SMTP id q7mr37413149oef.54.1343245600047; Wed, 25 Jul 2012 12:46:40 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Wed, 25 Jul 2012 12:46:39 -0700 (PDT) In-Reply-To: References: <50064FB2.3020409@entel.upc.edu> Date: Wed, 25 Jul 2012 12:46:39 -0700 Message-ID: From: Garrett Cooper To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD FS , =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= , Peter Holm , Antony Mawer , George Neville-Neil , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 19:46:41 -0000 On Wed, Jul 25, 2012 at 10:04 AM, Attilio Rao wrote: > On 7/21/12, Antony Mawer wrote: >> On Wed, Jul 18, 2012 at 6:45 PM, Attilio Rao wrote= : >>> 2012/7/18, Gustau P=E9rez i Querol : >>>> >>>> Sorry fo the delay. >>>> >>>> About the ntfs support, I'd go with fuse and leave the most releva= nt >>>> filesystems in kernel space. In fact filesystems not particulary >>>> specific and not tied our kernel would go to userspace; thinks like >>>> smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace (the >>>> list is incomplete and I don't really know if all of them are yet >>>> implemenent in userspace) in my opinion. That would make them easier t= o >>>> maintain (changes in the kernel would only affect fuse, once fixed all >>>> the userspace filesystem would work again). >>>> >>>> As a bonus, we would get many working fs based on fuse. In the >>>> server side gluster is a desirable thing; in the desktop things like >>>> gvfs (in the linux world gvfs is used not only by gnome but also by kd= e >>>> or xfce) or truecrypt >>> >>> I'm really concerned also about ntfs and smbfs at the moment. It seems >>> that there is also a FUSE smbfs port, but I never used it and I'm not >>> sure about its state at all. >> >> From what I understand, Apple have done a considerable amount of work >> on the FreeBSD-drived smbfs in the latest versions of OS X, based on >> the existing smbfs in tree: > > I've also found that there are 2 FUSE modules for smbfs but pho@ and > flo@ still haven't tested them. It may make sense to do so before we > commit FUSE to -CURRENT. However, thee is a plan by a $COMPANY to work > on the in-kernel version of smbfs and lock it before 10.0 is shipped. > In the unlikely events this doesn't happen we will came up with a > different plan (assuming we will adopt anyway the FUSE module, if it > proves to work well). > >> http://www.opensource.apple.com/source/smb/smb-552.5/ >> >> I imagine things like the filesystem locking are probably somewhat >> different, but in terms of updating smbfs itself to support newer >> features it may be a good base (licensing permitting). smbfs at the >> moment lacks in some areas such as DFS support, although I do not know >> if the OS X version is any different there (given the consumer focus >> of their OS, probably not). There was also a version spun off by >> OpenSolaris: >> >> http://hub.opensolaris.org/bin/view/Project+smbfs/ >> >> which again was based on the FreeBSD + Apple versions. >> >> I also have a vested interest in NWFS continuing to work - only from a >> legacy point of view where we still interoperate with a number of >> Netware 6 servers through this. While those will likely eventually go >> away, more than likely before we move to 10.x, if there is anyone >> capable of working on it we could supply a test environment. >> Unfortunately the actual locking of the NWFS and NCP modules is >> outside my sphere of knowledge... > > If you have NCP, do you think you can try this netncp I never > committed because lack of testing?: > http://lists.freebsd.org/pipermail/freebsd-fs/2009-January/005617.html > > IIRC, Apple does a similar thing for netsmb (which suffers from a > similar problem as netncp). > Do you know if FUSE can support NWFS in any way? > > Starting providing stress-tests on the current codebase for > NWFS/NetNCP (and report bugs found, preparing a list) could be a good > way to start the locking effort. Interested developers then can look > into such a list and provide necessary insight. 1. The in-kernel smbfs is so far behind the SMB spec that I'm not sure that it's worthwhile maintaining it. It's SMB1.x based, which is pre-Vista; SMB2.1 has been out for a while and 3.0 is rolling around the corner in the next couple years (about the same time Windows XP is going to be EOS). 2. According to reports I have from internal sources, the Apple implementation is suboptimal from a performance perspective, in part because the Apple SMB client doesn't coalesce requests. I concur on the poor performance based on personal experience because NFS beats SMB hands down on OSX (comes close to saturating the physical media with NFS, and putters along at a fraction of the link speed with CIFS on my Macbook Pro with Lion), whereas running a Windows 7 client against samba36 yields performance I would expect (saturates gigabit). YMMV, -Garrett 1. http://windows.microsoft.com/en-us/windows/products/lifecycle From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 01:37:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5B38106566B for ; Thu, 26 Jul 2012 01:37:48 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 665928FC0C for ; Thu, 26 Jul 2012 01:37:48 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6Q1ahhc003675; Wed, 25 Jul 2012 19:37:15 -0600 Date: Thu, 26 Jul 2012 08:39:02 +0700 From: Erich Dollansky To: Hans Petter Selasky Message-ID: <20120726083902.440a7a03@AMD620.ovitrap.com> In-Reply-To: <201207251613.04300.hselasky@c2i.net> References: <20120725195408.732d59b6@AMD620.ovitrap.com> <201207251613.04300.hselasky@c2i.net> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: machine freezes when using USB disk and X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:37:48 -0000 Hi, On Wed, 25 Jul 2012 16:13:04 +0200 Hans Petter Selasky wrote: > On Wednesday 25 July 2012 14:54:08 Erich Dollansky wrote: > > > > I have strange problem which I can reproduce. > > > > When I copy some 100GB to a disk via USB when X is not active, it > > works without any problems. > > > > When I copy some 100GB to a disk via USB when X is running, the > > machine freezes. It does not react to keyboard, mouse and network > > actions. > > > > When I use only X on the same machine and do the same copy via > > network, the machine behaves as expected. > > > > What could I do to locate the problem? > > > > Erich > > > > PS > > > > uname says: > > > > FreeBSD AMD620.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #38: > > Sat Jul 21 06:58:49 WIT 2012 > > You might want to check what interrupts are shared. Might be an IRQ > problem. it does not look like. As it was working before since 8.0 without problems, I cannot imagine that this is the real problem even if they would be shared. I do not expect a solution for this. It is more or less a hint for developers working in the affected areas that there might be something wrong. Erich From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 01:52:32 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D103106566B; Thu, 26 Jul 2012 01:52:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id E60588FC08; Thu, 26 Jul 2012 01:52:31 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6Q1qLrt029016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 11:52:23 +1000 Date: Thu, 26 Jul 2012 11:52:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rainer Hurling In-Reply-To: <50102DD3.6010700@gwdg.de> Message-ID: <20120726111106.W1093@besplex.bde.org> References: <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> <20120725170004.GA72338@troutmask.apl.washington.edu> <50102DD3.6010700@gwdg.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 26 Jul 2012 02:18:20 +0000 Cc: David Schultz , freebsd-current@FreeBSD.org, Bruce Evans , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:52:32 -0000 On Wed, 25 Jul 2012, Rainer Hurling wrote: > On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote: >> On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote: >>> >>> Many thanks to you three for implementing expl() with r238722 and r238724. >>> >>> I am not a C programmer, but would like to ask if the following example >>> is correct and suituable as a minimalistic test of this new C99 function? >> >> It's not clear to me what you mean by test. If expl() is >> not available in libm, then linking the code would fail. >> So, testing for the existence of expl() (for example, >> in a configure script) is as simple as > > Sorry for not being clear enough. I didn't mean testing for the existence, > but for some comparable output between exp() and expl(), on a system with > expl() available in libm. This is basically what I do to test exp() (with a few billion cases automatically generated and compared). It is not sufficient for checking expl(), except for consistency. (It is assumed that expl() is reasonably accurate. If it is in fact less accurate than exp(), this tends to show up in the comparisons.) >> #include >> long double >> func(long double x) >> { >> return (expl(x)); >> } >> >>> //----------------------------------- >>> #include >>> #include >>> >>> int main(void) >>> { >>> double c = 2.0; >>> long double d = 2.0; >>> >>> double e = exp(c); >>> long double f = expl(d); >>> >>> printf("exp(%f) is %.*f\n", c, 90, e); >>> printf("expl(%Lf) is %.*Lf\n", d, 90, f); >> >> If you mean testing that the output is correct, then >> asking for 90 digits is of little use. The following >> is sufficient (and my actually produce a digit or two >> more than is available in number) > > Ok, I understand. I printed the 90 digits to be able to take a look at the > decimal places, I did not expect to get valid digits in this area. Use binary format (%a) for manual comparison. Don't print any more bits than the format has. This is DBL_MANT_DIG (53) for doubles and LDLBL_MANT_DIG (64 on x86) for long doubles. %a format is in nybbles and tends to group the bits into nybbles badly. See below on reducing problems from this. Decimal format has to print about 3 more digits than are really meaningful, to allow recovering the original value uniquely. For manual comparison, you need to print these extra digits and manually round or ignore them as appropriate. The correct number of extra digits is hard to determine. For the "any", type, it is DECIMAL_DIG (21) on x86. The corresponding number of normally-accurate decimal digits for long doubles is given by LDBL_DIG (18). For floats and doubles, this corresponds to FLT_DIG (6) and DBL_DIG (15). Unfortunately, doesn't define anything corresponding to DECIMAL_DIG for the smaller types. 21 is a lot of digits and noise digits take a long time to determine and ignore (its worse on sparc64 where DECIMAL_DIG is 36). I usually add 2 extra digits to the number of normally-accurate digits. This is sloppy. 3 is needed in some cases, depending on MANT_DIG and the bits in log(2) and/or log(10). >> troutmask:fvwm:kargl[203] diff -u a.c.orig a.c >> --- a.c.orig 2012-07-25 09:38:31.000000000 -0700 >> +++ a.c 2012-07-25 09:40:36.000000000 -0700 >> @@ -1,5 +1,6 @@ >> #include >> #include >> +#include >> >> int main(void) >> { >> @@ -9,8 +10,8 @@ >> double e = exp(c); >> long double f = expl(d); >> >> - printf("exp(%f) is %.*f\n", c, 90, e); >> - printf("expl(%Lf) is %.*Lf\n", d, 90, f); >> + printf("exp(%f) is %.*f\n", c, DBL_DIG+2, e); >> + printf("expl(%Lf) is %.*Lf\n", d, LDBL_DIG+2, f); >> >> return 0; >> } > > Thanks, I was not aware of DBL_DIG and LDBL_DIG. Steve is sloppy and adds 2 also :-). For long doubles, it is clear that 3 are strictly needed, since DECIMAL_DIG is 3 more. For most long double functions on i386, you need to switch the rounding precision to 64 bits around calls to them, and also to do any operations on the results except printing them. expl() is one of the few large functions that does the switch internally. So the above should work (since it only prints), but (expl(d) + 0) should round to the default 53-bit precision and this give the same result as exp(d). >> If you actually want to test expl() to see if it is producing >> a decent result, you need a reference solution that contains >> a higher precision. I use mpfr with 256 bits of precision. >> >> troutmask:fvwm:kargl[213] ./testl -V 2 >> ULP = 0.3863 >> x = 2.000000000000000000e+00 >> libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 >> mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 >> mpfr: 7.3890560989306502272304274605750078131803155705518\ >> 47324087127822522573796079054e+00 >> mpfr: >> 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0 >> >> The 1st 'mpfr:' line is produced after converting the results >> fof mpfr_exp() to long double. The 2nd 'mpfr:' line is >> produced by mpfr_printf() where the number of printed >> digits depends on the 256-bit precision. The last 'mpfr:' >> line is mpfr_printf()'s hex formatting. Unfortunately, it >> does not normalize the hex representation to start with >> '0x1.', which makes comparison somewhat difficult. Starting with 0x1 is only a good (just OK) normalization when the number of binary digits is 1 mod the number of bits in a nybble. So it is good for doubles but bad for long doubles on x86 and 256-bit format. To reduce this problem, promote to a common type and print all the bits of that. (I don't know how to promote to 256 bits to match mpfr). Even when the first hex nybble is not normalized, the bits of similar results line up unless the results are not actually similar or in rare half-way cases. Another method that I like to use with better binary formats than %a produced by my library is to print values twice, first rounded to their nominal number of binary bits (53 for doubles) and then with 8 extra bits (8 is a multiple of 4 to keep the nybbles lined up). Sometimes you have extra precision and need to see what it is. i386 has 11 bits of extra precision for long doubles internally, in all cases provided its rounding precision is switched to 64 bits and in some other cases. Actually, I would use 12 extra bits to compare 64-bit values with 53-bit ones, since one extra nybble provides complete info without much expansion. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 02:19:37 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA13E106566B; Thu, 26 Jul 2012 02:19:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 58FE58FC1E; Thu, 26 Jul 2012 02:19:37 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6Q2JRBj005609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 12:19:28 +1000 Date: Thu, 26 Jul 2012 12:19:27 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stephen Montgomery-Smith In-Reply-To: <50102EF4.2080601@missouri.edu> Message-ID: <20120726121848.I1093@besplex.bde.org> References: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> <50102C8F.2080901@missouri.edu> <20120725173147.GA72824@troutmask.apl.washington.edu> <50102EF4.2080601@missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 26 Jul 2012 02:39:47 +0000 Cc: freebsd-current@FreeBSD.org, David Schultz , Bruce Evans , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 02:19:38 -0000 On Wed, 25 Jul 2012, Stephen Montgomery-Smith wrote: > On 07/25/12 12:31, Steve Kargl wrote: >> On Wed, Jul 25, 2012 at 12:27:43PM -0500, Stephen Montgomery-Smith wrote: >>> Just as a point of comparison, here is the answer computed using >>> Mathematica: >>> >>> N[Exp[2], 50] >>> 7.3890560989306502272304274605750078131803155705518 >>> >>> As you can see, the expl solution has only a few digits more accuracy >>> that exp. >> >> Unless you are using sparc64 hardware. >> >> flame:kargl[204] ./testl -V 2 >> ULP = 0.2670 for x = 2.000000000000000000000000000000000e+00 >> mpfr exp: 7.389056098930650227230427460575008e+00 >> libm exp: 7.389056098930650227230427460575008e+00 > Yes. It would be nice if long on the Intel was as long as the sparc64. You want it to be as slow as sparc64? (About 300 times slower, after scaling the CPU clock rates. Doubles on sparc64 are less than 2 times slower.) I forgot to mention in a previous reply is that expl has only a few more decimal digits of accuracy than exp because the extra precision on x86 wasn't designed to give much more accuracy. It was designed to give more chance of full double precision accuracy in naive code. It was designed in ~1980 when bits were expensive and the extra 11 provided by the 8087 were considered the best tradeoff between cost and accuracy. They only previde 2-3 extra decimal digits of accuracy. They are best thought of as guard bits. Floating point uses 1 or 2 guard bits internally. 11 extends that significantly and externalizes it, but is far from doubling the number of bits. Their use to provide extra precision was mostly defeated in C by bad C bindings and implementations. This was consolidated by my not using the extra bits for the default rounding precision in FreeBSD. This has been further consolidated by SSE not supporting extended precision. Now the naive code that uses doubles never gets the extra precision on amd64. Mixing of long doubles with doubles is much slower with SSE+i387 than with i387, since the long doubles are handled in different registers and must be translated with SSE+i387, while with i387, using long doubles is almost free (it actually has a negative cost in non-naive code since it allows avoiding extra precision in software). Thus SSE also inhibits using the extra precision intentionally. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 15:06:14 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5BFB106564A; Thu, 26 Jul 2012 15:06:14 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 17D778FC12; Thu, 26 Jul 2012 15:06:14 +0000 (UTC) Received: from p5dc3ea61.dip.t-dialin.net ([93.195.234.97] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SuPdY-0002c7-NQ; Thu, 26 Jul 2012 17:06:00 +0200 Message-ID: <50115CD8.70705@gwdg.de> Date: Thu, 26 Jul 2012 17:06:00 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> <20120725170004.GA72338@troutmask.apl.washington.edu> <50102DD3.6010700@gwdg.de> <20120726111106.W1093@besplex.bde.org> In-Reply-To: <20120726111106.W1093@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: David Schultz , freebsd-current@FreeBSD.org, Bruce Evans , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 15:06:14 -0000 Am 26.07.2012 03:52 (UTC+1) schrieb Bruce Evans: > On Wed, 25 Jul 2012, Rainer Hurling wrote: > >> On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote: >>> On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote: >>>> >>>> Many thanks to you three for implementing expl() with r238722 and >>>> r238724. >>>> >>>> I am not a C programmer, but would like to ask if the following example >>>> is correct and suituable as a minimalistic test of this new C99 >>>> function? >>> >>> It's not clear to me what you mean by test. If expl() is >>> not available in libm, then linking the code would fail. >>> So, testing for the existence of expl() (for example, >>> in a configure script) is as simple as >> >> Sorry for not being clear enough. I didn't mean testing for the >> existence, but for some comparable output between exp() and expl(), on >> a system with expl() available in libm. > > This is basically what I do to test exp() (with a few billion cases > automatically generated and compared). It is not sufficient for > checking expl(), except for consistency. (It is assumed that expl() > is reasonably accurate. If it is in fact less accurate than exp(), > this tends to show up in the comparisons.) Ahh ok, I think I understand it better now. >>> #include >>> long double >>> func(long double x) >>> { >>> return (expl(x)); >>> } >>> >>>> //----------------------------------- >>>> #include >>>> #include >>>> >>>> int main(void) >>>> { >>>> double c = 2.0; >>>> long double d = 2.0; >>>> >>>> double e = exp(c); >>>> long double f = expl(d); >>>> >>>> printf("exp(%f) is %.*f\n", c, 90, e); >>>> printf("expl(%Lf) is %.*Lf\n", d, 90, f); >>> >>> If you mean testing that the output is correct, then >>> asking for 90 digits is of little use. The following >>> is sufficient (and my actually produce a digit or two >>> more than is available in number) >> >> Ok, I understand. I printed the 90 digits to be able to take a look at >> the decimal places, I did not expect to get valid digits in this area. > > Use binary format (%a) for manual comparison. Don't print any more > bits than the format has. This is DBL_MANT_DIG (53) for doubles and > LDLBL_MANT_DIG (64 on x86) for long doubles. %a format is in nybbles > and tends to group the bits into nybbles badly. See below on reducing > problems from this. Decimal format has to print about 3 more digits > than are really meaningful, to allow recovering the original value > uniquely. For manual comparison, you need to print these extra digits > and manually round or ignore them as appropriate. The correct number > of extra digits is hard to determine. For the "any", type, it is > DECIMAL_DIG (21) on x86. The corresponding number of normally-accurate > decimal digits for long doubles is given by LDBL_DIG (18). For > floats and doubles, this corresponds to FLT_DIG (6) and DBL_DIG (15). > Unfortunately, doesn't define anything corresponding to > DECIMAL_DIG for the smaller types. 21 is a lot of digits and noise > digits take a long time to determine and ignore (its worse on sparc64 > where DECIMAL_DIG is 36). I usually add 2 extra digits to the number > of normally-accurate digits. This is sloppy. 3 is needed in some > cases, depending on MANT_DIG and the bits in log(2) and/or log(10). I printed more bits (digits) than the format provides, because I wanted to see if and when what the new function would do in this 'outside' area. Of course you are right that this has nothing to do with more precision and these digits may not be used in subsequent calculations. But this really was not my intention here (only curiosity). >>> troutmask:fvwm:kargl[203] diff -u a.c.orig a.c >>> --- a.c.orig 2012-07-25 09:38:31.000000000 -0700 >>> +++ a.c 2012-07-25 09:40:36.000000000 -0700 >>> @@ -1,5 +1,6 @@ >>> #include >>> #include >>> +#include >>> >>> int main(void) >>> { >>> @@ -9,8 +10,8 @@ >>> double e = exp(c); >>> long double f = expl(d); >>> >>> - printf("exp(%f) is %.*f\n", c, 90, e); >>> - printf("expl(%Lf) is %.*Lf\n", d, 90, f); >>> + printf("exp(%f) is %.*f\n", c, DBL_DIG+2, e); >>> + printf("expl(%Lf) is %.*Lf\n", d, LDBL_DIG+2, f); >>> >>> return 0; >>> } >> >> Thanks, I was not aware of DBL_DIG and LDBL_DIG. > > Steve is sloppy and adds 2 also :-). For long doubles, it is clear that > 3 are strictly needed, since DECIMAL_DIG is 3 more. So I better use +3 here? printf("expl(%Lf) is %.*Lf\n", d, LDBL_DIG+3, f); ^^ > For most long double functions on i386, you need to switch the rounding > precision to 64 bits around calls to them, and also to do any operations > on the results except printing them. expl() is one of the few large > functions that does the switch internally. So the above should work > (since it only prints), but (expl(d) + 0) should round to the default > 53-bit precision and this give the same result as exp(d). Now that this rounding problem is more understandable to me, I am happy that in most cases I can use math/R for my calculations ;-) >>> If you actually want to test expl() to see if it is producing >>> a decent result, you need a reference solution that contains >>> a higher precision. I use mpfr with 256 bits of precision. >>> >>> troutmask:fvwm:kargl[213] ./testl -V 2 >>> ULP = 0.3863 >>> x = 2.000000000000000000e+00 >>> libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 >>> mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 >>> mpfr: 7.3890560989306502272304274605750078131803155705518\ >>> 47324087127822522573796079054e+00 >>> mpfr: >>> 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0 >>> >>> The 1st 'mpfr:' line is produced after converting the results >>> fof mpfr_exp() to long double. The 2nd 'mpfr:' line is >>> produced by mpfr_printf() where the number of printed >>> digits depends on the 256-bit precision. The last 'mpfr:' >>> line is mpfr_printf()'s hex formatting. Unfortunately, it >>> does not normalize the hex representation to start with >>> '0x1.', which makes comparison somewhat difficult. > > Starting with 0x1 is only a good (just OK) normalization when the number > of binary digits is 1 mod the number of bits in a nybble. So it is good > for doubles but bad for long doubles on x86 and 256-bit format. To > reduce this problem, promote to a common type and print all the bits of > that. (I don't know how to promote to 256 bits to match mpfr). Even when > the first hex nybble is not normalized, the bits of similar results > line up unless the results are not actually similar or in rare half-way > cases. > > Another method that I like to use with better binary formats than %a > produced by my library is to print values twice, first rounded to > their nominal number of binary bits (53 for doubles) and then with > 8 extra bits (8 is a multiple of 4 to keep the nybbles lined up). > Sometimes you have extra precision and need to see what it is. > i386 has 11 bits of extra precision for long doubles internally, > in all cases provided its rounding precision is switched to 64 > bits and in some other cases. Actually, I would use 12 extra bits > to compare 64-bit values with 53-bit ones, since one extra nybble > provides complete info without much expansion. Yes, that is making sense, even to me with only little skills in this field. Many thanks for your patience and kindness in answering my beginner questions, also to Steve for his postings before. I really appreciate your detailed, understandable explanations. With your help this subject is much more transparent now. Rainer > Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 15:46:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 754E4106566C for ; Thu, 26 Jul 2012 15:46:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6678FC0C for ; Thu, 26 Jul 2012 15:46:17 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q6QFkAUY067670 for ; Thu, 26 Jul 2012 08:46:10 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q6QFkAFs067669 for current@freebsd.org; Thu, 26 Jul 2012 08:46:10 -0700 (PDT) (envelope-from david) Date: Thu, 26 Jul 2012 08:46:10 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20120726154610.GC1587@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 15:46:17 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is at r238795; cut/paste of backtrace: KDB: enter: panic [ thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 12 tid 100026 td 0xc6755000 kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x= 3d panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_s= leep+0x35e _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_disp= atch_src+0xa7 netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input= +0x329 netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at= intr_event_execute_handlers+0xc5 ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xf0839d40, ebp =3D 0 --- db> show locks exclusive sleep mutex em0 (EM TX Lock) r =3D 0 (0xc68b8560) locked @ /usr/s= rc/sys/dev/e1000/if_lem.c:1324 exclusive sleep mutex em0 (EM Core Lock) r =3D 0 (0xc68b854c) locked @ /usr= /src/sys/dev/e1000/if_lem.c:1302 db>=20 I need to head off to a meeting; I can poke at the machine a bit more in a couple of hours or so. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlARZkEACgkQmprOCmdXAD2eMACeJ+jeIqBlAorF2dQFcKaB+FT3 eEsAnibzYn8tJQNnlEsdad76KJSYXSl3 =i85M -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 16:01:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02FD01065672 for ; Thu, 26 Jul 2012 16:01:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC82E8FC12 for ; Thu, 26 Jul 2012 16:01:18 +0000 (UTC) Received: by obbun3 with SMTP id un3so3718626obb.13 for ; Thu, 26 Jul 2012 09:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9p3c4Rajn5SuE8EHx1zi1yKiyXS9Bq/qaVcC+G2CXGY=; b=CLkrC5eEcmTRzIagHV3ZMznvAgg3hi3VPwwdVcSvIHQk+7TBJqvI6hUJFxvUiCrhtK wAv2mSc/X/jvzakrnOB6gullZemx8hsO6Ddww7PJdCoHNTNRdmWHYb5XAs5vjuLtATkw I8GeDcoWreamjuUndK+M4MTQtUwt8nzbUBJyOrOdr0ThulLVv1v2Xx1p9sMjiOx9JGDj T9RVtZp+z7rIW7Jph6QQo11oA3oJejb+1QPGWrsjFq0z6uzBcvzNvSs8UZydc2rJWB6z b0RneTsDe5f+8aPT8CY7CI0WXxugpNxpIIb+LoJx0gU6Zl5BobaXDvVDb49zWIDrqaS+ h7eg== MIME-Version: 1.0 Received: by 10.182.88.9 with SMTP id bc9mr42478036obb.4.1343318478317; Thu, 26 Jul 2012 09:01:18 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Thu, 26 Jul 2012 09:01:18 -0700 (PDT) In-Reply-To: <20120726154610.GC1587@albert.catwhisker.org> References: <20120726154610.GC1587@albert.catwhisker.org> Date: Thu, 26 Jul 2012 09:01:18 -0700 Message-ID: From: Garrett Cooper To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:01:19 -0000 On Thu, Jul 26, 2012 at 8:46 AM, David Wolfskill wrote: > This is at r238795; cut/paste of backtrace: > > KDB: enter: panic > [ thread pid 12 tid 100026 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> bt > Tracing pid 12 tid 100026 td 0xc6755000 > kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d > panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 > _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e > _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb > lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 > if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 > ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df > arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c > netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 > netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 > ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 > ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 > netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 > netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 > ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 > lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 > intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 > ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 > fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- > db> show locks > exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 > exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 > db> > > I need to head off to a meeting; I can poke at the machine a bit more > in a couple of hours or so. Probably fallout from Luigi enabling legacy interrupts by default in r238765. -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 16:03:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E99F1065670 for ; Thu, 26 Jul 2012 16:03:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 589AB8FC12 for ; Thu, 26 Jul 2012 16:03:27 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3AFB67300A; Thu, 26 Jul 2012 18:23:25 +0200 (CEST) Date: Thu, 26 Jul 2012 18:23:25 +0200 From: Luigi Rizzo To: Garrett Cooper Message-ID: <20120726162325.GA47121@onelab2.iet.unipi.it> References: <20120726154610.GC1587@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:03:27 -0000 On Thu, Jul 26, 2012 at 09:01:18AM -0700, Garrett Cooper wrote: > On Thu, Jul 26, 2012 at 8:46 AM, David Wolfskill wrote: > > This is at r238795; cut/paste of backtrace: > > > > KDB: enter: panic > > [ thread pid 12 tid 100026 ] > > Stopped at kdb_enter+0x3d: movl $0,kdb_why > > db> bt > > Tracing pid 12 tid 100026 td 0xc6755000 > > kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d > > panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 > > _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e > > _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb > > lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 > > if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 > > ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df > > arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c > > netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 > > netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 > > ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 > > ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 > > netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 > > netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 > > ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 > > lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 > > intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 > > ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 > > fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- > > db> show locks > > exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 > > exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 > > db> > > > > I need to head off to a meeting; I can poke at the machine a bit more > > in a couple of hours or so. > > Probably fallout from Luigi enabling legacy interrupts by default in r238765. yes. I'll investigate with David then he returns from the meeting, and either we find a fix or i will backout the change and add a note in the source about this problem, should people want to look at it in the future. cheers luigi on the From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 20:11:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 989FE106566C for ; Thu, 26 Jul 2012 20:11:50 +0000 (UTC) (envelope-from mezz.freebsd@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 574FF8FC0C for ; Thu, 26 Jul 2012 20:11:50 +0000 (UTC) Received: by ghbz22 with SMTP id z22so2901268ghb.13 for ; Thu, 26 Jul 2012 13:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/AXg1iNOdKMxw6t4ibg5xTStNOPLEtprP9cEXjP1ds4=; b=t5aPql9Dw4UrgJy7HxfEEVDkV/VMV5GsiCE2t4VviB8tYCysOe0dcK3GpU8IpLG1Eu HOOhw98m/fPOUEFln8weV0ol2Wo4X5IcmPOaugWO5ayaTeglkUJ6tK+IrESLKNEwgSxs 0Ie2ifpGdSoDMFemHC1Cf5JYuTGkWd43jpYugcLjMXESSZo20M4kGHenzUQNMmYUb8fC l3BjFODoNwR/Sqa+AAbtscMDMO/5ZYvrvQryvt5laF8yQ3UfVlY8IKjLNEcQ4DaNt8H+ CeOoCPRW6Wk5AyAIDRQpsbShfHVQUyMxbUfh6ryKtuW9otpiCLSMnINvElqYB3qsNq9q ULKw== MIME-Version: 1.0 Received: by 10.60.25.226 with SMTP id f2mr123342oeg.13.1343333509753; Thu, 26 Jul 2012 13:11:49 -0700 (PDT) Received: by 10.76.125.233 with HTTP; Thu, 26 Jul 2012 13:11:49 -0700 (PDT) Date: Thu, 26 Jul 2012 15:11:49 -0500 Message-ID: From: Jeremy Messenger To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Is the :u behaves normal or not (a bug) in the make? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 20:11:50 -0000 Hello all, While I was working on add the :build/:run feature in the bsd.gnome.mk. I got a bug where it will running some dependencies got duplicate. Thanks to the make(1) that shows me the :u feature to get rid of the duplicates. But it doesn't exactly help unless I use the :O to get the words in order to make the :u works. I am not sure if it's just limited on how it works (normal) or it's a bug. Here's an example test: ----------------------------- USE_TEST= foo bar bar foobar foo USE_TEST1= foo bar bar foobar foo test: @${ECHO_CMD} "USE_TEST: " ${USE_TEST:u} @${ECHO_CMD} "USE_TEST1: " ${USE_TEST1:O:u} ----------------------------- Here's result: ----------------------------- # make test USE_TEST: foo bar foobar foo USE_TEST1: bar foo foobar ----------------------------- Thanks, Mezz -- mezz.freebsd@gmail.com - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 20:15:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B775106564A for ; Thu, 26 Jul 2012 20:15:55 +0000 (UTC) (envelope-from mezz.freebsd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50EF48FC08 for ; Thu, 26 Jul 2012 20:15:55 +0000 (UTC) Received: by obbun3 with SMTP id un3so4085585obb.13 for ; Thu, 26 Jul 2012 13:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uqKOPUJ6fyJS3+53VjWx/hz+yS0F5TfGfUv8YKPoI3c=; b=eca37yAw3oiHawa4M4F0eB194nk767HAkNh0a79sFr/W/+EQk2ayMO9Q9k1oQRerbQ tkdqjESpI4ZgiKGsSd2hbhlUR7oc7ukzVnMJ60Wtc06VjmH2qqQfgfdkneMx2FE/2xZs HHJEZuA/TkWaQY02igG6/K/wAgaje6HQsurj9cmruG/vkcJ/gRMS38GjI8+3XYOQKZ5R d+h7Ajk3JYngg/a9JTKVX9oDYmNH7ufYY4kLIMquE8kFP/ddpkMQYhSKAnOi7kq23T59 o/WsDvQpfOjroZvbD9tFbnGtE2cP9n797/SRKLtw1bC1AI0w/DaKBxIpROkcfq/BshYZ u7vw== MIME-Version: 1.0 Received: by 10.182.136.66 with SMTP id py2mr183783obb.9.1343333754696; Thu, 26 Jul 2012 13:15:54 -0700 (PDT) Received: by 10.76.125.233 with HTTP; Thu, 26 Jul 2012 13:15:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jul 2012 15:15:54 -0500 Message-ID: From: Jeremy Messenger To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Is the :u behaves normal or not (a bug) in the make? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 20:15:55 -0000 On Thu, Jul 26, 2012 at 3:11 PM, Jeremy Messenger wrote: > Hello all, > > While I was working on add the :build/:run feature in the > bsd.gnome.mk. I got a bug where it will running some dependencies got > duplicate. Thanks to the make(1) that shows me the :u feature to get > rid of the duplicates. But it doesn't exactly help unless I use the :O > to get the words in order to make the :u works. I am not sure if it's > just limited on how it works (normal) or it's a bug. Here's an example > test: > > ----------------------------- > USE_TEST= foo bar bar foobar foo > USE_TEST1= foo bar bar foobar foo > > test: > @${ECHO_CMD} "USE_TEST: " ${USE_TEST:u} > @${ECHO_CMD} "USE_TEST1: " ${USE_TEST1:O:u} > ----------------------------- > > Here's result: > ----------------------------- > # make test > USE_TEST: foo bar foobar foo > USE_TEST1: bar foo foobar > ----------------------------- BTW: # uname -a FreeBSD outlaws.localhost 9.0-STABLE FreeBSD 9.0-STABLE #0: Sat Mar 31 12:43:40 CDT 2012 mezz@outlaws.localhost:/usr/obj/usr/src/sys/GENERIC amd64 > Thanks, > Mezz -- mezz.freebsd@gmail.com - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 21:27:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B753106566B; Thu, 26 Jul 2012 21:27:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5931B8FC08; Thu, 26 Jul 2012 21:27:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6QLRpNG092109; Thu, 26 Jul 2012 17:27:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6QLRppx092108; Thu, 26 Jul 2012 21:27:51 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 26 Jul 2012 21:27:51 GMT Message-Id: <201207262127.q6QLRppx092108@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:27:57 -0000 TB --- 2012-07-26 20:18:04 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-26 20:18:04 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-26 20:18:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-26 20:18:04 - cleaning the object tree TB --- 2012-07-26 20:18:04 - cvsupping the source tree TB --- 2012-07-26 20:18:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-26 20:18:50 - building world TB --- 2012-07-26 20:18:50 - CROSS_BUILD_TESTING=YES TB --- 2012-07-26 20:18:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-26 20:18:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-26 20:18:50 - SRCCONF=/dev/null TB --- 2012-07-26 20:18:50 - TARGET=sparc64 TB --- 2012-07-26 20:18:50 - TARGET_ARCH=sparc64 TB --- 2012-07-26 20:18:50 - TZ=UTC TB --- 2012-07-26 20:18:50 - __MAKE_CONF=/dev/null TB --- 2012-07-26 20:18:50 - cd /src TB --- 2012-07-26 20:18:50 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 26 20:18:51 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 26 21:21:17 UTC 2012 TB --- 2012-07-26 21:21:17 - generating LINT kernel config TB --- 2012-07-26 21:21:17 - cd /src/sys/sparc64/conf TB --- 2012-07-26 21:21:17 - /usr/bin/make -B LINT TB --- 2012-07-26 21:21:17 - cd /src/sys/sparc64/conf TB --- 2012-07-26 21:21:17 - /usr/sbin/config -m LINT TB --- 2012-07-26 21:21:17 - building LINT kernel TB --- 2012-07-26 21:21:17 - CROSS_BUILD_TESTING=YES TB --- 2012-07-26 21:21:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-26 21:21:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-26 21:21:17 - SRCCONF=/dev/null TB --- 2012-07-26 21:21:17 - TARGET=sparc64 TB --- 2012-07-26 21:21:17 - TARGET_ARCH=sparc64 TB --- 2012-07-26 21:21:17 - TZ=UTC TB --- 2012-07-26 21:21:17 - __MAKE_CONF=/dev/null TB --- 2012-07-26 21:21:17 - cd /src TB --- 2012-07-26 21:21:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 26 21:21:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c {standard input}: Assembler messages: {standard input}:6869: Error: Unknown opcode: `prefetcht0' *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-26 21:27:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-26 21:27:51 - ERROR: failed to build LINT kernel TB --- 2012-07-26 21:27:51 - 3310.72 user 589.32 system 4187.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 21:29:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B8CC1065672; Thu, 26 Jul 2012 21:29:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 05AE08FC16; Thu, 26 Jul 2012 21:29:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6QLTrss098278; Thu, 26 Jul 2012 17:29:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6QLTrcD098277; Thu, 26 Jul 2012 21:29:53 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 26 Jul 2012 21:29:53 GMT Message-Id: <201207262129.q6QLTrcD098277@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:29:54 -0000 TB --- 2012-07-26 19:09:57 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-26 19:09:57 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-26 19:09:57 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-26 19:09:57 - cleaning the object tree TB --- 2012-07-26 19:09:57 - cvsupping the source tree TB --- 2012-07-26 19:09:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-26 19:10:54 - building world TB --- 2012-07-26 19:10:54 - CROSS_BUILD_TESTING=YES TB --- 2012-07-26 19:10:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-26 19:10:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-26 19:10:54 - SRCCONF=/dev/null TB --- 2012-07-26 19:10:54 - TARGET=powerpc TB --- 2012-07-26 19:10:54 - TARGET_ARCH=powerpc TB --- 2012-07-26 19:10:54 - TZ=UTC TB --- 2012-07-26 19:10:54 - __MAKE_CONF=/dev/null TB --- 2012-07-26 19:10:54 - cd /src TB --- 2012-07-26 19:10:54 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 26 19:10:55 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 26 21:24:50 UTC 2012 TB --- 2012-07-26 21:24:50 - generating LINT kernel config TB --- 2012-07-26 21:24:50 - cd /src/sys/powerpc/conf TB --- 2012-07-26 21:24:50 - /usr/bin/make -B LINT TB --- 2012-07-26 21:24:50 - cd /src/sys/powerpc/conf TB --- 2012-07-26 21:24:50 - /usr/sbin/config -m LINT TB --- 2012-07-26 21:24:50 - building LINT kernel TB --- 2012-07-26 21:24:50 - CROSS_BUILD_TESTING=YES TB --- 2012-07-26 21:24:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-26 21:24:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-26 21:24:50 - SRCCONF=/dev/null TB --- 2012-07-26 21:24:50 - TARGET=powerpc TB --- 2012-07-26 21:24:50 - TARGET_ARCH=powerpc TB --- 2012-07-26 21:24:50 - TZ=UTC TB --- 2012-07-26 21:24:50 - __MAKE_CONF=/dev/null TB --- 2012-07-26 21:24:50 - cd /src TB --- 2012-07-26 21:24:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 26 21:24:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_eth_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_ethp_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c {standard input}: Assembler messages: {standard input}:5958: Error: Unrecognized opcode: `prefetcht0' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-26 21:29:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-26 21:29:53 - ERROR: failed to build LINT kernel TB --- 2012-07-26 21:29:53 - 6876.32 user 900.18 system 8396.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 22:10:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632181065670 for ; Thu, 26 Jul 2012 22:10:35 +0000 (UTC) (envelope-from ohauer@FreeBSD.org) Received: from p578be941.dip0.t-ipconnect.de (p578be941.dip0.t-ipconnect.de [87.139.233.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9B18FC15 for ; Thu, 26 Jul 2012 22:10:35 +0000 (UTC) Received: from [192.168.0.100] (cde1100.uni.vrs [192.168.0.100]) (Authenticated sender: ohauer) by p578be941.dip0.t-ipconnect.de (Postfix) with ESMTPSA id 0DA4D2089A; Fri, 27 Jul 2012 00:10:24 +0200 (CEST) Message-ID: <5011C04E.2070507@FreeBSD.org> Date: Fri, 27 Jul 2012 00:10:22 +0200 From: Olli Hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeremy Messenger Subject: Re: Is the :u behaves normal or not (a bug) in the make? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD Current List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 22:10:35 -0000 On 2012-07-26 22:11, Jeremy Messenger wrote: > Hello all, > > While I was working on add the :build/:run feature in the > bsd.gnome.mk. I got a bug where it will running some dependencies got > duplicate. Thanks to the make(1) that shows me the :u feature to get > rid of the duplicates. But it doesn't exactly help unless I use the :O > to get the words in order to make the :u works. I am not sure if it's > just limited on how it works (normal) or it's a bug. Here's an example > test: > > ----------------------------- > USE_TEST= foo bar bar foobar foo > USE_TEST1= foo bar bar foobar foo > > test: > @${ECHO_CMD} "USE_TEST: " ${USE_TEST:u} > @${ECHO_CMD} "USE_TEST1: " ${USE_TEST1:O:u} > ----------------------------- > > Here's result: > ----------------------------- > # make test > USE_TEST: foo bar foobar foo > USE_TEST1: bar foo foobar > ----------------------------- It's normal, from man(1) make u Remove adjacent duplicate words (like uniq(1)). from man(1) uniq Repeated lines in the input will not be detected if they are not adjacent, so it may be necessary to sort the files first. -- Regards, olli From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 22:16:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C72106564A; Thu, 26 Jul 2012 22:16:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 863F78FC12; Thu, 26 Jul 2012 22:16:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6QMGCIt009693; Thu, 26 Jul 2012 18:16:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6QMGCEh009692; Thu, 26 Jul 2012 22:16:12 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 26 Jul 2012 22:16:12 GMT Message-Id: <201207262216.q6QMGCEh009692@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 22:16:13 -0000 TB --- 2012-07-26 19:29:08 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-26 19:29:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-26 19:29:08 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-26 19:29:08 - cleaning the object tree TB --- 2012-07-26 19:29:08 - cvsupping the source tree TB --- 2012-07-26 19:29:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-26 19:30:39 - building world TB --- 2012-07-26 19:30:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-26 19:30:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-26 19:30:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-26 19:30:39 - SRCCONF=/dev/null TB --- 2012-07-26 19:30:39 - TARGET=powerpc TB --- 2012-07-26 19:30:39 - TARGET_ARCH=powerpc64 TB --- 2012-07-26 19:30:39 - TZ=UTC TB --- 2012-07-26 19:30:39 - __MAKE_CONF=/dev/null TB --- 2012-07-26 19:30:39 - cd /src TB --- 2012-07-26 19:30:39 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 26 19:30:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jul 26 22:11:10 UTC 2012 TB --- 2012-07-26 22:11:10 - generating LINT kernel config TB --- 2012-07-26 22:11:10 - cd /src/sys/powerpc/conf TB --- 2012-07-26 22:11:10 - /usr/bin/make -B LINT TB --- 2012-07-26 22:11:10 - cd /src/sys/powerpc/conf TB --- 2012-07-26 22:11:10 - /usr/sbin/config -m LINT TB --- 2012-07-26 22:11:10 - building LINT kernel TB --- 2012-07-26 22:11:10 - CROSS_BUILD_TESTING=YES TB --- 2012-07-26 22:11:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-26 22:11:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-26 22:11:10 - SRCCONF=/dev/null TB --- 2012-07-26 22:11:10 - TARGET=powerpc TB --- 2012-07-26 22:11:10 - TARGET_ARCH=powerpc64 TB --- 2012-07-26 22:11:10 - TZ=UTC TB --- 2012-07-26 22:11:10 - __MAKE_CONF=/dev/null TB --- 2012-07-26 22:11:10 - cd /src TB --- 2012-07-26 22:11:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 26 22:11:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_eth_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_ethp_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c {standard input}: Assembler messages: {standard input}:8133: Error: Unrecognized opcode: `prefetcht0' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-26 22:16:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-26 22:16:12 - ERROR: failed to build LINT kernel TB --- 2012-07-26 22:16:12 - 8405.01 user 1136.40 system 10024.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 22:16:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1261A1065673 for ; Thu, 26 Jul 2012 22:16:18 +0000 (UTC) (envelope-from mezz.freebsd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C35318FC18 for ; Thu, 26 Jul 2012 22:16:17 +0000 (UTC) Received: by yhfs35 with SMTP id s35so3021243yhf.13 for ; Thu, 26 Jul 2012 15:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Jz8jzVtDMxpiLpJKR0kZwd3mJGatp6qB3XVVIrm0n+4=; b=XVefNZ/i2JuEUMBYnN3/CCgEiSS+KAbi3J2TkDcJzXEUNRqwcRAap4vTq9hAMfbHc5 6FhNevaKSnAXaS+krg7nZqJZWHNVLDo07JlIFgineCjB6qyF/lAGu9CeAILS+3/janY6 a4cKq3xSOCWyB/PyKg9tvFiK6DmhMFvctxFTAlN7daHexREKIrE08JHDrEXSC1jYALEv D2zxQnRAysEbmQHMTyLuXXU4sxXinAdjpl4zxR0c1j2HwfEn6ZVQT1QLz+TSw96VCOdY yiDGGwL7tU+I84zX8pcaDIg4Wpa3MqnIHT3i6OfdeEGjLjgGtLnRjoeskmT1z+e+suTL nwlw== MIME-Version: 1.0 Received: by 10.66.75.168 with SMTP id d8mr606208paw.63.1343340976773; Thu, 26 Jul 2012 15:16:16 -0700 (PDT) Received: by 10.66.41.100 with HTTP; Thu, 26 Jul 2012 15:16:16 -0700 (PDT) In-Reply-To: <5011C04E.2070507@FreeBSD.org> References: <5011C04E.2070507@FreeBSD.org> Date: Thu, 26 Jul 2012 17:16:16 -0500 Message-ID: From: Jeremy Messenger To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Is the :u behaves normal or not (a bug) in the make? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 22:16:18 -0000 On Thu, Jul 26, 2012 at 5:10 PM, Olli Hauer wrote: > On 2012-07-26 22:11, Jeremy Messenger wrote: >> Hello all, >> >> While I was working on add the :build/:run feature in the >> bsd.gnome.mk. I got a bug where it will running some dependencies got >> duplicate. Thanks to the make(1) that shows me the :u feature to get >> rid of the duplicates. But it doesn't exactly help unless I use the :O >> to get the words in order to make the :u works. I am not sure if it's >> just limited on how it works (normal) or it's a bug. Here's an example >> test: >> >> ----------------------------- >> USE_TEST= foo bar bar foobar foo >> USE_TEST1= foo bar bar foobar foo >> >> test: >> @${ECHO_CMD} "USE_TEST: " ${USE_TEST:u} >> @${ECHO_CMD} "USE_TEST1: " ${USE_TEST1:O:u} >> ----------------------------- >> >> Here's result: >> ----------------------------- >> # make test >> USE_TEST: foo bar foobar foo >> USE_TEST1: bar foo foobar >> ----------------------------- > > > It's normal, from man(1) make > u Remove adjacent duplicate words (like uniq(1)). > > from man(1) uniq > Repeated lines in the input will not be detected if they are > not adjacent, so it may be necessary to sort the files first. Damn it, I missed that line! :-P Thanks! Cheers, Mezz > -- > Regards, > olli -- mezz.freebsd@gmail.com - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 05:41:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E49E106564A for ; Fri, 27 Jul 2012 05:41:06 +0000 (UTC) (envelope-from alp@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.238]) by mx1.freebsd.org (Postfix) with ESMTP id E06188FC08 for ; Fri, 27 Jul 2012 05:41:05 +0000 (UTC) Received: from pyhalov.cc.rsu.ru (pyhalov.cc.rsu.ru [195.208.255.102]) (Authenticated sender: alp@sfedu.ru) by mail.r61.net (MTA) with ESMTPSA id C65E83A16B1 for ; Fri, 27 Jul 2012 09:35:13 +0400 (MSK) Message-ID: <50122891.5050301@rsu.ru> Date: Fri, 27 Jul 2012 09:35:13 +0400 From: Alexander Pyhalov User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.14) Gecko/20110306 Thunderbird/3.1.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.7 (mail.r61.net [0.0.0.0]); Fri, 27 Jul 2012 09:35:13 +0400 (MSK) Subject: make release recursion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 05:41:06 -0000 Hello. I've tried to do "make cdrom" on recent 10-current (svn revision 238763) and got after day of work: a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/pam_echo.so a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/libwind_p.a a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/librpcsec_gss.so.1 a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/libzfs_p.a ... Here I hitted ^C and received: *** src.txz removed It seems, it continued to add files to some archive recursively... Is it a bug or maybe I just can't cook it properly? -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 05:52:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9507106566C for ; Fri, 27 Jul 2012 05:52:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 92ACE8FC08 for ; Fri, 27 Jul 2012 05:52:09 +0000 (UTC) Received: by ghbz22 with SMTP id z22so3326171ghb.13 for ; Thu, 26 Jul 2012 22:52:09 -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=WcjbAVPK8BWvTjHlkDActlekf8kuAamU4d9QmnytGvk=; b=pZfhZ+6nd9daUnMUVGicx/VE7Fp6ZBGkSLZpkR2AFwQoJC9QPNWCQvA2H253/UzOM+ Uw/B3fxfG0DbDk2h5A3EU1KHp30WCFLyF9dP0W5zlpwvhnXsgRCNhPRxFePzcaOE7xgK H0e47JDQR019zUcpUuQaSO+do+W5DkH44VCq+qLXjSYhbnUM+NfF70f+wk3h8vlys2uU SCqZrPmJwxHbrXZKAos9Y15jLDBFFGucTPEM5/04NsMHk15g6cHSti1M+3lR+rpslR5j PJLP5p+xTy9xrWomLMBq50nZdJPYtD9DLtGJy2asv9sT3L3SgEYdPcqER0LJV90fB9RF OScQ== MIME-Version: 1.0 Received: by 10.66.74.36 with SMTP id q4mr3043487pav.13.1343368328559; Thu, 26 Jul 2012 22:52:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Thu, 26 Jul 2012 22:52:08 -0700 (PDT) In-Reply-To: <20120725151403.GA33640@onelab2.iet.unipi.it> References: <20120724202019.GA22927@onelab2.iet.unipi.it> <20120725151403.GA33640@onelab2.iet.unipi.it> Date: Thu, 26 Jul 2012 22:52:08 -0700 X-Google-Sender-Auth: u63peznblJ671mzSItgHkmLjrCc Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 05:52:10 -0000 On 25 July 2012 08:14, Luigi Rizzo wrote: >> I suggest doing some digging to understand why. I bet we all know the >> answer, but it would be nice to have it documented and investigated. I >> bet em(4) isn't the only device that would benefit from this? > > I am not so sure i know the answer on bare iron (and my take is that the > difference is more or less irrelevant there), but in the virtualized case > the improvement is almost surely because the code used in FAST_INTR > has a couple of MMIO accesses to disable/enable interrupts on the > card while the taskqueue runs. These are expensive in a VM > (such accesses cost ~10K cycles each, even with hw support) Hm, really? Doing these register accesses to a virtualised em NIC in a VM is that expensive, or is there something else going on I don't understand? Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 06:15:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63F7D106566C; Fri, 27 Jul 2012 06:15:22 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 209768FC0C; Fri, 27 Jul 2012 06:15:21 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 8CE267300A; Fri, 27 Jul 2012 08:35:14 +0200 (CEST) Date: Fri, 27 Jul 2012 08:35:14 +0200 From: Luigi Rizzo To: Adrian Chadd Message-ID: <20120727063514.GA49988@onelab2.iet.unipi.it> References: <20120724202019.GA22927@onelab2.iet.unipi.it> <20120725151403.GA33640@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 06:15:22 -0000 On Thu, Jul 26, 2012 at 10:52:08PM -0700, Adrian Chadd wrote: > On 25 July 2012 08:14, Luigi Rizzo wrote: > > >> I suggest doing some digging to understand why. I bet we all know the > >> answer, but it would be nice to have it documented and investigated. I > >> bet em(4) isn't the only device that would benefit from this? > > > > I am not so sure i know the answer on bare iron (and my take is that the > > difference is more or less irrelevant there), but in the virtualized case > > the improvement is almost surely because the code used in FAST_INTR > > has a couple of MMIO accesses to disable/enable interrupts on the > > card while the taskqueue runs. These are expensive in a VM > > (such accesses cost ~10K cycles each, even with hw support) > > Hm, really? Doing these register accesses to a virtualised em NIC in a > VM is that expensive, or is there something else going on I don't > understand? access to emulated registers is expensive because you need to exit from the hardware VM before you can run the emulation code, and the exit is incredibly expensive as it needs to save a ton of state. Things are marginally better in qemu, but there everything is more expensive so you still see a measurable performance gain if you save the accesses. There is a recent paper/talk at usenix that discusses briefly the problem https://www.usenix.org/conference/usenixfederatedconferencesweek/software-techniques-avoiding-hardware-virtualization-exits The ~10k cycles per access were measured in kvm on recent i5 and i7 processors. For qemu, the change moves the packet rate from 7.5 to 8.3 Kpps, if you do the math the difference is about 13us per packet so we are in a similar ballpark. (the numbers are low because the default emulation does not support interrupt mitigation, i have patches for that, see the qemu-devel mailing list http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03195.html which bring the rate up to some 50kpps. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 08:32:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 724C3106566B for ; Fri, 27 Jul 2012 08:32:47 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id E71918FC0A for ; Fri, 27 Jul 2012 08:32:46 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id q6R8WUZj040569; Fri, 27 Jul 2012 10:32:45 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id q6R8WU7i040568; Fri, 27 Jul 2012 10:32:30 +0200 (CEST) (envelope-from olli) Date: Fri, 27 Jul 2012 10:32:30 +0200 (CEST) Message-Id: <201207270832.q6R8WU7i040568@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG X-Newsgroups: list.freebsd-current User-Agent: tin/1.9.6-20101126 ("Burnside") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (lurza.secnetix.de [127.0.0.1]); Fri, 27 Jul 2012 10:32:45 +0200 (CEST) Cc: Subject: Change default for periodic/weekly/400.status-pkg ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 08:32:47 -0000 Hi, Currently, the periodic/weekly/400.status-pkg script uses the ports' INDEX file if it exists. On my machines, the INDEX file exists, and the periodic script produces output like this: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: $ That is, apparently everything is up to date, so I don't have to do anything. But this is wrong. When I change it to use /nonexistent in place of the INDEX file, I get this output: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: netpbm-manpages-10.35.85 was orphaned: LOCAL/netpbm-manpages pkg-config-0.25_1 was orphaned: devel/pkg-config $ A-ha! The first line is to be expected (netpbm-manpages is a "fake" port that I maintain locally), but the second line about pkg-config is much more important. Now this makes me look at ports/UPDATING, revealing that pkg-config was replaced by pkgconf. Therefore I propose to change the default for the periodic script to use /nonexistent. It does not change the output that usually appears, it only produces _additional_ output for installed packages whose origin disappeared. This is valuable information, I think. Also, the INDEX file could be outdated, which might lead to wrong results, so using the INDEX file by default is probably not a good idea anyway. Last but not least: Contrary to what the pkg_version(1) manpage suggests, the periodic script actually finishes slightly faster when no INDEX file is used. There doesn't seem to be any reason why the real INDEX file should be used. What do you think? Best regards Oliver PS: Specifying /nonexistent is different from /dev/null. The latter makes pkg_version assume that it is an empty INDEX file, causing different behaviour (not useful) than a non-existing file. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 09:13:35 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6BBE106566C for ; Fri, 27 Jul 2012 09:13:35 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6CF9A8FC12 for ; Fri, 27 Jul 2012 09:13:35 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 34AC228423; Fri, 27 Jul 2012 11:05:59 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 21EEF28427; Fri, 27 Jul 2012 11:05:57 +0200 (CEST) Message-ID: <501259F4.7050908@quip.cz> Date: Fri, 27 Jul 2012 11:05:56 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Oliver Fromme References: <201207270832.q6R8WU7i040568@lurza.secnetix.de> In-Reply-To: <201207270832.q6R8WU7i040568@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: Change default for periodic/weekly/400.status-pkg ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:13:35 -0000 Oliver Fromme wrote: > Hi, > > Currently, the periodic/weekly/400.status-pkg script uses > the ports' INDEX file if it exists. On my machines, the > INDEX file exists, and the periodic script produces output > like this: > > $ /etc/periodic/weekly/400.status-pkg > > Check for out of date packages: > $ > > That is, apparently everything is up to date, so I don't > have to do anything. But this is wrong. When I change it > to use /nonexistent in place of the INDEX file, I get this > output: > > $ /etc/periodic/weekly/400.status-pkg > > Check for out of date packages: > netpbm-manpages-10.35.85 was orphaned: LOCAL/netpbm-manpages > pkg-config-0.25_1 was orphaned: devel/pkg-config > $ > > A-ha! The first line is to be expected (netpbm-manpages > is a "fake" port that I maintain locally), but the second > line about pkg-config is much more important. Now this > makes me look at ports/UPDATING, revealing that pkg-config > was replaced by pkgconf. > > Therefore I propose to change the default for the periodic > script to use /nonexistent. It does not change the output > that usually appears, it only produces _additional_ output > for installed packages whose origin disappeared. This is > valuable information, I think. Also, the INDEX file could > be outdated, which might lead to wrong results, so using > the INDEX file by default is probably not a good idea anyway. On the other hand - we are using daily `portsnap -I update` so we have updated INDEX on all our machines, but outdated ports tree. (freezed in some point in time, so we can have same versions installed on all servers in a group) I think it should be user configurable in /etc/periodic.conf if somebody want to use INDEX or not. Or the hack with /nonexistent should be mentioned in a comment in /etc/defaults/periodic.conf and in a manpage. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 09:18:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 026D11065670 for ; Fri, 27 Jul 2012 09:18:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BAE138FC19 for ; Fri, 27 Jul 2012 09:18:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E64217300B; Fri, 27 Jul 2012 11:38:24 +0200 (CEST) Date: Fri, 27 Jul 2012 11:38:24 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20120727093824.GB56662@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:18:26 -0000 In writing cross platform code I often have to deal with function arguments or variables that are not used on certain platforms. In FreeBSD:sys/cdefs.h we have #define __unused __attribute__((__unused__)) and in the kernel we tend to annotate with "__unused" such arguments int f(type foo __unused) However on linux __unused is not a standard macro, and is often used as a variable or field name in standard headers, so introducing our __unused macro breaks compilation there. The alternative way to avoid an 'unused' warning from the compiler is an empty statement (void)foo; that the compiler hopefully optimizes away. Any disadvantage or objection to selectively use this form in our kernel code for parts that need to work on multiple platforms ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 09:32:33 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0411106564A for ; Fri, 27 Jul 2012 09:32:33 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6633B8FC0C for ; Fri, 27 Jul 2012 09:32:33 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id q6R9WFYY042897; Fri, 27 Jul 2012 11:32:32 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id q6R9WFr0042896; Fri, 27 Jul 2012 11:32:15 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201207270932.q6R9WFr0042896@lurza.secnetix.de> To: 000.fbsd@quip.cz (Miroslav Lachman) Date: Fri, 27 Jul 2012 11:32:15 +0200 (CEST) In-Reply-To: <501259F4.7050908@quip.cz> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (lurza.secnetix.de [127.0.0.1]); Fri, 27 Jul 2012 11:32:32 +0200 (CEST) Cc: freebsd-current@FreeBSD.ORG Subject: Re: Change default for periodic/weekly/400.status-pkg ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:32:34 -0000 Miroslav Lachman wrote: > I think it should be user configurable in /etc/periodic.conf if > somebody want to use INDEX or not. It already is user configurable. My point is to change the default, because the current default is useless. It should also be noted that change is "safe", because the output of the weekly cron script does not change at all if everything is alright. Only if some ports lost their origin, this fact is noted in the output. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 09:44:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F35106566C for ; Fri, 27 Jul 2012 09:44:53 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id BF4BC8FC15 for ; Fri, 27 Jul 2012 09:44:52 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6R9ij3N026053; Fri, 27 Jul 2012 03:44:48 -0600 Date: Fri, 27 Jul 2012 16:47:15 +0700 From: Erich Dollansky To: Luigi Rizzo Message-ID: <20120727164715.51ba740d@AMD620.ovitrap.com> In-Reply-To: <20120727093824.GB56662@onelab2.iet.unipi.it> References: <20120727093824.GB56662@onelab2.iet.unipi.it> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:44:53 -0000 Hi, On Fri, 27 Jul 2012 11:38:24 +0200 Luigi Rizzo wrote: > In writing cross platform code I often have to deal with function > arguments or variables that are not used on certain platforms. > In FreeBSD:sys/cdefs.h we have > if I understand you right here, it is you own code that has to run on different platforms. I can only tell what we are doing since a long long time. We have one file which handles all these things in one central location. This makes all other files independent of the platform but this one file might needs some work when a new platform comes in or things change on one platform. > Any disadvantage or objection to selectively use this form > in our kernel code for parts that need to work on multiple > platforms ? This concept also works inside a kernel, driver or in the world. The concept should then be limited to the module. Erich From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 10:10:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47248106564A for ; Fri, 27 Jul 2012 10:10:29 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 01A008FC08 for ; Fri, 27 Jul 2012 10:10:29 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 38A755C37; Fri, 27 Jul 2012 12:10:27 +0200 (CEST) Message-ID: <50126915.5020405@FreeBSD.org> Date: Fri, 27 Jul 2012 12:10:29 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Luigi Rizzo References: <20120727093824.GB56662@onelab2.iet.unipi.it> In-Reply-To: <20120727093824.GB56662@onelab2.iet.unipi.it> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 10:10:29 -0000 On 2012-07-27 11:38, Luigi Rizzo wrote: > In writing cross platform code I often have to deal with function > arguments or variables that are not used on certain platforms. > In FreeBSD:sys/cdefs.h we have > > #define __unused __attribute__((__unused__)) > > and in the kernel we tend to annotate with "__unused" such arguments > > int f(type foo __unused) > > However on linux __unused is not a standard macro, and is often > used as a variable or field name in standard headers, so introducing > our __unused macro breaks compilation there. Hm, Linux seems to use __unused for padding in structs, and as the name (!!) of unused parameters in prototypes. :( It uses the following for unused attributes: #define __maybe_unused __attribute__((unused)) #define __always_unused __attribute__((unused)) The former seems to be used much more throughout the Linux sources, I count 243 instances of it in my copy, as opposed to just 9 of the latter. I don't really understand the rationale (if any) for two different defines, though. > The alternative way to avoid an 'unused' warning from the compiler > is an empty statement > > (void)foo; > > that the compiler hopefully optimizes away. > > Any disadvantage or objection to selectively use this form > in our kernel code for parts that need to work on multiple > platforms ? Better to just define a UNUSED_ARG() macro for this, that does the cast. This will save you having to go over every file again, should you ever encounter a compiler that complains about useless casts to void... Then again, whatever macro name we come up with, might also clash with Linux. I'm afraid there is no good portable solution, except possibly undefining __unused just before including Linux headers, then re-defining it, but that is rather ugly. Otherwise, either Linux renames all their __unused instances, or we rename all of them. Alternatively, we can introduce an __unused2 macro, just as ugly as the __dead2 and __pure2 macros. Then replace __unused with __unused2 in the files that you intend to port to Linux. From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 11:14:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 218951065672 for ; Fri, 27 Jul 2012 11:14:41 +0000 (UTC) (envelope-from root@9du.org) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7D7E8FC16 for ; Fri, 27 Jul 2012 11:14:40 +0000 (UTC) Received: by ggnm2 with SMTP id m2so3585407ggn.13 for ; Fri, 27 Jul 2012 04:14:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type :x-gm-message-state; bh=60ybCFoxYB6691UvL7sNpKtxgfA6HwEs75CabpM+zI8=; b=Sva4vTC9u6PAf3HacFtWtI5tbWaA9PRz/Vj7Sl1bcQ9YQT7CUBiZU4BD5bFnJWj1F6 LvhEqvrnJBmDYJTBbZAKRvf13T/TrYUeAnE12iNNVta/EJCXMnXRY9AmlwEBLuuG3g0o KTeE7mTsD3u2ivGgr1QwpYoWDAIAlEhxUx+9xzz2RzXeuzYzBNRIl2CJaFsYBqwjhx51 3J5YLSSjwjd08E4ho3pfnXN56W8El7AmWeraEu98v355MHL2TpPMgFJ/ySiTfb2HKmZe RkAAbW1FaYQOKpwkEs3xNSGc68dvEPuXPoxuX0DrLnkxD3jd0Ry5m2B7oUSSInte4lNh lgHQ== Received: by 10.66.73.69 with SMTP id j5mr4967512pav.8.1343387679825; Fri, 27 Jul 2012 04:14:39 -0700 (PDT) Received: from YONG-BJHOME ([111.194.132.40]) by mx.google.com with ESMTPS id sh3sm1738134pbc.16.2012.07.27.04.14.37 (version=SSLv3 cipher=OTHER); Fri, 27 Jul 2012 04:14:39 -0700 (PDT) Date: Fri, 27 Jul 2012 19:14:28 +0800 From: "root@9du.org" To: freebsd-current References: <20120710154057.BC83D1065708@hub.freebsd.org> X-Priority: 3 X-GUID: 47247802-6836-46CC-81BC-1E181303953D X-Has-Attach: no X-Mailer: Foxmail 7.0.1.90[cn] Mime-Version: 1.0 Message-ID: <201207271914198432934@9du.org> X-Gm-Message-State: ALoCoQm6as2PHLPnWeF6j3GSczfjDVwyg5WiOk5Mcqk4nyQA+/rc5pcSK9PzOLBKeFk8qOvwpVpM Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: rizzo Subject: about netmap num_rx_desc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: root List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 11:14:41 -0000 aW4gbmV0bWFwX2tlcm4uaA0Kc3RydWN0IG5ldG1hcF9hZGFwdGVyIHsNCg0KLi4uLi4uDQoNCnVf aW50IG51bV9yeF9kZXNjOw0KLy91X2ludCBidWZmX3NpemU7IC8vIFhYWCBkZXByZWNhdGUsIHVz ZSBORVRNQVBfQlVGX1NJWkUNCg0KDQpidXQgaW4gbmV0bWFwLmMNCg0KaW50DQpuZXRtYXBfYXR0 YWNoKHN0cnVjdCBuZXRtYXBfYWRhcHRlciAqbmEsIGludCBudW1fcXVldWVzKQ0Kew0KLi4uLg0K bmEtPm51bV9yeF9yaW5ncyA9IG51bV9xdWV1ZXM7DQoNCml4Z2JlX25ldG1hcC5oDQoNCnN0YXRp YyB2b2lkDQppeGdiZV9uZXRtYXBfYXR0YWNoKHN0cnVjdCBhZGFwdGVyICphZGFwdGVyKQ0Kew0K Li4uDQpuZXRtYXBfYXR0YWNoKCZuYSwgYWRhcHRlci0+bnVtX3F1ZXVlcyk7DQp9DQoNCndoeSBu b3QgdXNlIHRoZSBuZXRtYXBfYnVmX3NpemUgYXMgbmEtPm51bV9yeF9yaW5nczsNCnRoZW4gd2ls bCBiZSBoYXZlIGEgbGFyZ2VyIGJ1ZmZlcg== From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 11:28:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93968106566C for ; Fri, 27 Jul 2012 11:28:20 +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 130428FC14 for ; Fri, 27 Jul 2012 11:28:20 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id AB8833B6B9; Fri, 27 Jul 2012 11:20:49 +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 q6RBKmW1009655; Fri, 27 Jul 2012 11:20:49 GMT (envelope-from phk@phk.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Jul 2012 11:38:24 +0200." <20120727093824.GB56662@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 27 Jul 2012 11:20:48 +0000 Message-ID: <9654.1343388048@critter.freebsd.dk> Cc: current@freebsd.org Subject: Re: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 11:28:20 -0000 In message <20120727093824.GB56662@onelab2.iet.unipi.it>, Luigi Rizzo writes: >The alternative way to avoid an 'unused' warning from the compiler >is an empty statement > > (void)foo; The thing I don't like about this form, is that it doesn't communicate your intention, only your action. Somewhere down my TODO list I have an item to propose instead: typedef void unused_t; int main(int argc, char **argv) { (unused_t)argc; (unused_t)argv; return (0); } -- 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-current@FreeBSD.ORG Fri Jul 27 12:31:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AE6B106566B for ; Fri, 27 Jul 2012 12:31:36 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5E58FC08 for ; Fri, 27 Jul 2012 12:31:36 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 914C27300A; Fri, 27 Jul 2012 14:51:34 +0200 (CEST) Date: Fri, 27 Jul 2012 14:51:34 +0200 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20120727125134.GA58187@onelab2.iet.unipi.it> References: <20120727093824.GB56662@onelab2.iet.unipi.it> <9654.1343388048@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9654.1343388048@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 12:31:36 -0000 On Fri, Jul 27, 2012 at 11:20:48AM +0000, Poul-Henning Kamp wrote: > In message <20120727093824.GB56662@onelab2.iet.unipi.it>, Luigi Rizzo writes: > > >The alternative way to avoid an 'unused' warning from the compiler > >is an empty statement > > > > (void)foo; > > The thing I don't like about this form, is that it doesn't communicate > your intention, only your action. > > Somewhere down my TODO list I have an item to propose instead: > > typedef void unused_t; > > int main(int argc, char **argv) > { > > (unused_t)argc; > (unused_t)argv; > return (0); > } i certainly like this better, my only concern is that some other platform might come with an incompatible usage of the name 'unused_t' same as it happened for __unused, and we are back with the problem. A comment might be used to explain the intention in even more detail: (void)foo; /* unused on XyBSD and Babbage-OS */ cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 14:26:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C9E4106566B for ; Fri, 27 Jul 2012 14:26:05 +0000 (UTC) (envelope-from prvs=0555f7a98c=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DEDD8FC12 for ; Fri, 27 Jul 2012 14:26:05 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SulUQ-000L8x-5p for freebsd-current@freebsd.org; Fri, 27 Jul 2012 16:26:02 +0200 Date: Fri, 27 Jul 2012 16:26:02 +0200 From: Oliver Brandmueller To: freebsd-current@freebsd.org Message-ID: <20120727142601.GJ60764@e-Gitt.NET> Mail-Followup-To: freebsd-current@freebsd.org References: <50122891.5050301@rsu.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50122891.5050301@rsu.ru> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Subject: Re: make release recursion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 14:26:05 -0000 Hi, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: > Hello. > I've tried to do "make cdrom" on recent 10-current (svn revision 238763) > and got after day of work: [...] > It seems, it continued to add files to some archive recursively... Is it > a bug or maybe I just can't cook it properly? just to note: I just ran into the same thing with 9-STABLE - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 15:37:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA5A106564A for ; Fri, 27 Jul 2012 15:37:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB438FC08 for ; Fri, 27 Jul 2012 15:37:50 +0000 (UTC) Received: by yenl8 with SMTP id l8so3950124yen.13 for ; Fri, 27 Jul 2012 08:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0pQOtvHA089UDmut/HEFGPgpPrkei478LR7D2M4tpw4=; b=0WWZ6qzCvqAF9lxK6bt+YLZyKVOGfAB4nnWUDAvtLQN+Y6F1sWZZNzpnqP6YKOesna 2qp50qe0pQYFwoOaLgng7UPUMd4di1a70DnC8u25d43VnQf818xTlp1aq/Cp4sV0QQ09 DVu0eGrkOmBxYIjWqL/N6xLf0ImxLYh+t6SWPSvfUjx/kqoxzA1p8Qo1N6Qlee8HVskc bFd1bLTjpuJSsdVSHRXAa/O5HMwooXGhAJKj0OnTsl0ZkHLV1FCH7Rt1Zh2puUWG+t9R lEY2pQtSN0vw3e8FO5kuLNJO2XDax9FTR8TRo6rZ0IaQ+Ebzg0C/ijZT3LHxLRF5A7op O3tw== MIME-Version: 1.0 Received: by 10.50.178.33 with SMTP id cv1mr2620092igc.1.1343403463446; Fri, 27 Jul 2012 08:37:43 -0700 (PDT) Received: by 10.64.171.101 with HTTP; Fri, 27 Jul 2012 08:37:43 -0700 (PDT) In-Reply-To: <20120727142601.GJ60764@e-Gitt.NET> References: <50122891.5050301@rsu.ru> <20120727142601.GJ60764@e-Gitt.NET> Date: Fri, 27 Jul 2012 08:37:43 -0700 Message-ID: From: Garrett Cooper To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: make release recursion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 15:37:50 -0000 On Fri, Jul 27, 2012 at 7:26 AM, Oliver Brandmueller wrote: > Hi, > > On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: >> Hello. >> I've tried to do "make cdrom" on recent 10-current (svn revision 238763) >> and got after day of work: > [...] >> It seems, it continued to add files to some archive recursively... Is it >> a bug or maybe I just can't cook it properly? > > just to note: I just ran into the same thing with 9-STABLE This is a known change after 9.0-RELEASE, but out of curiosity, how are you invoking make? I know how things in general need to be fixed but I need to figure out which variable you're passing in incorrectly. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 15:53:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9DE1065670 for ; Fri, 27 Jul 2012 15:53:13 +0000 (UTC) (envelope-from yanegomi@gmail.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 46BE08FC14 for ; Fri, 27 Jul 2012 15:53:13 +0000 (UTC) Received: by ggnm2 with SMTP id m2so3949153ggn.13 for ; Fri, 27 Jul 2012 08:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jH7RSkCFb6VFFATVNTBN+9DSYN/6aYkBqNsSRERPla4=; b=0svZcYyFXIJTry5jMCUC+GuvWj2FmBvzAzEisDCl903dVGthXKhj8FhhK1cMv74hEW n6L4IpaZmLRAB7+eq46qQm0unMkPVdIsTNVqK36C45IHQt0dItR7pUh11Z5nyb4k6wXF y1q3TVEmYeuVHLZdkCl1roQxgZOe67A9ifw33Vw1fG0gA9a7BA020zsw57iLsQYT/oot SSfxuhdNjnWdeoPbG+SGaGSyiWMT+++TPkYUq5OsKmHbz1Cuz4kSoC2TCwl22sFmldut 9kTnoZHwtrqsH8ei45my6AI4zTSnAq8LFDTf6LJFeQRiUDyNckrg/lEEHjM9xl53aVoe Qf/g== MIME-Version: 1.0 Received: by 10.50.169.73 with SMTP id ac9mr5159245igc.29.1343404392461; Fri, 27 Jul 2012 08:53:12 -0700 (PDT) Received: by 10.64.171.101 with HTTP; Fri, 27 Jul 2012 08:53:12 -0700 (PDT) In-Reply-To: References: <50122891.5050301@rsu.ru> <20120727142601.GJ60764@e-Gitt.NET> Date: Fri, 27 Jul 2012 08:53:12 -0700 Message-ID: From: Garrett Cooper To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: make release recursion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 15:53:13 -0000 On Fri, Jul 27, 2012 at 8:37 AM, Garrett Cooper wrote: > On Fri, Jul 27, 2012 at 7:26 AM, Oliver Brandmueller wrote: >> Hi, >> >> On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: >>> Hello. >>> I've tried to do "make cdrom" on recent 10-current (svn revision 238763) >>> and got after day of work: >> [...] >>> It seems, it continued to add files to some archive recursively... Is it >>> a bug or maybe I just can't cook it properly? >> >> just to note: I just ran into the same thing with 9-STABLE > > This is a known change after 9.0-RELEASE, but out of curiosity, > how are you invoking make? I know how things in general need to be > fixed but I need to figure out which variable you're passing in > incorrectly. Another good reference to note: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025326.html . You're not the first people to stumble on this, so I'm filing a PR to help fix it. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 18:25:23 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3242E106566C for ; Fri, 27 Jul 2012 18:25:23 +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 043868FC1A for ; Fri, 27 Jul 2012 18:25:22 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5787502pbb.13 for ; Fri, 27 Jul 2012 11:25:22 -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=I5zSyEV5hJUPqx+g41L5R4AjslCy5gCMHM0t9Awd4pM=; b=bvcInWM7eJtXtG6IPrU2LzRJ+njQ2syoE3nvl0kcRYID/nunn/83NGL6q0NvFGD9TX IML1gnnmTCi+JIsvtpop8y1BjTrlm9+d2itCFJRftoiv8CTPZ4mXCROEsIwjjVJTjRSM oLFqaR+/+3TYFdxRjmJEQFDcP9idOJSjKCVVJI/XIXR6s7LvhVcWx58udpDJqv/uJNTO KwQF3pGOBU2GQuas0l1uL5HiFwd2G9y52Yhh87C5nIOU6hfwpyf4ePoAT0OsJ1FkHBTE JXvQ9uPuwQXnA5GoVqbWYpyGmNmKH0qWUjCqgWkhsxrTnLIM1/n49Zi7WE/FwRkSnTRy GH7g== MIME-Version: 1.0 Received: by 10.68.203.7 with SMTP id km7mr16173106pbc.7.1343413522629; Fri, 27 Jul 2012 11:25:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Fri, 27 Jul 2012 11:25:22 -0700 (PDT) In-Reply-To: <20120727125134.GA58187@onelab2.iet.unipi.it> References: <20120727093824.GB56662@onelab2.iet.unipi.it> <9654.1343388048@critter.freebsd.dk> <20120727125134.GA58187@onelab2.iet.unipi.it> Date: Fri, 27 Jul 2012 11:25:22 -0700 X-Google-Sender-Auth: RfD5Q4gePSePD6YUy17zAnDp87A Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 18:25:23 -0000 I'd rather see a compiler-interpretable "way" of doing this. You could always just use your own for now, until something comes along (like how many #define N(a) there are in the tree, until nitems showed up.) Ie: #define A_UNUSED_T void (A_UNUSED_T) foo; That way (a) it's easy to change with a compile macro change, (b) if it ever clashes, it should be easy enough to rename without having to risk renaming fields you didn't want to, and (c) it's compiler-interpretable. I wonder if bde has any ideas on where a BSD "unused" hint could be stuffed.. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 18:31:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C8D2106564A for ; Fri, 27 Jul 2012 18:31:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.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 E62898FC0A for ; Fri, 27 Jul 2012 18:31:38 +0000 (UTC) Received: by ggnm2 with SMTP id m2so4163688ggn.13 for ; Fri, 27 Jul 2012 11:31:38 -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=qMQo6WHAL0eANdruf26tz5A/z40uwRpBE2g5UREyuGY=; b=GwZ8KlI8uMVEHsevTBVEZkjz+wgsuN1BS3Z0keTlAQEQXW9sTOLbvZBHhl9ndNJnRX A7zmubEPgP3G59yV4kokfUZcDDPeTBUxf/T9w0WG+uTbabmK78X0c6GBFVthCnwlcI1A arvAi+3gczOX6aAZF9xp6w/lY+vTsbFowOzy2/MmxEh0HSuokDbHBXPRBbMp6jhlmtjx j4P7DBgvWpCL5GJsiSTqYYMBOElBDi6tpxff7HSoyXWpZT6PmLy/okdzulKXQya0db0s BExzeP6U6Rnacm6K6wwAlKJsEWDd5aYnoTEYw2ljC4VrSAplKIMKSNYnF5o7R0ApiUXY mLGw== MIME-Version: 1.0 Received: by 10.66.74.69 with SMTP id r5mr7310939pav.56.1343413897808; Fri, 27 Jul 2012 11:31:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Fri, 27 Jul 2012 11:31:37 -0700 (PDT) In-Reply-To: <20120727063514.GA49988@onelab2.iet.unipi.it> References: <20120724202019.GA22927@onelab2.iet.unipi.it> <20120725151403.GA33640@onelab2.iet.unipi.it> <20120727063514.GA49988@onelab2.iet.unipi.it> Date: Fri, 27 Jul 2012 11:31:37 -0700 X-Google-Sender-Auth: Eb-n_aZtyBbknBUE9Qu-8bqvcpo Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: RFC: use EM_LEGACY_IRQ in if_lem.c ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 18:31:39 -0000 Hm. Ok, I wonder whether it's a general case of "touching the hardware too much" versus a more specific case of "all that taskqueue scheduling overhead is killing us in virtualised environments." Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 18:34:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1F04106566B for ; Fri, 27 Jul 2012 18:34:12 +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 9E49F8FC15 for ; Fri, 27 Jul 2012 18:34:12 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 3C5B53B789; Fri, 27 Jul 2012 18:34:11 +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 q6RIYAsG010807; Fri, 27 Jul 2012 18:34:11 GMT (envelope-from phk@phk.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Jul 2012 14:51:34 +0200." <20120727125134.GA58187@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 27 Jul 2012 18:34:10 +0000 Message-ID: <10806.1343414050@critter.freebsd.dk> Cc: current@freebsd.org Subject: Re: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 18:34:13 -0000 In message <20120727125134.GA58187@onelab2.iet.unipi.it>, Luigi Rizzo writes: >A comment might be used to explain the intention in even more detail: > > (void)foo; /* unused on XyBSD and Babbage-OS */ Comments are noise which compilers and static checkers cannot and should not examine. The intent should be expressed where compilers and static checkers can see it. -- 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-current@FreeBSD.ORG Fri Jul 27 18:47:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F21CF106564A for ; Fri, 27 Jul 2012 18:47:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id AB2B78FC14 for ; Fri, 27 Jul 2012 18:47:20 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0FB2F5C37; Fri, 27 Jul 2012 20:47:13 +0200 (CEST) Message-ID: <5012E233.3050007@FreeBSD.org> Date: Fri, 27 Jul 2012 20:47:15 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: David Wolfskill References: <20120726154610.GC1587@albert.catwhisker.org> In-Reply-To: <20120726154610.GC1587@albert.catwhisker.org> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 18:47:21 -0000 On 2012-07-26 17:46, David Wolfskill wrote: > This is at r238795; cut/paste of backtrace: > > KDB: enter: panic > [ thread pid 12 tid 100026 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> bt > Tracing pid 12 tid 100026 td 0xc6755000 > kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d > panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 > _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e > _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb > lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 > if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 > ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df > arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c > netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 > netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 > ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 > ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 > netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 > netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 > ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 > lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 > intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 > ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 > fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- > db> show locks > exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 > exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 > db> > > I need to head off to a meeting; I can poke at the machine a bit more > in a couple of hours or so. I get the same panic and backtrace here, while running as a VMware guest. At least, as soon something actually happens with the network. From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 20:09:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A071065670 for ; Fri, 27 Jul 2012 20:09:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 318828FC12 for ; Fri, 27 Jul 2012 20:09:54 +0000 (UTC) Received: (qmail 4351 invoked by uid 0); 27 Jul 2012 20:09:46 -0000 Received: from unknown (HELO glenbarber.us) (75.146.225.65) by 0 with SMTP; 27 Jul 2012 20:09:46 -0000 Date: Fri, 27 Jul 2012 16:09:44 -0400 From: Glen Barber To: Alexander Pyhalov Message-ID: <20120727200944.GA1442@glenbarber.us> References: <50122891.5050301@rsu.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50122891.5050301@rsu.ru> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: make release recursion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 20:09:54 -0000 Hello, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: > Hello. > I've tried to do "make cdrom" on recent 10-current (svn revision 238763) > and got after day of work: > [...] Could you please retry the cdrom build with NOSRC=yes set? If this does not succeed, could you please provide specific details on how your build environment is set up? While I do recall encountering this in 9-STABLE prior to 9.0-RELEASE, I do not see this happen on 10-CURRENT r237614, and my buildworld/buildkernel on an up-to-date checkout of head is still in progress. Regards, Glen From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 20:31:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 648A3106564A; Fri, 27 Jul 2012 20:31:55 +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 30C5F8FC0C; Fri, 27 Jul 2012 20:31:55 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5956057pbb.13 for ; Fri, 27 Jul 2012 13:31:54 -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=nLD1nWiCkAQJIpWcZ9f6MTcGibLlqDbnNPrcb4L7lMQ=; b=j2xSuEKyv548jW/r3mZq9ozBna9sRbzzmiDOa8M5CPxI7s+gKUKbzHDLxUZJhJl2Ar 5i4OOBk/j/OPMv0+on9jA7+eyc/MdA+onZXjn1p2Zf1XLDsSUR0f9OWziY2ME0fLemJ6 mqebON8nt7k9HcNY6iCyKId++Tr4w4yAZ10D/7RnLTV40yOzN8UlbAQXq+bGp3dHt6Gt iG8p8G1+q75qfsJLSLqofWVyE5GdAhHvRxYOslPvtKotmxbAMR9yHlB05CC6EUIHxthY j44roQ1SJiNGZtp4eqZjbmhowrwxvfrLyAeWfa5SIdyzf43lDNWXHXiYRR3Jc/NFtdFd uUUA== MIME-Version: 1.0 Received: by 10.68.203.7 with SMTP id km7mr16867666pbc.7.1343421114803; Fri, 27 Jul 2012 13:31:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Fri, 27 Jul 2012 13:31:54 -0700 (PDT) In-Reply-To: <5012E233.3050007@FreeBSD.org> References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Fri, 27 Jul 2012 13:31:54 -0700 X-Google-Sender-Auth: nLdP9d1E_m7tzBQkoUN99XZrYG0 Message-ID: From: Adrian Chadd To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 20:31:55 -0000 It looks like a case of "lock held during call up the stack". This is bad for so many reasons. It also makes writing correctly locked drivers a pain in the ass as the moment you unlock the driver before calling ether_input() / ieee80211_input(), you allow things to change state. So no, although you shouldn't use long-held locks to protect things, apparently this is all the rage. iwn(4) does this. ath(4) does not. I'm having a right painful time trying to fine-grain lock things. I'm at the point where I'm about to not care, rip out all the locks and replace with a single ATH_LOCK(). Adrian On 27 July 2012 11:47, Dimitry Andric wrote: > On 2012-07-26 17:46, David Wolfskill wrote: >> This is at r238795; cut/paste of backtrace: >> >> KDB: enter: panic >> [ thread pid 12 tid 100026 ] >> Stopped at kdb_enter+0x3d: movl $0,kdb_why >> db> bt >> Tracing pid 12 tid 100026 td 0xc6755000 >> kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d >> panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 >> _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e >> _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb >> lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 >> if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 >> ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df >> arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c >> netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 >> netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 >> ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 >> ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 >> netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 >> netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 >> ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 >> lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 >> intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 >> ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 >> fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- >> db> show locks >> exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 >> exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 >> db> >> >> I need to head off to a meeting; I can poke at the machine a bit more >> in a couple of hours or so. > > I get the same panic and backtrace here, while running as a VMware > guest. At least, as soon something actually happens with the network. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 06:41:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 718AA106566B for ; Sat, 28 Jul 2012 06:41:17 +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 4C4FE8FC16 for ; Sat, 28 Jul 2012 06:41:17 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q6S6fAaB027375; Sat, 28 Jul 2012 06:41:10 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id tv7nsrthxjcz9tjd863ask9iaw; Sat, 28 Jul 2012 06:41:10 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <20120727093824.GB56662@onelab2.iet.unipi.it> Date: Fri, 27 Jul 2012 23:41:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120727093824.GB56662@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1278) Cc: current@freebsd.org Subject: Re: (void)foo or __unused foo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 06:41:17 -0000 On Jul 27, 2012, at 2:38 AM, Luigi Rizzo wrote: >=20 > The alternative way to avoid an 'unused' warning from the compiler > is an empty statement >=20 > (void)foo; >=20 > that the compiler hopefully optimizes away. I learned the void-cast convention many years ago. I used it throughout the libarchive code and have yet to run into any problems. I always use it in exactly this form (with the exact comment here) so that I can easily search on it: int foo(int a) { (void) a; /* UNUSED */ =85 } I agree with PHK that it would be nice to express this intent in a way that static checkers could verify. I also agree that having static checkers interpret comments is Evil. But I have yet to see any alternative that was as straightforward and widely-supported as this one. Every other viable alternative seems to require tangled clumps of macros. Tim From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 08:52:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97C01106566B; Sat, 28 Jul 2012 08:52:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 660328FC08; Sat, 28 Jul 2012 08:52:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6S8qIn0034335; Sat, 28 Jul 2012 04:52:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6S8qIPi034322; Sat, 28 Jul 2012 08:52:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Jul 2012 08:52:18 GMT Message-Id: <201207280852.q6S8qIPi034322@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 08:52:24 -0000 TB --- 2012-07-28 06:27:10 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-28 06:27:10 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-28 06:27:10 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-28 06:27:10 - cleaning the object tree TB --- 2012-07-28 06:27:10 - cvsupping the source tree TB --- 2012-07-28 06:27:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-28 06:28:03 - building world TB --- 2012-07-28 06:28:03 - CROSS_BUILD_TESTING=YES TB --- 2012-07-28 06:28:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-28 06:28:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-28 06:28:03 - SRCCONF=/dev/null TB --- 2012-07-28 06:28:03 - TARGET=powerpc TB --- 2012-07-28 06:28:03 - TARGET_ARCH=powerpc TB --- 2012-07-28 06:28:03 - TZ=UTC TB --- 2012-07-28 06:28:03 - __MAKE_CONF=/dev/null TB --- 2012-07-28 06:28:03 - cd /src TB --- 2012-07-28 06:28:03 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 06:28:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 08:48:13 UTC 2012 TB --- 2012-07-28 08:48:13 - generating LINT kernel config TB --- 2012-07-28 08:48:13 - cd /src/sys/powerpc/conf TB --- 2012-07-28 08:48:13 - /usr/bin/make -B LINT TB --- 2012-07-28 08:48:13 - cd /src/sys/powerpc/conf TB --- 2012-07-28 08:48:13 - /usr/sbin/config -m LINT TB --- 2012-07-28 08:48:13 - building LINT kernel TB --- 2012-07-28 08:48:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-28 08:48:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-28 08:48:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-28 08:48:13 - SRCCONF=/dev/null TB --- 2012-07-28 08:48:13 - TARGET=powerpc TB --- 2012-07-28 08:48:13 - TARGET_ARCH=powerpc TB --- 2012-07-28 08:48:13 - TZ=UTC TB --- 2012-07-28 08:48:13 - __MAKE_CONF=/dev/null TB --- 2012-07-28 08:48:13 - cd /src TB --- 2012-07-28 08:48:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 08:48:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_keycache.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_led.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_edma.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath_tx_edma.c: In function 'ath_edma_setup_txfifo': /src/sys/dev/ath/if_ath_tx_edma.c:138: error: 'HAL_TXFIFO_DEPTH' undeclared (first use in this function) /src/sys/dev/ath/if_ath_tx_edma.c:138: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath_tx_edma.c:138: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-28 08:52:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-28 08:52:18 - ERROR: failed to build LINT kernel TB --- 2012-07-28 08:52:18 - 6794.80 user 883.49 system 8708.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 09:11:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 137E1106564A; Sat, 28 Jul 2012 09:11:21 +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 CD77D8FC0C; Sat, 28 Jul 2012 09:11:20 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so6872861pbb.13 for ; Sat, 28 Jul 2012 02:11:20 -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 :content-transfer-encoding; bh=URMRhRt77W8lsD4aWuzNv9pjIaEP5916szOCsMSrneg=; b=kZmhefqaTBwIEQv9TVO+rZcWAznzbTfHS5c8W5eolnEwChNsSe8W5OJF3WlJ3zhk9L n3R1g33RZT8lfexDUBWFPxtghfGl1FQIv9dU6PxNGENzO5AUUN26JCDe3JJiQqphAj+t hkODsK9ILWvj/tL8eOb6uxrIgVS55jKwtdi1SxiPnh6AOePTvtCZSTlLjIXN9g3gSgd3 BJhulFr5Ahy3PPLPsgUKboERRtzsoozN/1cPa9mA7+bI7sZt9vv2ccOdaIATzGGFfD33 oAdA96JLAXxGkHj2RogZBEOVRx3tM/z+KgSY7Dair6bMhSOh5f1rdHNbkWWJ+2LYAr+3 2lKg== MIME-Version: 1.0 Received: by 10.68.191.234 with SMTP id hb10mr5743963pbc.2.1343466680458; Sat, 28 Jul 2012 02:11:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Sat, 28 Jul 2012 02:11:20 -0700 (PDT) In-Reply-To: <201207280852.q6S8qIPi034322@freebsd-current.sentex.ca> References: <201207280852.q6S8qIPi034322@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2012 02:11:20 -0700 X-Google-Sender-Auth: s90hOaKui3uubmT9yActglAI7CM Message-ID: From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: powerpc@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 09:11:21 -0000 Fixed in a subsequent commit. Sorry. On 28 July 2012 01:52, FreeBSD Tinderbox wrote: > TB --- 2012-07-28 06:27:10 - tinderbox 2.9 running on freebsd-current.sen= tex.ca > TB --- 2012-07-28 06:27:10 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2012-07-28 06:27:10 - starting HEAD tinderbox run for powerpc/powe= rpc > TB --- 2012-07-28 06:27:10 - cleaning the object tree > TB --- 2012-07-28 06:27:10 - cvsupping the source tree > TB --- 2012-07-28 06:27:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/powerpc/powerpc/supfile > TB --- 2012-07-28 06:28:03 - building world > TB --- 2012-07-28 06:28:03 - CROSS_BUILD_TESTING=3DYES > TB --- 2012-07-28 06:28:03 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2012-07-28 06:28:03 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-07-28 06:28:03 - SRCCONF=3D/dev/null > TB --- 2012-07-28 06:28:03 - TARGET=3Dpowerpc > TB --- 2012-07-28 06:28:03 - TARGET_ARCH=3Dpowerpc > TB --- 2012-07-28 06:28:03 - TZ=3DUTC > TB --- 2012-07-28 06:28:03 - __MAKE_CONF=3D/dev/null > TB --- 2012-07-28 06:28:03 - cd /src > TB --- 2012-07-28 06:28:03 - /usr/bin/make -B buildworld >>>> World build started on Sat Jul 28 06:28:04 UTC 2012 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> World build completed on Sat Jul 28 08:48:13 UTC 2012 > TB --- 2012-07-28 08:48:13 - generating LINT kernel config > TB --- 2012-07-28 08:48:13 - cd /src/sys/powerpc/conf > TB --- 2012-07-28 08:48:13 - /usr/bin/make -B LINT > TB --- 2012-07-28 08:48:13 - cd /src/sys/powerpc/conf > TB --- 2012-07-28 08:48:13 - /usr/sbin/config -m LINT > TB --- 2012-07-28 08:48:13 - building LINT kernel > TB --- 2012-07-28 08:48:13 - CROSS_BUILD_TESTING=3DYES > TB --- 2012-07-28 08:48:13 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2012-07-28 08:48:13 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-07-28 08:48:13 - SRCCONF=3D/dev/null > TB --- 2012-07-28 08:48:13 - TARGET=3Dpowerpc > TB --- 2012-07-28 08:48:13 - TARGET_ARCH=3Dpowerpc > TB --- 2012-07-28 08:48:13 - TZ=3DUTC > TB --- 2012-07-28 08:48:13 - __MAKE_CONF=3D/dev/null > TB --- 2012-07-28 08:48:13 - cd /src > TB --- 2012-07-28 08:48:13 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Sat Jul 28 08:48:13 UTC 2012 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -c -O -pipe -std=3Dc99 -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdi= agnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -= I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include op= t_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D= 100 --param large-function-growth=3D1000 -fno-builtin -msoft-float -Wa,-man= y -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-= protector -Werror /src/sys/dev/ath/if_ath_keycache.c -I/src/sys/dev/ath > cc -c -O -pipe -std=3Dc99 -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdi= agnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -= I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include op= t_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D= 100 --param large-function-growth=3D1000 -fno-builtin -msoft-float -Wa,-man= y -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-= protector -Werror /src/sys/dev/ath/if_ath_led.c -I/src/sys/dev/ath > cc -c -O -pipe -std=3Dc99 -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdi= agnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -= I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include op= t_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D= 100 --param large-function-growth=3D1000 -fno-builtin -msoft-float -Wa,-man= y -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-= protector -Werror /src/sys/dev/ath/if_ath_tx.c -I/src/sys/dev/ath > cc -c -O -pipe -std=3Dc99 -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdi= agnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -= I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include op= t_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D= 100 --param large-function-growth=3D1000 -fno-builtin -msoft-float -Wa,-man= y -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-= protector -Werror /src/sys/dev/ath/if_ath_tx_edma.c -I/src/sys/dev/ath > /src/sys/dev/ath/if_ath_tx_edma.c: In function 'ath_edma_setup_txfifo': > /src/sys/dev/ath/if_ath_tx_edma.c:138: error: 'HAL_TXFIFO_DEPTH' undeclar= ed (first use in this function) > /src/sys/dev/ath/if_ath_tx_edma.c:138: error: (Each undeclared identifier= is reported only once > /src/sys/dev/ath/if_ath_tx_edma.c:138: error: for each function it appear= s in.) > *** Error code 1 > > Stop in /obj/powerpc.powerpc/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-07-28 08:52:18 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2012-07-28 08:52:18 - ERROR: failed to build LINT kernel > TB --- 2012-07-28 08:52:18 - 6794.80 user 883.49 system 8708.30 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 09:39:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CABA7106566B; Sat, 28 Jul 2012 09:39:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8989E8FC12; Sat, 28 Jul 2012 09:39:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6S9d1Nq022781; Sat, 28 Jul 2012 05:39:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6S9d1nG022780; Sat, 28 Jul 2012 09:39:01 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Jul 2012 09:39:01 GMT Message-Id: <201207280939.q6S9d1nG022780@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 09:39:02 -0000 TB --- 2012-07-28 06:44:34 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-28 06:44:34 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-28 06:44:34 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-28 06:44:35 - cleaning the object tree TB --- 2012-07-28 06:44:35 - cvsupping the source tree TB --- 2012-07-28 06:44:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-28 06:45:18 - building world TB --- 2012-07-28 06:45:18 - CROSS_BUILD_TESTING=YES TB --- 2012-07-28 06:45:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-28 06:45:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-28 06:45:18 - SRCCONF=/dev/null TB --- 2012-07-28 06:45:18 - TARGET=powerpc TB --- 2012-07-28 06:45:18 - TARGET_ARCH=powerpc64 TB --- 2012-07-28 06:45:18 - TZ=UTC TB --- 2012-07-28 06:45:18 - __MAKE_CONF=/dev/null TB --- 2012-07-28 06:45:18 - cd /src TB --- 2012-07-28 06:45:18 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 06:45:19 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jul 28 09:35:19 UTC 2012 TB --- 2012-07-28 09:35:19 - generating LINT kernel config TB --- 2012-07-28 09:35:19 - cd /src/sys/powerpc/conf TB --- 2012-07-28 09:35:19 - /usr/bin/make -B LINT TB --- 2012-07-28 09:35:19 - cd /src/sys/powerpc/conf TB --- 2012-07-28 09:35:19 - /usr/sbin/config -m LINT TB --- 2012-07-28 09:35:19 - building LINT kernel TB --- 2012-07-28 09:35:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-28 09:35:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-28 09:35:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-28 09:35:19 - SRCCONF=/dev/null TB --- 2012-07-28 09:35:19 - TARGET=powerpc TB --- 2012-07-28 09:35:19 - TARGET_ARCH=powerpc64 TB --- 2012-07-28 09:35:19 - TZ=UTC TB --- 2012-07-28 09:35:19 - __MAKE_CONF=/dev/null TB --- 2012-07-28 09:35:19 - cd /src TB --- 2012-07-28 09:35:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 09:35:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_keycache.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_led.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_edma.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath_tx_edma.c: In function 'ath_edma_setup_txfifo': /src/sys/dev/ath/if_ath_tx_edma.c:138: error: 'HAL_TXFIFO_DEPTH' undeclared (first use in this function) /src/sys/dev/ath/if_ath_tx_edma.c:138: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath_tx_edma.c:138: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-28 09:39:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-28 09:39:01 - ERROR: failed to build LINT kernel TB --- 2012-07-28 09:39:01 - 8243.04 user 1144.00 system 10466.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 17:21:27 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C00A61065675 for ; Sat, 28 Jul 2012 17:21:27 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8AC8FC1D for ; Sat, 28 Jul 2012 17:21:27 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1SvAhi-0007q9-K7>; Sat, 28 Jul 2012 19:21:26 +0200 Received: from e178024171.adsl.alicedsl.de ([85.178.24.171] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1SvAhi-0007Zz-Fl>; Sat, 28 Jul 2012 19:21:26 +0200 Message-ID: <50141F96.5070808@zedat.fu-berlin.de> Date: Sat, 28 Jul 2012 19:21:26 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: "freeb >> Current FreeBSD" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.24.171 Cc: Subject: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 17:21:27 -0000 When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then: ===>>> Starting build for graphics/png <<<=== ===>>> All dependencies are up to date ===>>> Creating a backup package for old version png-1.5.12 load: 1.38 cmd: bsdtar 99286 [running] 1301.04r 1296.34u 0.00s 100% 5656k And a look on top: last pid: 3365; load averages: 1.49, 1.44, 1.41 up 0+04:39:08 19:17:44 65 processes: 2 running, 63 sleeping CPU: 50.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 48.6% idle Mem: 521M Active, 3599M Inact, 3424M Wired, 32M Cache, 826M Buf, 323M Free ARC: 1970M Total, 672M MRU, 1224M MFU, 48K Anon, 46M Header, 28M Other Swap: 32G Total, 32G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 99286 root 1 103 0 71724K 5672K CPU1 1 24:10 100.00% bsdtar 1339 root 1 21 0 3221M 38008K select 1 3:02 1.71% Xorg 3364 ohartmann 28 20 0 634M 301M uwait 1 0:06 0.63% thunderbird 737 root 1 20 0 16520K 1492K select 0 0:42 0.00% moused 3286 ohartmann 22 20 0 681M 368M uwait 1 0:14 0.00% firefox 1469 ohartmann 1 20 0 72364K 10612K select 1 0:05 0.00% xterm I can circumvent by doing a make reinstall in the port's directory, but this doesn't work for ports which copy files around using tar - like www/firefox and mail/thunderbird (which also get stuck when bsdtar is involved). My operating system is FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 buildworld and kernel from today's sources, ports seem to be up to date, I updated everything successfully before installing the new world which seems to be faulty. I also recompiled usr.bin/tar separately and installed it, but without success. What to do? regards, Oliver From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 18:16:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C08D106564A; Sat, 28 Jul 2012 18:16:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1666F8FC0C; Sat, 28 Jul 2012 18:16:45 +0000 (UTC) Received: by obbun3 with SMTP id un3so7987783obb.13 for ; Sat, 28 Jul 2012 11:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3OkQooc7un/FLsZP94YbJ4Ls8TqKswbqAAFZv0GlhoI=; b=Yc+4G80FPYXWHsbqvGAE39DoH3hirK4j+k8Ra8Ya5rQB2rqzeq8J1gKP0KwXIfY4Pv fDXnArzNlQHDdFQ5+iLyeZhIU0COAIFs6VFrx0It3OdG7Bx2BM15XYqh8pae7I3mUvf1 /MnAZ3RfRXgIa+wSGMfIIECASkCcWUkc5D+cKV5kwnGsOyEYE/jkstEoHFIs6azogtl5 e1pfx6LyK3+9yjSW1lCfdcnNtba5OP9dtZx9IwEfr/igDFdkTiBMVUlXt+SjZjBKni1+ r2Fdm9BqVbHO1cjQowCnltoaak3GgGeouEnbZ+Hxmjy6CmRj2rvFR7wWBXz0Ilb5T73j zWyg== MIME-Version: 1.0 Received: by 10.182.88.9 with SMTP id bc9mr9610070obb.4.1343499404715; Sat, 28 Jul 2012 11:16:44 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sat, 28 Jul 2012 11:16:44 -0700 (PDT) In-Reply-To: <50141F96.5070808@zedat.fu-berlin.de> References: <50141F96.5070808@zedat.fu-berlin.de> Date: Sat, 28 Jul 2012 11:16:44 -0700 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , "freeb >> Current FreeBSD" , Martin Matuska Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 18:16:45 -0000 On Sat, Jul 28, 2012 at 10:21 AM, O. Hartmann wrote: > When updating ports (like databases/sqlite3 or graphics/png via portmaster > graphics/png), the installation process comes to a point where a backup of > the old port is created with bsdtar. The process hangs then: > > ===>>> Starting build for graphics/png <<<=== > > ===>>> All dependencies are up to date > > > ===>>> Creating a backup package for old version png-1.5.12 > load: 1.38 cmd: bsdtar 99286 [running] 1301.04r 1296.34u 0.00s 100% 5656k > > > And a look on top: > > last pid: 3365; load averages: 1.49, 1.44, 1.41 > up 0+04:39:08 19:17:44 > 65 processes: 2 running, 63 sleeping > CPU: 50.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 48.6% idle > Mem: 521M Active, 3599M Inact, 3424M Wired, 32M Cache, 826M Buf, 323M Free > ARC: 1970M Total, 672M MRU, 1224M MFU, 48K Anon, 46M Header, 28M Other > Swap: 32G Total, 32G Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 99286 root 1 103 0 71724K 5672K CPU1 1 24:10 100.00% > bsdtar > 1339 root 1 21 0 3221M 38008K select 1 3:02 1.71% Xorg > 3364 ohartmann 28 20 0 634M 301M uwait 1 0:06 0.63% > thunderbird > 737 root 1 20 0 16520K 1492K select 0 0:42 0.00% > moused > 3286 ohartmann 22 20 0 681M 368M uwait 1 0:14 0.00% > firefox > 1469 ohartmann 1 20 0 72364K 10612K select 1 0:05 0.00% > xterm > > > I can circumvent by doing a make reinstall in the port's directory, but this > doesn't work for ports which copy files around using tar - like www/firefox > and mail/thunderbird (which also get stuck when bsdtar is involved). > > My operating system is > FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 > > buildworld and kernel from today's sources, ports seem to be up to date, I > updated everything successfully before installing the new world which seems > to be faulty. > > I also recompiled usr.bin/tar separately and installed it, but without > success. > > What to do? Debugging with FreeBSD 101: 1. Build application and library with DEBUG_FLAGS=-g . 2. Install application and libraries. 3. Trigger issue again. 4. gcore 5. gdb `which tar` 6. Type in bt and hit enter. Other things that are always needed for developers when tracking down issues: - Simple reproductions: I do X, Y happens (exact commands are a must). - Provide your environment: Quantifying `environment` can be tricky (it can extend to grabbing shell environment info, machine info, etc), but in this case grabbing your /etc/make.conf and /etc/src.conf and providing a date when you synced from ports *should* suffice. Send the backtrace in 6., the reproduction, and your environment, to the upstream/local maintainer (in this case kientzle@/mm@) so the issue can be resolved locally then pulled back in at a later date from upstream. Thanks! -Garrett PS If your situation is reproducible, I might hit this in a bit when I upgrade my VMs and have to do ports upgrades. This is always another helpful datapoint. From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 19:09:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 708DD106567E; Sat, 28 Jul 2012 19:09:54 +0000 (UTC) (envelope-from lacombar@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 A7B418FC08; Sat, 28 Jul 2012 19:09:53 +0000 (UTC) Received: by weyx56 with SMTP id x56so3308688wey.13 for ; Sat, 28 Jul 2012 12:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DCHc3mQ6nHfZfbetpT3cFG0bg3Nd5FcEIc2IxBDz7wY=; b=kbMREAj+yx3nl7c7ma3akoTjp+wNSunPqr/LNk/KoypIgAvlHjs2FgY0YBOPT1plbd l1KeZRdPVNeUVz0vpvaKhwPvZVY9vsdu64R40ewQbwhHR/kzPyXfuuYP3J8FFljBRVQk HoxJLI3eo2EDj9zgMOFDPEvITE7tH4GPbZCzeDHZjVQ/D4K0Kkmw23LoBV/tChVWDNOd L8Xz3fgpsUuDZUhAoT6g0R95kFNxaD8LDEqmhHklpZCvxCUYvC7vT5VerqV27nlhcTI0 cuH46qz9BSm0Bz+2utYbV+C5CUjgGB4biecVUtnMvx1Jxpi7BvkV9lHdChhaE5E9lUnO qOoA== MIME-Version: 1.0 Received: by 10.180.91.1 with SMTP id ca1mr30980584wib.8.1343502587383; Sat, 28 Jul 2012 12:09:47 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 12:09:47 -0700 (PDT) In-Reply-To: References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Sat, 28 Jul 2012 15:09:47 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Dimitry Andric , current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 19:09:54 -0000 Hi, On Fri, Jul 27, 2012 at 4:31 PM, Adrian Chadd wrote: > It looks like a case of "lock held during call up the stack". This is > bad for so many reasons. > > It also makes writing correctly locked drivers a pain in the ass as > the moment you unlock the driver before calling ether_input() / > ieee80211_input(), you allow things to change state. So no, although > you shouldn't use long-held locks to protect things, apparently this > is all the rage. > > iwn(4) does this. ath(4) does not. I'm having a right painful time > trying to fine-grain lock things. I'm at the point where I'm about to > not care, rip out all the locks and replace with a single ATH_LOCK(). > How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to be a classical fallout from direct dispatch where you can re-enter the driver from the driver itself through the network stack. - Arnaud > Adrian > > On 27 July 2012 11:47, Dimitry Andric wrote: >> On 2012-07-26 17:46, David Wolfskill wrote: >>> This is at r238795; cut/paste of backtrace: >>> >>> KDB: enter: panic >>> [ thread pid 12 tid 100026 ] >>> Stopped at kdb_enter+0x3d: movl $0,kdb_why >>> db> bt >>> Tracing pid 12 tid 100026 td 0xc6755000 >>> kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d >>> panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 >>> _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e >>> _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb >>> lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 >>> if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 >>> ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df >>> arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c >>> netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 >>> netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 >>> ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 >>> ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 >>> netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 >>> netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 >>> ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 >>> lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 >>> intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 >>> ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 >>> fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c >>> fork_trampoline() at fork_trampoline+0x8 >>> --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- >>> db> show locks >>> exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 >>> exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 >>> db> >>> >>> I need to head off to a meeting; I can poke at the machine a bit more >>> in a couple of hours or so. >> >> I get the same panic and backtrace here, while running as a VMware >> guest. At least, as soon something actually happens with the network. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 20:04:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22051106566B; Sat, 28 Jul 2012 20:04:28 +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 E02F98FC08; Sat, 28 Jul 2012 20:04:27 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so7620121pbb.13 for ; Sat, 28 Jul 2012 13:04:27 -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=ipM4O4q7w69HJzMZqxwCYrBkz1yDgtyL0CYqGjEo6cc=; b=EbaH/oS9hAv1OrBl7ZSCYm6xSTpQ+vRITu1Mtx7Iv2hgrbOjpnNcQw3fpdtYeCMkIy i4FjEh74/AsJ9c8AnnOp0VMiOYuOrI5oO2+cb+c1dd1IW7i0s7sm/UzMmrCqcs5wbar+ NsOzGX9AIXTx8DdmdcgkeNQM7JIaxFbEMwZtLvR5l5NKW6HQivCsapztbaok/W8WYjXl QV8ZdxCy2LPkCVSWtC+hmFeSGn13WaFK8e+Lny4MmQvRs4WJzCvTkPidgdUu7QgG4pP3 XB9BdlBCaqYvaDQdZx0ORtMR2R7/JBXznZqLGZS7Q0mYFCXxl+9uHouif9q8MB8GTDIn ooDg== MIME-Version: 1.0 Received: by 10.68.218.7 with SMTP id pc7mr23180057pbc.88.1343505867370; Sat, 28 Jul 2012 13:04:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Sat, 28 Jul 2012 13:04:27 -0700 (PDT) In-Reply-To: References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Sat, 28 Jul 2012 13:04:27 -0700 X-Google-Sender-Auth: JPjZ_73LT8F-yuFYEE1U0WYmaTA Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: Dimitry Andric , current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 20:04:28 -0000 On 28 July 2012 12:09, Arnaud Lacombe wrote: > How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to > be a classical fallout from direct dispatch where you can re-enter the > driver from the driver itself through the network stack. Take a look at iwn. It has a single lock - IWN_LOCK() - which it releases before punting the frame up the stack. Adrian From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 21:41:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 578721065670; Sat, 28 Jul 2012 21:41:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 892C18FC0A; Sat, 28 Jul 2012 21:41:52 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3610370wgb.31 for ; Sat, 28 Jul 2012 14:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UcYnvR6ypYuXx0tdXJpvRwLMdPAKqaA8eJjcUTFOE3Q=; b=gTMH1FaxZMw3XIXQiLtSfIBQI97HCkKp9xYKkBYCVQYlkpYfSQwQXxt823xN0sz1UB qjFKYWi7n+a0WVgpi+eGUeUdoo5KRz4gPn+XXcLYHEqo0jTx+vCNcSwpoeMLzf3vdv/V kI3Pp+bukC55VJbcDSAyPc4of1kzfQJ6vR0jf8VBFEiOj4K9VBvjCWsYkbvatESq3TJx st+y5MuZHQ6g3H1+WieN5zVDgTdF2lry5epkCX3yOoRkHMbJU7Ay4i1kJyFrM2H1I6My M7yd8ljuOe7hyZHOHfp+CkCVhTHzPL5Fs8PZ+5u2W7IPKgL5SmhkNiVaSqfSCbfVANKE gMUw== MIME-Version: 1.0 Received: by 10.180.90.207 with SMTP id by15mr31116096wib.22.1343511711674; Sat, 28 Jul 2012 14:41:51 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 14:41:50 -0700 (PDT) In-Reply-To: References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Sat, 28 Jul 2012 17:41:50 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: multipart/mixed; boundary=f46d043c80465371b304c5eab254 Cc: Dimitry Andric , current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 21:41:53 -0000 --f46d043c80465371b304c5eab254 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd wrote: > On 28 July 2012 12:09, Arnaud Lacombe wrote: > >> How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to >> be a classical fallout from direct dispatch where you can re-enter the >> driver from the driver itself through the network stack. > > Take a look at iwn. It has a single lock - IWN_LOCK() - which it > releases before punting the frame up the stack. > oh, I see. So, what happens in lem(4) is that we enter the stack with RX unlocked, but TX and CORE are still locked. The whole locking of lem(4) seems rather inconsistent. Through DEVICE_POLLING, lem_rxeof() is called with TX and CORE unlocked. Through EN_LEGACY_IRQ it is called with TX and CORE locked, and from MSI interrupt handler, is is caller with TX unlocked (CORE assumed to be unlock). I'd assume that lem(4) is just poorly maintained[0]... I would make a huge shot in the dark by proposing the completely untested attached patch :/ - Arnaud [0]: like code claiming support for Intel 82574 when this chipset *cannot* be used by lem(4), as there is no E1000_DEV_ID_82574* entries in `lem_vendor_info_array'. --f46d043c80465371b304c5eab254 Content-Type: application/octet-stream; name="if_lem.c.diff" Content-Disposition: attachment; filename="if_lem.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h5785h3b0 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvZTEwMDAvaWZfbGVtLmMgYi9zeXMvZGV2L2UxMDAwL2lmX2xl bS5jCmluZGV4IDRhZGUxODAuLjE1OTZkNjYgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvZTEwMDAvaWZf bGVtLmMKKysrIGIvc3lzL2Rldi9lMTAwMC9pZl9sZW0uYwpAQCAtMTMwNCwxMSArMTMwNCwxNSBA QCBsZW1faW50cih2b2lkICphcmcpCiAJaWYgKHJlZ19pY3IgJiBFMTAwMF9JQ1JfUlhPKQogCQlh ZGFwdGVyLT5yeF9vdmVycnVucysrOwogCi0JaWYgKChyZWdfaWNyID09IDB4ZmZmZmZmZmYpIHx8 IChyZWdfaWNyID09IDApKQotCQkJZ290byBvdXQ7CisJaWYgKChyZWdfaWNyID09IDB4ZmZmZmZm ZmYpIHx8IChyZWdfaWNyID09IDApKSB7CisJCUVNX0NPUkVfVU5MT0NLKGFkYXB0ZXIpOworCQln b3RvIG91dDsKKwl9CiAKLQlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5H KSA9PSAwKQotCQkJZ290byBvdXQ7CisJaWYgKChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZf UlVOTklORykgPT0gMCkgeworCQlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKKwkJZ290byBvdXQ7 CisJfQogCiAJaWYgKHJlZ19pY3IgJiAoRTEwMDBfSUNSX1JYU0VRIHwgRTEwMDBfSUNSX0xTQykp IHsKIAkJY2FsbG91dF9zdG9wKCZhZGFwdGVyLT50aW1lcik7CkBAIC0xMzIwLDE3ICsxMzI0LDE3 IEBAIGxlbV9pbnRyKHZvaWQgKmFyZykKIAkJICAgIGxlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7 CiAJCWdvdG8gb3V0OwogCX0KKwlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKIAotCUVNX1RYX0xP Q0soYWRhcHRlcik7CiAJbGVtX3J4ZW9mKGFkYXB0ZXIsIC0xLCBOVUxMKTsKKworCUVNX1RYX0xP Q0soYWRhcHRlcik7CiAJbGVtX3R4ZW9mKGFkYXB0ZXIpOwotCWlmIChpZnAtPmlmX2Rydl9mbGFn cyAmIElGRl9EUlZfUlVOTklORyAmJgotCSAgICAhSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9z bmQpKQorCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQogCQlsZW1fc3RhcnRf bG9ja2VkKGlmcCk7CiAJRU1fVFhfVU5MT0NLKGFkYXB0ZXIpOwogCiBvdXQ6Ci0JRU1fQ09SRV9V TkxPQ0soYWRhcHRlcik7CiAJcmV0dXJuOwogfQogCg== --f46d043c80465371b304c5eab254-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 21:49:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33133106566B for ; Sat, 28 Jul 2012 21:49:58 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B6CE18FC19 for ; Sat, 28 Jul 2012 21:49:57 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3612672wgb.31 for ; Sat, 28 Jul 2012 14:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dZ6Fz7ThwtM1L/zBKGUBpP9C6obGvcIS396ZF3ELjms=; b=1GuibtsrrNHEmjv3bw6pfqqg1pg50qGduq6JPI45jgvRFcIZUInSGKK3DBA3Ww7HqY 36FZ7b7wvFGMFiIxihsagf1A/e8h1BAvnwOjWrc81bURTSDhPKfB3qZVLuD6+Vjg1EwU /rPJWychoEnAxKmOzce5XW4jnpPXF6t3YYWTG5tBgABfGJrST+KCbk88bBqsWdw53Nby n2qsqcFmrcgKsc/18C51k3z3Tr19w+jAu3UdyTKdzWCbHKGcThXT2WTqqBsvDNe2z+ls MA/JMz99DJXsairGqOWVum/dnmPrcoShRQgYkMf2vjAcXAn4VxT3spyP4XcHekYbRZJ+ W0+Q== MIME-Version: 1.0 Received: by 10.216.181.67 with SMTP id k45mr3078717wem.17.1343512196856; Sat, 28 Jul 2012 14:49:56 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Sat, 28 Jul 2012 14:49:56 -0700 (PDT) In-Reply-To: <201207270932.q6R9WFr0042896@lurza.secnetix.de> References: <501259F4.7050908@quip.cz> <201207270932.q6R9WFr0042896@lurza.secnetix.de> Date: Sat, 28 Jul 2012 14:49:56 -0700 Message-ID: From: Kevin Oberman To: Oliver Fromme Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: Change default for periodic/weekly/400.status-pkg ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 21:49:58 -0000 On Fri, Jul 27, 2012 at 2:32 AM, Oliver Fromme wrote: > > Miroslav Lachman wrote: > > I think it should be user configurable in /etc/periodic.conf if > > somebody want to use INDEX or not. > > It already is user configurable. My point is to change the > default, because the current default is useless. > > It should also be noted that change is "safe", because the > output of the weekly cron script does not change at all if > everything is alright. Only if some ports lost their origin, > this fact is noted in the output. A couple of thoughts on this. First one is "most likely". If you use you INDEX, was it fetched or built after updating your ports? If it was fetched, it is going to be just a little old, so it might miss something that was just updated. I do this daily, not weekly, and I often see a port or two that has been updated be missed by the check, but it shows up the next day. (I am NOT using a public mirror.) Second, there has been a recent issue with pkgconfig which might, but probably is not causing this odd behavior. It has most certainly been annoying me in other ways, though I believe it may have been fixed in the past 24 hours. (This might indicate the timing issue I mentioned above.) -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 22:14:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0904106566C for ; Sat, 28 Jul 2012 22:14:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 679498FC12 for ; Sat, 28 Jul 2012 22:14:15 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D731725D389C; Sat, 28 Jul 2012 22:14:13 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C353BBE8553; Sat, 28 Jul 2012 22:14:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id SPrXLsQaqjlx; Sat, 28 Jul 2012 22:14:11 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 761EEBE8552; Sat, 28 Jul 2012 22:14:11 +0000 (UTC) Date: Sat, 28 Jul 2012 22:14:10 +0000 (UTC) From: "Bjoern A. Zeeb" To: Luigi Rizzo In-Reply-To: <20120725155211.GA33971@onelab2.iet.unipi.it> Message-ID: References: <20120725155211.GA33971@onelab2.iet.unipi.it> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 22:14:15 -0000 On Wed, 25 Jul 2012, Luigi Rizzo wrote: > During some ipfw/dummynet cleanup i noticed that the libkern version of > inet_ntoa_r() is missing the buffer size argument that is present in > the libc counterpart. > > Any objection if i fix it ? And why exactly would you need it? What does libc do with it? Render partial IPv4 addresses? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 22:35:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44E81106566B for ; Sat, 28 Jul 2012 22:35:41 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id C77B98FC12 for ; Sat, 28 Jul 2012 22:35:40 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so544482wib.13 for ; Sat, 28 Jul 2012 15:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CZhLO0wNsk/raVzXxqpIX+eR3GFDMxj1456SWdF50Oc=; b=gYBzPf6hy389o2TbPplG0nlDg6XUAg3xpMn8ozY6DTG8l5Wr+CUeZ4P+O6efnEJfBA LZ+w1GDgQGHF2wjGY+1p1Q2zNV26O4b81VnyXj8TcZMRah0SXOJtWpRaZC/4Wvmz3H3G LWv8QogEPzOisuYdPbycxHaRLma7db4GGOi9upzA394YTbfCgySypSzANcAkco+vdGbq Me+XzQD79qLZ1tgs4BP8yXrLR7VJVu/kPRl3uAniSv/YC59zzrn4PUVyFUWHgeRmnhRG x232swhPJfRu4M3it/Mu3FzNTjgUmUdCc14iQ4K0K0DWSxLbW8eidw9xwKz0fnVXvSuf AWkg== MIME-Version: 1.0 Received: by 10.180.91.1 with SMTP id ca1mr31758163wib.8.1343514939702; Sat, 28 Jul 2012 15:35:39 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 15:35:39 -0700 (PDT) In-Reply-To: References: <20120725155211.GA33971@onelab2.iet.unipi.it> Date: Sat, 28 Jul 2012 18:35:39 -0400 Message-ID: From: Arnaud Lacombe To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 22:35:41 -0000 Hi, On Sat, Jul 28, 2012 at 6:14 PM, Bjoern A. Zeeb wrote: > On Wed, 25 Jul 2012, Luigi Rizzo wrote: > >> During some ipfw/dummynet cleanup i noticed that the libkern version of >> inet_ntoa_r() is missing the buffer size argument that is present in >> the libc counterpart. >> >> Any objection if i fix it ? > > > And why exactly would you need it? What does libc do with it? Render > partial IPv4 addresses? > Mitigate possibilities of memory corruption ? At the very least, allow the following: { char tmp[sizeof "255.255.255.255"]; KASSERT(size >= (sizeof tmp)); [...] } to be enforced... but hey, who gives a damn about consistently doing things and enforcing code assumptions ? ;-) - Arnaud > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 22:39:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB2DB106566B; Sat, 28 Jul 2012 22:39:42 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B29C8FC0A; Sat, 28 Jul 2012 22:39:42 +0000 (UTC) Received: by obbun3 with SMTP id un3so8335197obb.13 for ; Sat, 28 Jul 2012 15:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UrEPqv4vSV1aD7TQbyDYTGF/pQTBXc7YdYhMqRA8W60=; b=zcM4W//GOX9GjVdYujnVOkFXR+Eble6csbcuWnRpj+A2yTZP2OlHck8FMDizCN6r1e r44aDLfme1ArU1idvTSMXZ71a++N05BrDu4QZUUquZQh/BBQqp+C5ytd9F0SAD7AeRUM QR6E5FNYKSN3+ElZvDhaxrkFh6dNhLEavjTCvtxuO6bDQhkrkbQBJGr1w1TT4pnlfXQd cPkcNFGXKBaTOtDhdWb3ulvGTCvRLZnaTraODFOvTW4V52Uk26ht0ho0Jr17TWIPAgFn uMhK8kmOsWdokTXNm/Yts6NEf60sGvngqmuZ0QaCUwfSAq5T5o0enq60xwHiA8ik9MRc YFVA== MIME-Version: 1.0 Received: by 10.182.8.6 with SMTP id n6mr10246829oba.39.1343515181878; Sat, 28 Jul 2012 15:39:41 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sat, 28 Jul 2012 15:39:41 -0700 (PDT) In-Reply-To: References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Sat, 28 Jul 2012 15:39:41 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: multipart/mixed; boundary=f46d0444ec532a8c8c04c5eb81f7 Cc: Adrian Chadd , Dimitry Andric , current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 22:39:43 -0000 --f46d0444ec532a8c8c04c5eb81f7 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe wrote: > Hi, > > On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd wrote: >> On 28 July 2012 12:09, Arnaud Lacombe wrote: >> >>> How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to >>> be a classical fallout from direct dispatch where you can re-enter the >>> driver from the driver itself through the network stack. >> >> Take a look at iwn. It has a single lock - IWN_LOCK() - which it >> releases before punting the frame up the stack. >> > oh, I see. So, what happens in lem(4) is that we enter the stack with > RX unlocked, but TX and CORE are still locked. The whole locking of > lem(4) seems rather inconsistent. Through DEVICE_POLLING, lem_rxeof() > is called with TX and CORE unlocked. Through EN_LEGACY_IRQ it is > called with TX and CORE locked, and from MSI interrupt handler, is is > caller with TX unlocked (CORE assumed to be unlock). I'd assume that > lem(4) is just poorly maintained[0]... I would make a huge shot in the > dark by proposing the completely untested attached patch :/ > > - Arnaud > > [0]: like code claiming support for Intel 82574 when this chipset > *cannot* be used by lem(4), as there is no E1000_DEV_ID_82574* entries > in `lem_vendor_info_array'. Close, but you missed a spot. The attached patch (based on your's) works, i.e. no longer panics at boot on my vbox instance. Thanks! -Garrett --f46d0444ec532a8c8c04c5eb81f7 Content-Type: application/octet-stream; name="fix-if_lem-panic-at-boot.patch" Content-Disposition: attachment; filename="fix-if_lem-panic-at-boot.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h57a8juz1 LS0tIC8vZGVwb3QvdXNlci9nY29vcGVyL2F0Zi1oZWFkL3NyYy9zeXMvZGV2L2UxMDAwL2lmX2xl bS5jCTIwMTItMDctMjUgMTc6MTE6MDAuMDAwMDAwMDAwIDAwMDAKKysrIC9zY3JhdGNoL3A0L3Vz ZXIvZ2Nvb3Blci9hdGYtaGVhZC9zcmMvc3lzL2Rldi9lMTAwMC9pZl9sZW0uYwkyMDEyLTA3LTI1 IDE3OjExOjAwLjAwMDAwMDAwMCAwMDAwCkBAIC0xMjk0LDEyICsxMjk0LDEzIEBACiAJc3RydWN0 IGFkYXB0ZXIJKmFkYXB0ZXIgPSBhcmc7CiAJc3RydWN0IGlmbmV0CSppZnAgPSBhZGFwdGVyLT5p ZnA7CiAJdTMyCQlyZWdfaWNyOwotCisJaW50IGxvY2tlZDsKIAogCWlmIChpZnAtPmlmX2NhcGVu YWJsZSAmIElGQ0FQX1BPTExJTkcpCiAJCXJldHVybjsKIAogCUVNX0NPUkVfTE9DSyhhZGFwdGVy KTsKKwlsb2NrZWQgPSAxOwogCXJlZ19pY3IgPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcs IEUxMDAwX0lDUik7CiAJaWYgKHJlZ19pY3IgJiBFMTAwMF9JQ1JfUlhPKQogCQlhZGFwdGVyLT5y eF9vdmVycnVucysrOwpAQCAtMTMyMCw5ICsxMzIxLDExIEBACiAJCSAgICBsZW1fbG9jYWxfdGlt ZXIsIGFkYXB0ZXIpOwogCQlnb3RvIG91dDsKIAl9CisJRU1fQ09SRV9VTkxPQ0soYWRhcHRlcik7 CisJbG9ja2VkID0gMDsKIAorCWxlbV9yeGVvZihhZGFwdGVyLCAtMSwgTlVMTCk7CiAJRU1fVFhf TE9DSyhhZGFwdGVyKTsKLQlsZW1fcnhlb2YoYWRhcHRlciwgLTEsIE5VTEwpOwogCWxlbV90eGVv ZihhZGFwdGVyKTsKIAlpZiAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcgJiYK IAkgICAgIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKQEAgLTEzMzAsNyArMTMzMyw5 IEBACiAJRU1fVFhfVU5MT0NLKGFkYXB0ZXIpOwogCiBvdXQ6Ci0JRU1fQ09SRV9VTkxPQ0soYWRh cHRlcik7CisJaWYgKGxvY2tlZCkKKwkJRU1fQ09SRV9VTkxPQ0soYWRhcHRlcik7CisKIAlyZXR1 cm47CiB9CiAK --f46d0444ec532a8c8c04c5eb81f7-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 22:42:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E43E106564A for ; Sat, 28 Jul 2012 22:42:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E611C8FC08 for ; Sat, 28 Jul 2012 22:42:51 +0000 (UTC) Received: by obbun3 with SMTP id un3so8339012obb.13 for ; Sat, 28 Jul 2012 15:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sDculiBhrND00D9BobO4Opa+VRnvGeabVVkiv/FrKvQ=; b=FQVmrDvWK2rQwhA914pxZ24dR3x7ZFD+/cawmNQbZLx2W64+TRxJScbrBH+g2Y9w6B dmhc6KIN+iIr46u16P4t+nMe5S3WgsNT3sK8V1HQQXn/57Xi2wjp9crnkJkDBfscy3ip RkxocviwrFHj/IRtKaJeQyb11U8Zpumiv8nLHanAs8DQxhdCzUmVweCiZwkikeE58ZxB fLzvVv7L43NxGQNqEnE6hzUps0YtcCfCf2D9+SQ1LPrsZdsB+2eo9KXS2izona8fvMt9 xVAcgCRBcOON0dXeT9/FEtgHH5qoJxbTX+HRffEeTJFDS6wb8MxaBbEpmKSLPUA2zlco FHFg== MIME-Version: 1.0 Received: by 10.60.29.230 with SMTP id n6mr10142194oeh.22.1343515371510; Sat, 28 Jul 2012 15:42:51 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sat, 28 Jul 2012 15:42:51 -0700 (PDT) In-Reply-To: References: <20120725155211.GA33971@onelab2.iet.unipi.it> Date: Sat, 28 Jul 2012 15:42:51 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: "Bjoern A. Zeeb" , Luigi Rizzo , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 22:42:52 -0000 On Sat, Jul 28, 2012 at 3:35 PM, Arnaud Lacombe wrote: > Hi, > > On Sat, Jul 28, 2012 at 6:14 PM, Bjoern A. Zeeb > wrote: >> On Wed, 25 Jul 2012, Luigi Rizzo wrote: >> >>> During some ipfw/dummynet cleanup i noticed that the libkern version of >>> inet_ntoa_r() is missing the buffer size argument that is present in >>> the libc counterpart. >>> >>> Any objection if i fix it ? >> >> >> And why exactly would you need it? What does libc do with it? Render >> partial IPv4 addresses? >> > Mitigate possibilities of memory corruption ? At the very least, allow > the following: > > { > char tmp[sizeof "255.255.255.255"]; > > KASSERT(size >= (sizeof tmp)); > [...] > } > > to be enforced... but hey, who gives a damn about consistently doing > things and enforcing code assumptions ? ;-) I think that a subtlety in Bjoern's reply was missed. Note that inet_ntoa is guaranteed to only work with IPv4, not IPv4+IPv6, like inet_ntop. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 22:44:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 429AF106566B for ; Sat, 28 Jul 2012 22:44:34 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id E27628FC16 for ; Sat, 28 Jul 2012 22:44:33 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 15C6F25D3888; Sat, 28 Jul 2012 22:44:33 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 39C68BE8553; Sat, 28 Jul 2012 22:44:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id fsL329NW6tQ7; Sat, 28 Jul 2012 22:44:30 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B1C9ABE8552; Sat, 28 Jul 2012 22:44:30 +0000 (UTC) Date: Sat, 28 Jul 2012 22:44:29 +0000 (UTC) From: "Bjoern A. Zeeb" To: Arnaud Lacombe In-Reply-To: Message-ID: References: <20120725155211.GA33971@onelab2.iet.unipi.it> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 22:44:34 -0000 On Sat, 28 Jul 2012, Arnaud Lacombe wrote: > Hi, > > On Sat, Jul 28, 2012 at 6:14 PM, Bjoern A. Zeeb > wrote: >> On Wed, 25 Jul 2012, Luigi Rizzo wrote: >> >>> During some ipfw/dummynet cleanup i noticed that the libkern version of >>> inet_ntoa_r() is missing the buffer size argument that is present in >>> the libc counterpart. >>> >>> Any objection if i fix it ? >> >> >> And why exactly would you need it? What does libc do with it? Render >> partial IPv4 addresses? >> > Mitigate possibilities of memory corruption ? At the very least, allow > the following: > > { > char tmp[sizeof "255.255.255.255"]; char tmp[INET_ADDRSTRLEN]; > > KASSERT(size >= (sizeof tmp)); This would need to go into the called library function and cannot. > [...] So that gives you what extra checking exactly? That the programmer got the sizeof right rather than the buffer size? You pushed some more on the stack or reused an register for something that is supposed to be at a minial fixed length (nothing else lower allowed and will ever result in anything but misbehaviour) no matter what. It's not like it's inet_pton which can take totally different sizes. Which again leaves me with the question - why does libc have it? /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 23:16:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AD05106564A for ; Sat, 28 Jul 2012 23:16:02 +0000 (UTC) (envelope-from lacombar@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 AFF078FC21 for ; Sat, 28 Jul 2012 23:16:01 +0000 (UTC) Received: by weyx56 with SMTP id x56so3383602wey.13 for ; Sat, 28 Jul 2012 16:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=05KygHWNThcV6CzudxTlOUnsp+j9SdkqdSzRzXZT+A0=; b=dP9yqEsHzkOoJzs+AnZw2GuXoYg5rphsg4RR/zL2eL7k6ymjsVn3esfVpJbmoqQSJX HI+psNXJk985GSTzq5tloDZTUM9Cm335stZZVR7PhJRK8Ebub0rIeAYbYCyfWAwy8Nb2 kgG4jABhjqaPC6vLG0EB3IoWL8zv8pgiId959otDzh9jWEjiWeIGh3GaIBExyma+GfrG D3g9aUwF66ubHCN8CBUkF5yQKiHnUUfwI7HBjjMjnONbsAI0zmXIRjHqr+qiZ0dm7qqb HGTun4Bdg1h9FWASAMCtZKlXt6ru0TXP/T1oh9EM1VNNSN/d8I1aEYXJJ5QNB8Pb4fqJ 2JgA== MIME-Version: 1.0 Received: by 10.216.183.140 with SMTP id q12mr3131225wem.58.1343517360607; Sat, 28 Jul 2012 16:16:00 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 16:16:00 -0700 (PDT) In-Reply-To: References: <20120725155211.GA33971@onelab2.iet.unipi.it> Date: Sat, 28 Jul 2012 19:16:00 -0400 Message-ID: From: Arnaud Lacombe To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 23:16:02 -0000 Hi, On Sat, Jul 28, 2012 at 6:44 PM, Bjoern A. Zeeb wrote: > On Sat, 28 Jul 2012, Arnaud Lacombe wrote: > >> Hi, >> >> On Sat, Jul 28, 2012 at 6:14 PM, Bjoern A. Zeeb >> wrote: >>> >>> On Wed, 25 Jul 2012, Luigi Rizzo wrote: >>> >>>> During some ipfw/dummynet cleanup i noticed that the libkern version of >>>> inet_ntoa_r() is missing the buffer size argument that is present in >>>> the libc counterpart. >>>> >>>> Any objection if i fix it ? >>> >>> >>> >>> And why exactly would you need it? What does libc do with it? Render >>> partial IPv4 addresses? >>> >> Mitigate possibilities of memory corruption ? At the very least, allow >> the following: >> >> { >> char tmp[sizeof "255.255.255.255"]; > char tmp[INET_ADDRSTRLEN]; > Should I mention that this is taken directly from `lib/libc/inet/inet_ntop.c' ? you may want to fix it, as you have been blessed with a commit bit. >> >> KASSERT(size >= (sizeof tmp)); > > This would need to go into the called library function and cannot. > > So that gives you what extra checking exactly? That the programmer got > the sizeof right rather than the buffer size? You pushed some more on the > stack or reused an register That is funny. I was told that 2 always unused extra argument all along the mutex API could not change anything, and now I am told the opposite for 1 argument. There is no point trading the cost of a register for overall runtime correctness. This is a string manipulation function, it must be doing some kind of size check. > for something that is supposed to be at a minial fixed length > "supposed to be" ? you do not seem to be really sure to know how inet_ntoa_r() is gonna be used, nor have you any way, by your words, enforce it in any way. > (nothing else lower allowed and will ever result > in anything but misbehaviour) no matter what. > I'd be more than happy to welcome you tracking down memory corruption based misbehaviors, but I prefer to detect it before, than attempt to catch it after, it happens. > It's not like it's > inet_pton which can take totally different sizes. > that's nothing but an implementation details. > > Which again leaves me with the question - why does libc have it? > It is passed down to strlcpy(). You could have found this out by yourself in a minute or so... But again, implementation details, might they be incomplete, are irrelevant. - Arnaud From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 23:46:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 491C5106564A for ; Sat, 28 Jul 2012 23:46:15 +0000 (UTC) (envelope-from lacombar@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 CDA138FC08 for ; Sat, 28 Jul 2012 23:46:14 +0000 (UTC) Received: by weyx56 with SMTP id x56so3391910wey.13 for ; Sat, 28 Jul 2012 16:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tM7MD7Ut/0EpaeVknxZFVcwRU93RDSQ5dY550ZwKRAQ=; b=Wv+nG1MRh5eomMOfQZufCz+TTrFmY14Dg3w2nGslXjtqScHDSjj3LiLncjcT14Znx0 u5QC9oXcXkx9FFIwZJEkAuhcsWtrAqRWZY01ltUz57sl/gplezJxvCTsIDJ1RuN4krJk mbcTWnLo73+LIMXsctyGAmQfDp7PDIere6Y6snMonlRWdk7jSzmuSYjkZ8FjMV8Jhe2u 56iyQ2mHOeh+G2kX79Z3RVjJv4oykqN4JE2Lgg6KxLd2g7Skz5x0mMLtAGr5OC0K+8Zt xSlIXAQoP7y08SjxMs5Qkw9Zr+q96IYxt1WgiS86PoMO3YY1KkCSxa9aYmlGtP5N/TUr voPQ== MIME-Version: 1.0 Received: by 10.180.103.136 with SMTP id fw8mr16039026wib.20.1343519173686; Sat, 28 Jul 2012 16:46:13 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 16:46:13 -0700 (PDT) In-Reply-To: References: <20120725155211.GA33971@onelab2.iet.unipi.it> Date: Sat, 28 Jul 2012 19:46:13 -0400 Message-ID: From: Arnaud Lacombe To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 23:46:15 -0000 Hi, On Sat, Jul 28, 2012 at 6:44 PM, Bjoern A. Zeeb wrote: > Which again leaves me with the question - why does libc have it? > as for the semantic, theoretical, "why", I would refer you to the POSIX's comity, as inet_ntop() is part of it. - Arnaud