From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 02:02:28 2011 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 2F9FD106564A; Sun, 6 Nov 2011 02:02:28 +0000 (UTC) (envelope-from yanegomi@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 BB0338FC12; Sun, 6 Nov 2011 02:02:27 +0000 (UTC) Received: by ywt32 with SMTP id 32so5204770ywt.13 for ; Sat, 05 Nov 2011 19:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=z3ZDFIcTgxeNkcZCEJntG/adnuQpBC/830yASi5gS+Q=; b=MJRSSEm6lC4MKhgAR0SrBhLtg4c5hK15Wh6CKahg4Pu37fGbZTToyEGLEhnQ1/TKMW Tqg0LULxUiyYo6+b2KzX6Nt5+ujiuPtcslxCs5XdEBbuw0VPNtTffoCfl7hzZt3Vd0Vh Q9mv5oHeirILiUM0uaXqg/PJ/K5wKxfpQN/lA= Received: by 10.50.17.197 with SMTP id q5mr27679534igd.2.1320544946892; Sat, 05 Nov 2011 19:02:26 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id y6sm23295851pbi.5.2011.11.05.19.02.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 19:02:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4E9D8FBF.3030502@FreeBSD.org> Date: Sat, 5 Nov 2011 19:02:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23A28BD1-8F02-42D3-8BE3-0F90C3702955@gmail.com> References: <4E8D7406.4090302@restart.be> <4E8D86A2.1040508@FreeBSD.org> <4E8D9F57.70506@restart.be> <4E8DAEE5.4020004@FreeBSD.org> <4E9D566F.1040104@restart.be> <4E9D8FBF.3030502@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: Henri Hennebert , freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfsloader 9.0 BETA3 r225759 - i/o error - all block copies unavailable 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, 06 Nov 2011 02:02:28 -0000 On Oct 18, 2011, at 7:39 AM, Andriy Gapon wrote: > on 18/10/2011 13:35 Henri Hennebert said the following: >> I upgrade another system to 9.0-RC1 and encounter the same problem, = this time >> zfsloader do not run. >>=20 >> After >>=20 >> mv /mnt/boot /mnt/Boot >> mkdir /mnt/boot >> cd /mnt/Boot >> find . | cpio -pvdmu /mnt/boot >>=20 >> FreeBSD boot OK >>=20 >>=20 >> [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 = /dev/ada1p2 >> ZFS: SPA version 28 >> pool: rpool >> config: >>=20 >> NAME STATE >> rpool ONLINE >> mirror ONLINE >> ada0p2 ONLINE >> ada1p2 ONLINE >> ZFS: i/o error - all block copies unavailable >> can't lookup >>=20 >> 10 minutes later: >>=20 >> [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 >> /dev/ada1p2|less >> ZFS: SPA version 28 >> pool: rpool >> config: >>=20 >> NAME STATE >> rpool ONLINE >> mirror ONLINE >> ada0p2 ONLINE >> ada1p2 ONLINE >> >>=20 >> it seems ok :-o >>=20 >> and a other time: >> [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 >> segmentation fault... >>=20 >> Strange isn't it. >=20 > I think that it would be smart to not do any filesystem modifications = after the > problem is detected / reproduced. > Also, currently zfsboottest doesn't do much of a problem = self-diagnostics, so > using gdb or/and adding some printfs in the code are required to = understand a > nature of a problem. Like what kind of block gives an I/O error, if = it actual > reading that fails or checksum verification or etc, and so on. Running into the same issue with a post-RC1 kernel. 1. ZFS on root. 2. stable/9. 3. Here's my zpool status output: $ zpool status pool: sac state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM sac ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 errors: No known data errors pool: store state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM store ONLINE 0 0 0 mfid0p1 ONLINE 0 0 0 errors: No known data errors $ sudo ./zfsboottest /boot/zfsloader /dev/ada0p3=20 # Spits out the zpool status and a lot of other boot gobbledygook. If I use the new gptzfsboot, then my system becomes unbootable = with the old kernel (it can't find the zpool). gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ada0 It spits out "I/O error - all block copies unavailable" at boot; = if I manually did boot , then everything worked. So I figured it = was an environmental issue. I changed /boot/kernel from a symlink to a = kernel directory to a standard directory and things worked as expected. Your issue might be similar, but it would be nice if booting = from symlinks was either fixed or enhanced to work properly with = gptzfsboot. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 12:43:35 2011 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 E0EF31065674; Sun, 6 Nov 2011 12:43:35 +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 7B3188FC1B; Sun, 6 Nov 2011 12:43:35 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA6ChWk6012841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2011 14:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA6ChWlY054793; Sun, 6 Nov 2011 14:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA6ChVrE054792; Sun, 6 Nov 2011 14:43:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Nov 2011 14:43:31 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111106124331.GP50300@deviant.kiev.zoral.com.ua> References: <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iK/U8+IrLmbLL9vI" Content-Disposition: inline In-Reply-To: <4EB595FA.4020500@rice.edu> 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=-3.9 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: mdf@freebsd.org, "K. Macy" , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 06 Nov 2011 12:43:36 -0000 --iK/U8+IrLmbLL9vI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2011 at 03:00:58PM -0500, Alan Cox wrote: > On 11/05/2011 10:15, Kostik Belousov wrote: > >On Sat, Nov 05, 2011 at 07:37:48AM -0700, mdf@freebsd.org wrote: > >>On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov = =20 > >>wrote: > >>>On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: > >>> > >>>Below is the KBI patch after vm_page_bits_t merge is done. > >>>Again, I did not spent time converting all in-tree consumers > >>>from the (potentially) loadable modules to the new KPI until it > >>>is agreed upon. > >>I like my bikeshed orange... > >> > >>I would think a more canonical name would be get/set rather than > >>read/write, especially since these operations aren't reading and > >>writing the page (neither are they getting the page, but at least set > >>is pretty unambiguous). > >Look at the vm_page.h:385. vm_page_set_valid() is already taken. >=20 > I don't feel good about creating an interface under which we have=20 > functions named vm_page_set_valid() and vm_page_write_valid(). I think= =20 > that we should take a step back and look at the whole of set of=20 > functions that exist for manipulating the page's valid and dirty field=20 > and see if we can come up with a logical schema for naming them. I=20 > wouldn't then be surprised if this results in renaming some of the=20 > existing functions. >=20 > However, this should not delay the changes to address the vm_page_lock=20 > problem. I had two questions about that part of your patch. First, is= =20 > there any reason that you didn't include vm_page_lockptr()? If we=20 > created the page locking macros that you, jhb@, and I were talking about= =20 > last week, then vm_page_lockptr() would be required. Second, there=20 > seems to be precedent for naming the locking functions _vm_page_lock()=20 > instead of vm_page_lock_func(), for example, the mutex code, i.e.,=20 > sys/mutex.h, and the vm map locking functions. I think vm_page_lockptr() should be included when some kind of reloc-iterating macros are actually introduced into the tree. And, I have a hope that they can be wrapped around a function with the signature like void vm_page_relock(vm_page_t locked_page, vm_page_t unlocked_page); which moves the lock from locked_page to unlocked_page. Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has a lot of violations in regard of the namespaces, IMO. The __* namespace is reserved for the language implementation, so our freestanding program (kernel) ignores the requirements of the C standard with the names like __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes it not unreasonable for other developers to introduce reserved names. So I decided to use the suffixes. vm_map.h locking is free of these violations. --iK/U8+IrLmbLL9vI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk62gPMACgkQC3+MBN1Mb4hMmQCeNIkyDL5uP3ZfnsmDyF0/vRFn X3QAnAo1an3qCsI+jdgUxl9Pk6ZTMDFV =MZ3u -----END PGP SIGNATURE----- --iK/U8+IrLmbLL9vI-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 15:22:53 2011 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 6324B106564A; Sun, 6 Nov 2011 15:22:53 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB7D28FC15; Sun, 6 Nov 2011 15:22:52 +0000 (UTC) Received: by ggnk3 with SMTP id k3so3806511ggn.13 for ; Sun, 06 Nov 2011 07:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4Vcy9s/WvKzLpmg41Gqq4Yi8G7gEVA4f8NoCKre0/Yc=; b=wITo5NqcSLY7wR7f8Xcw7+dJbrzCcRQHCn2nENYX8p3Qqh6MhEydIONcKjOCD1vNXp T3ileXqmPoP52R6MzveHcbSUZUYtIi2AjkqnE5XJrBxa9AQbljsKfVOM04PJdm1zAHVl 3tcPfqgABCpWQFdDI1khwKvFfqwMLoxOkgwMI= MIME-Version: 1.0 Received: by 10.50.88.199 with SMTP id bi7mr33520999igb.45.1320592971879; Sun, 06 Nov 2011 07:22:51 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.49.35 with HTTP; Sun, 6 Nov 2011 07:22:51 -0800 (PST) In-Reply-To: <20111106124331.GP50300@deviant.kiev.zoral.com.ua> References: <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> Date: Sun, 6 Nov 2011 07:22:51 -0800 X-Google-Sender-Auth: DtaeaDnQlAnu4G85AyWcnFCnl8I Message-ID: From: mdf@FreeBSD.org To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 06 Nov 2011 15:22:53 -0000 On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov wrote: > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has > a lot of violations in regard of the namespaces, IMO. The __* namespace > is reserved for the language implementation, so our freestanding program > (kernel) ignores the requirements of the C standard with the names like > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes > it not unreasonable for other developers to introduce reserved names. > So I decided to use the suffixes. vm_map.h locking is free of these > violations. I'm pretty sure that when the C standard says, "the implementation", they're referring to the compiler and OS it runs on. Which makes the FreeBSD kernel part of "the implementation", which is precisely why so many headers have defines that start with __ and then, if certain posix defines are set, also uses non-__ versions of the name. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 15:41:51 2011 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 0433C1065672 for ; Sun, 6 Nov 2011 15:41:51 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB1348FC0C for ; Sun, 6 Nov 2011 15:41:50 +0000 (UTC) Received: by gyd5 with SMTP id 5so4521336gyd.13 for ; Sun, 06 Nov 2011 07:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=bohe28sUEIH2Ykys0u4goD4zpH6qZrjd5e33g/4gkbY=; b=OVsJCZqUOF+TRaTm+/AuCDEUIys+DRtinbp2Djk7wbUgrqSchuX16PlYiQwBVkC2T/ GGNM96FrT1DUBjOuBDj3y6Zi+jWqSntNQZTewLzl5c7MY7FzMszbYyex4Oz9OYRQTHQW oabQ+P7JXDCSZPfnDPZrlfebLLnOgC7xrPP+Y= MIME-Version: 1.0 Received: by 10.236.190.130 with SMTP id e2mr29908901yhn.107.1320594109936; Sun, 06 Nov 2011 07:41:49 -0800 (PST) Received: by 10.150.225.9 with HTTP; Sun, 6 Nov 2011 07:41:49 -0800 (PST) Date: Sun, 6 Nov 2011 17:41:49 +0200 Message-ID: From: Alexander Yerenkow To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem compiling kernel 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, 06 Nov 2011 15:41:51 -0000 Hello all! I have sources: Path: . URL: http://svn.freebsd.org/base/stable/9 Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 227206 Node Kind: directory Schedule: normal Last Changed Author: dougb Last Changed Rev: 227146 Last Changed Date: 2011-11-06 09:50:25 +0200 (=D7=D3, 06 =CE=CF=D1 2011) And problem compiling kernel for amd64 arch. I attached full log: http://www.box.net/shared/juajg1o2lg1mxbht5x9b I find somewhere that to build kernel I need to have world build; So, world built just fine before I tried to build kernel. Also, just in case I've updated (binary way) host to: FreeBSD testpc 9.0-RC1 FreeBSD 9.0-RC1 #0: Tue Oct 18 18:51:43 UTC 2011 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 The problem persist, can't compile kernel. My config is: include GENERIC ident MYK machine amd64 # Bus support. device isa # Pseudo devices. device mem # Memory and kernel memory devices device io # I/O device # UART chips on this platform device uart_ns8250 # Default partitioning schemes options GEOM_PART_BSD options GEOM_PART_EBR options GEOM_PART_EBR_COMPAT options GEOM_PART_MBR options NEW_PCIB device pf device pflog device pfsync options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_NAT options IPDIVERT While I'm waiting for any help, I'll try to compile GENERIC. Thanks! --=20 Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 16:42:08 2011 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 AAA83106566B; Sun, 6 Nov 2011 16:42:08 +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 447498FC15; Sun, 6 Nov 2011 16:42:07 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA6Gg49g030995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2011 18:42:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA6Gg4dB055635; Sun, 6 Nov 2011 18:42:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA6Gg4x6055634; Sun, 6 Nov 2011 18:42:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Nov 2011 18:42:04 +0200 From: Kostik Belousov To: mdf@freebsd.org Message-ID: <20111106164204.GY50300@deviant.kiev.zoral.com.ua> References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IUUPtLpdNqNE81UU" 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=-3.9 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: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 06 Nov 2011 16:42:08 -0000 --IUUPtLpdNqNE81UU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 06, 2011 at 07:22:51AM -0800, mdf@freebsd.org wrote: > On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov wro= te: > > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has > > a lot of violations in regard of the namespaces, IMO. The __* namespace > > is reserved for the language implementation, so our freestanding program > > (kernel) ignores the requirements of the C standard with the names like > > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes > > it not unreasonable for other developers to introduce reserved names. > > So I decided to use the suffixes. vm_map.h locking is free of these > > violations. >=20 > I'm pretty sure that when the C standard says, "the implementation", > they're referring to the compiler and OS it runs on. Which makes the > FreeBSD kernel part of "the implementation", which is precisely why so > many headers have defines that start with __ and then, if certain > posix defines are set, also uses non-__ versions of the name. For libc providing parts, required by standard, you are right. But our kernel is a freestanding program using a compiler, so in-kernel uses of the reserved namespace is a violation. --IUUPtLpdNqNE81UU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk62uNsACgkQC3+MBN1Mb4gqpQCfQdG7yhZaVm0lbGb75HOrT0jJ YQAAoN1NhUXeIIzgUP2IXY/JRoZQq/MX =nf9h -----END PGP SIGNATURE----- --IUUPtLpdNqNE81UU-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 19:28:48 2011 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 99E971065673; Sun, 6 Nov 2011 19:28:48 +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 6D64E8FC1A; Sun, 6 Nov 2011 19:28:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA6JSgaY090511; Sun, 6 Nov 2011 14:28:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA6JSgFv090492; Sun, 6 Nov 2011 19:28:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 Nov 2011 19:28:42 GMT Message-Id: <201111061928.pA6JSgFv090492@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: Sun, 06 Nov 2011 19:28:48 -0000 TB --- 2011-11-06 18:46:21 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-06 18:46:21 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-06 18:46:21 - cleaning the object tree TB --- 2011-11-06 18:46:38 - cvsupping the source tree TB --- 2011-11-06 18:46:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-06 18:46:52 - building world TB --- 2011-11-06 18:46:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-06 18:46:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-06 18:46:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-06 18:46:52 - SRCCONF=/dev/null TB --- 2011-11-06 18:46:52 - TARGET=powerpc TB --- 2011-11-06 18:46:52 - TARGET_ARCH=powerpc64 TB --- 2011-11-06 18:46:52 - TZ=UTC TB --- 2011-11-06 18:46:52 - __MAKE_CONF=/dev/null TB --- 2011-11-06 18:46:52 - cd /src TB --- 2011-11-06 18:46:52 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 6 18:46:53 UTC 2011 >>> 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 [...] ===> libexec/atrun (all) cc -O2 -pipe -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/src/libexec/atrun/../../usr.bin/at -I/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/atrun/atrun.c cc -O2 -pipe -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/src/libexec/atrun/../../usr.bin/at -I/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/atrun/gloadavg.c cc -O2 -pipe -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/src/libexec/atrun/../../usr.bin/at -I/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil atrun.o:(.got+0x28): undefined reference to `effective_uid' atrun.o:(.got+0x30): undefined reference to `effective_gid' atrun.o:(.got+0x40): undefined reference to `real_gid' atrun.o:(.got+0x48): undefined reference to `real_uid' *** Error code 1 Stop in /src/libexec/atrun. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-06 19:28:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-06 19:28:41 - ERROR: failed to build world TB --- 2011-11-06 19:28:42 - 1811.48 user 473.18 system 2540.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 19:56:42 2011 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 13DD4106564A for ; Sun, 6 Nov 2011 19:56:42 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id CA7E48FC19 for ; Sun, 6 Nov 2011 19:56:41 +0000 (UTC) Received: by ggnk3 with SMTP id k3so4049694ggn.13 for ; Sun, 06 Nov 2011 11:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HMcIkhkctVcpJCHoA+mT1mS5ARvCOzD2HJC99wXoLBY=; b=CgM/laog2ptgSKlOiaaCjYO47atOI6N7pwIrd0GIs7PVctJXGNEdODInuAAYjBORHH zdV1GgYOEzX2hDI3MGxAPZM1vqVB3yEKk8MJvmoeT9wA9aB26swKwvaW3myhjTA6aN7v sog62qVdHOYfKij3TDYmMNgxz2Wk6/kAMNun4= MIME-Version: 1.0 Received: by 10.182.212.33 with SMTP id nh1mr6364031obc.72.1320609400963; Sun, 06 Nov 2011 11:56:40 -0800 (PST) Received: by 10.182.42.104 with HTTP; Sun, 6 Nov 2011 11:56:40 -0800 (PST) Date: Sun, 6 Nov 2011 20:56:40 +0100 Message-ID: From: Oliver Pinter To: acpi@freebsd.org Content-Type: multipart/mixed; boundary=e89a8f50398a3b419804b116563c Cc: current@freebsd.org Subject: [PATCH][acpi_thermal] add dimension 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, 06 Nov 2011 19:56:42 -0000 --e89a8f50398a3b419804b116563c Content-Type: text/plain; charset=ISO-8859-1 Hi all! $subject --e89a8f50398a3b419804b116563c Content-Type: text/x-diff; charset=US-ASCII; name="acpi_thermal.patch" Content-Disposition: attachment; filename="acpi_thermal.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 RnJvbSBjNDZmNjVjMmQ1M2VmM2JkOGJjYzg3N2JiOWRhNTE4YTUyNGQ3YzFiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBPbGl2ZXIgUGludGVyIDxvcG5Ab3BuLihub25lKT4KRGF0ZTog U3VuLCA2IE5vdiAyMDExIDIwOjQ5OjE2ICswMTAwClN1YmplY3Q6IFtQQVRDSF0gc3BlY2lmeSBw b2xsaW5nX3JhdGUgZGltZW5zaW9uCgpTaWduZWQtb2ZmLWJ5OiBPbGl2ZXIgUGludGVyIDxvbGl2 ZXIucG50ckBnbWFpbC5jb20+CgpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9hY3BpY2EvYWNwaV90aGVy bWFsLmMgYi9zeXMvZGV2L2FjcGljYS9hY3BpX3RoZXJtYWwuYwppbmRleCAxODk5NmJkLi40MzI2 N2I0IDEwMDY0NAotLS0gYS9zeXMvZGV2L2FjcGljYS9hY3BpX3RoZXJtYWwuYworKysgYi9zeXMv ZGV2L2FjcGljYS9hY3BpX3RoZXJtYWwuYwpAQCAtMjQ1LDcgKzI0NSw3IEBAIGFjcGlfdHpfYXR0 YWNoKGRldmljZV90IGRldikKIAlTWVNDVExfQUREX0lOVCgmYWNwaV90el9zeXNjdGxfY3R4LAog CQkgICAgICAgU1lTQ1RMX0NISUxEUkVOKGFjcGlfdHpfc3lzY3RsX3RyZWUpLAogCQkgICAgICAg T0lEX0FVVE8sICJwb2xsaW5nX3JhdGUiLCBDVExGTEFHX1JXLAotCQkgICAgICAgJmFjcGlfdHpf cG9sbGluZ19yYXRlLCAwLCAibW9uaXRvciBwb2xsaW5nIHJhdGUiKTsKKwkJICAgICAgICZhY3Bp X3R6X3BvbGxpbmdfcmF0ZSwgMCwgIm1vbml0b3IgcG9sbGluZyByYXRlIGluIHNlYyIpOwogCVNZ U0NUTF9BRERfSU5UKCZhY3BpX3R6X3N5c2N0bF9jdHgsCiAJCSAgICAgICBTWVNDVExfQ0hJTERS RU4oYWNwaV90el9zeXNjdGxfdHJlZSksIE9JRF9BVVRPLAogCQkgICAgICAgInVzZXJfb3ZlcnJp ZGUiLCBDVExGTEFHX1JXLCAmYWNwaV90el9vdmVycmlkZSwgMCwK --e89a8f50398a3b419804b116563c-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 20:04:41 2011 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 A736F106566B; Sun, 6 Nov 2011 20:04:41 +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 4BBF78FC12; Sun, 6 Nov 2011 20:04:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA6K4dTN008556; Sun, 6 Nov 2011 15:04:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA6K4dN0008551; Sun, 6 Nov 2011 20:04:39 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 Nov 2011 20:04:39 GMT Message-Id: <201111062004.pA6K4dN0008551@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: Sun, 06 Nov 2011 20:04:41 -0000 TB --- 2011-11-06 19:28:42 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-06 19:28:42 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-06 19:28:42 - cleaning the object tree TB --- 2011-11-06 19:28:53 - cvsupping the source tree TB --- 2011-11-06 19:28:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-06 19:29:17 - building world TB --- 2011-11-06 19:29:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-06 19:29:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-06 19:29:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-06 19:29:17 - SRCCONF=/dev/null TB --- 2011-11-06 19:29:17 - TARGET=sparc64 TB --- 2011-11-06 19:29:17 - TARGET_ARCH=sparc64 TB --- 2011-11-06 19:29:17 - TZ=UTC TB --- 2011-11-06 19:29:17 - __MAKE_CONF=/dev/null TB --- 2011-11-06 19:29:17 - cd /src TB --- 2011-11-06 19:29:17 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 6 19:29:18 UTC 2011 >>> 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 [...] atrun.c:(.text+0xa2c): undefined reference to `real_uid' atrun.c:(.text+0xa40): undefined reference to `real_gid' atrun.c:(.text+0xa44): undefined reference to `effective_uid' atrun.c:(.text+0xa4c): undefined reference to `effective_uid' atrun.c:(.text+0xa50): undefined reference to `effective_gid' atrun.c:(.text+0xa54): undefined reference to `effective_gid' atrun.c:(.text+0xa5c): undefined reference to `real_gid' atrun.c:(.text+0xa64): undefined reference to `real_uid' *** Error code 1 Stop in /src/libexec/atrun. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-06 20:04:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-06 20:04:39 - ERROR: failed to build world TB --- 2011-11-06 20:04:39 - 1583.02 user 429.02 system 2156.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 20:56:58 2011 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 05DC31065670 for ; Sun, 6 Nov 2011 20:56:58 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id C0A3B8FC12 for ; Sun, 6 Nov 2011 20:56:57 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 240162A28CE3; Sun, 6 Nov 2011 21:31:56 +0100 (CET) Date: Sun, 6 Nov 2011 21:31:56 +0100 From: Ed Schouten To: current@freebsd.org Message-ID: <20111106203156.GP2258@hoeg.nl> References: <201111061928.pA6JSgFv090492@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CMx2Qe8y1jN1ar4Y" Content-Disposition: inline In-Reply-To: <201111061928.pA6JSgFv090492@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: [head tinderbox] failure on powerpc64/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: Sun, 06 Nov 2011 20:56:58 -0000 --CMx2Qe8y1jN1ar4Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * FreeBSD Tinderbox , 20111106 20:28: > atrun.o:(.got+0x28): undefined reference to `effective_uid' > atrun.o:(.got+0x30): undefined reference to `effective_gid' > atrun.o:(.got+0x40): undefined reference to `real_gid' > atrun.o:(.got+0x48): undefined reference to `real_uid' Sorry about that. Should be fixed now! --=20 Ed Schouten WWW: http://80386.nl/ --CMx2Qe8y1jN1ar4Y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOtu68AAoJEG5e2P40kaK7m2kP/2qFGZKyK0EW5lxXK83iwN1u fPoZpLv7J7W3HmGWETFoLhaFT4vTWbL3fdbGfHKOtEXb4T3GGoI9JTabjfK27/N0 gj7dFR6jOIMeXjmkmsdW4Tu83qKBwRRUUDtjsdJA+XOPoYxKx+ZnlknQgsBvrWsJ LphBi2Ha04b1TmfXpNxD7kl+8GB6XcDtznoY0Bn4APMHiep5jc853PYpSq3NlD3x WymQKccLYW+55ew82H83dmPxq9CMzJpBXIDXKS/N61e/6+HrjSGYlcDiilfii0Sq mTtoz9VY7we6mCI2y+jQIat6iLu1zwnl9R02R0KqpPuMBgD43WY6P9hjWlO4B2e3 /LfB7wBgGr8UL6NgPKa4D0BwECDJ7uIRi3lvs/jVavdNwXq0yLz1g4UT0Zz8UXwq AB2FP4Bf13KYpEjrIBhFR0a1SZL9ydjr8BWmtUoCvUPUDdihqWzQ4COA0dXF/N9r 5PlX8vn/birKtT/qIa1dU1Kjw39b/bfk1fA4cEmOWHZUsORWjiMlZt04PuZPnK9G P4ZgNb2fMX+V1QgVAeKPt09yXvsSRN6MbBbGyVAar8B4DXkRBcy8bxmdR+VC8SdJ GoSCCieE6lYvhpatarmc+k8w67MQbaweaL56SGNpDvbS1uxJMv6sMOlcoijyQAio rr9zDmx9CMU4KbtQ/Lvw =Mvyq -----END PGP SIGNATURE----- --CMx2Qe8y1jN1ar4Y-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 21:15:44 2011 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 755D5106566C; Sun, 6 Nov 2011 21:15:44 +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 962348FC19; Sun, 6 Nov 2011 21:15:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA6LFbds078600; Sun, 6 Nov 2011 16:15:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA6LFW4v078399; Sun, 6 Nov 2011 21:15:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 Nov 2011 21:15:32 GMT Message-Id: <201111062115.pA6LFW4v078399@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 arm/arm 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: Sun, 06 Nov 2011 21:15:44 -0000 TB --- 2011-11-06 20:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-06 20:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-06 20:40:00 - cleaning the object tree TB --- 2011-11-06 20:40:40 - cvsupping the source tree TB --- 2011-11-06 20:40:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-06 20:40:59 - building world TB --- 2011-11-06 20:40:59 - CROSS_BUILD_TESTING=YES TB --- 2011-11-06 20:40:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-06 20:40:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-06 20:40:59 - SRCCONF=/dev/null TB --- 2011-11-06 20:40:59 - TARGET=arm TB --- 2011-11-06 20:40:59 - TARGET_ARCH=arm TB --- 2011-11-06 20:40:59 - TZ=UTC TB --- 2011-11-06 20:40:59 - __MAKE_CONF=/dev/null TB --- 2011-11-06 20:40:59 - cd /src TB --- 2011-11-06 20:40:59 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 6 20:40:59 UTC 2011 >>> 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 [...] atrun.c:(.text+0x7cc): undefined reference to `effective_gid' atrun.c:(.text+0x7d4): undefined reference to `real_gid' atrun.c:(.text+0x7d8): undefined reference to `real_uid' atrun.o: In function `main': atrun.c:(.text+0xc28): undefined reference to `real_uid' atrun.c:(.text+0xc2c): undefined reference to `effective_uid' atrun.c:(.text+0xc30): undefined reference to `real_gid' atrun.c:(.text+0xc34): undefined reference to `effective_gid' *** Error code 1 Stop in /src/libexec/atrun. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-06 21:15:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-06 21:15:32 - ERROR: failed to build world TB --- 2011-11-06 21:15:32 - 1424.16 user 502.01 system 2131.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:03:37 2011 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 73C6A106566C; Sun, 6 Nov 2011 22:03:37 +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 15F978FC15; Sun, 6 Nov 2011 22:03:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA6M3a9a016828; Sun, 6 Nov 2011 17:03:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA6M3aco016827; Sun, 6 Nov 2011 22:03:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 Nov 2011 22:03:36 GMT Message-Id: <201111062203.pA6M3aco016827@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: Sun, 06 Nov 2011 22:03:37 -0000 TB --- 2011-11-06 21:15:37 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-06 21:15:37 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-06 21:15:37 - cleaning the object tree TB --- 2011-11-06 21:15:50 - cvsupping the source tree TB --- 2011-11-06 21:15:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-06 21:16:02 - building world TB --- 2011-11-06 21:16:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-06 21:16:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-06 21:16:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-06 21:16:02 - SRCCONF=/dev/null TB --- 2011-11-06 21:16:02 - TARGET=ia64 TB --- 2011-11-06 21:16:02 - TARGET_ARCH=ia64 TB --- 2011-11-06 21:16:02 - TZ=UTC TB --- 2011-11-06 21:16:02 - __MAKE_CONF=/dev/null TB --- 2011-11-06 21:16:02 - cd /src TB --- 2011-11-06 21:16:02 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 6 21:16:02 UTC 2011 >>> 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 [...] atrun.c:(.text+0x1d11): undefined reference to `real_uid' atrun.c:(.text+0x1d31): undefined reference to `real_uid' atrun.c:(.text+0x1d50): undefined reference to `real_gid' atrun.c:(.text+0x1d71): undefined reference to `real_gid' atrun.c:(.text+0x1df2): undefined reference to `effective_uid' atrun.c:(.text+0x1e00): undefined reference to `effective_uid' atrun.c:(.text+0x1e30): undefined reference to `effective_gid' atrun.c:(.text+0x1e31): undefined reference to `effective_gid' *** Error code 1 Stop in /src/libexec/atrun. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-06 22:03:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-06 22:03:35 - ERROR: failed to build world TB --- 2011-11-06 22:03:35 - 2155.01 user 492.27 system 2878.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:20:22 2011 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 A167C1065670; Sun, 6 Nov 2011 22:20:22 +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 4C0FE8FC12; Sun, 6 Nov 2011 22:20:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA6MKLoB049733; Sun, 6 Nov 2011 17:20:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA6MKLgv049703; Sun, 6 Nov 2011 22:20:21 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 Nov 2011 22:20:21 GMT Message-Id: <201111062220.pA6MKLgv049703@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/i386 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: Sun, 06 Nov 2011 22:20:22 -0000 TB --- 2011-11-06 20:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-06 20:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-06 20:40:00 - cleaning the object tree TB --- 2011-11-06 20:41:03 - cvsupping the source tree TB --- 2011-11-06 20:41:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-06 20:41:16 - building world TB --- 2011-11-06 20:41:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-06 20:41:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-06 20:41:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-06 20:41:16 - SRCCONF=/dev/null TB --- 2011-11-06 20:41:16 - TARGET=i386 TB --- 2011-11-06 20:41:16 - TARGET_ARCH=i386 TB --- 2011-11-06 20:41:16 - TZ=UTC TB --- 2011-11-06 20:41:16 - __MAKE_CONF=/dev/null TB --- 2011-11-06 20:41:16 - cd /src TB --- 2011-11-06 20:41:16 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 6 20:41:17 UTC 2011 >>> 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 [...] atrun.c:(.text+0x91a): undefined reference to `real_uid' atrun.o: In function `main': atrun.c:(.text+0xae6): undefined reference to `real_uid' atrun.c:(.text+0xb15): undefined reference to `real_gid' atrun.c:(.text+0xb1e): undefined reference to `effective_uid' atrun.c:(.text+0xb28): undefined reference to `effective_gid' atrun.c:(.text+0xb2d): undefined reference to `real_gid' atrun.c:(.text+0xb3a): undefined reference to `real_uid' *** Error code 1 Stop in /src/libexec/atrun. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-06 22:20:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-06 22:20:21 - ERROR: failed to build world TB --- 2011-11-06 22:20:21 - 4888.91 user 826.67 system 6020.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:20:42 2011 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 1864D106564A; Sun, 6 Nov 2011 22:20:42 +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 B1E1E8FC12; Sun, 6 Nov 2011 22:20:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA6MKffc051469; Sun, 6 Nov 2011 17:20:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA6MKf5D051457; Sun, 6 Nov 2011 22:20:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 Nov 2011 22:20:41 GMT Message-Id: <201111062220.pA6MKf5D051457@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: Sun, 06 Nov 2011 22:20:42 -0000 TB --- 2011-11-06 20:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-06 20:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-06 20:40:00 - cleaning the object tree TB --- 2011-11-06 20:40:37 - cvsupping the source tree TB --- 2011-11-06 20:40:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-06 20:40:59 - building world TB --- 2011-11-06 20:40:59 - CROSS_BUILD_TESTING=YES TB --- 2011-11-06 20:40:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-06 20:40:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-06 20:40:59 - SRCCONF=/dev/null TB --- 2011-11-06 20:40:59 - TARGET=pc98 TB --- 2011-11-06 20:40:59 - TARGET_ARCH=i386 TB --- 2011-11-06 20:40:59 - TZ=UTC TB --- 2011-11-06 20:40:59 - __MAKE_CONF=/dev/null TB --- 2011-11-06 20:40:59 - cd /src TB --- 2011-11-06 20:40:59 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 6 20:40:59 UTC 2011 >>> 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 [...] atrun.c:(.text+0x91a): undefined reference to `real_uid' atrun.o: In function `main': atrun.c:(.text+0xae6): undefined reference to `real_uid' atrun.c:(.text+0xb15): undefined reference to `real_gid' atrun.c:(.text+0xb1e): undefined reference to `effective_uid' atrun.c:(.text+0xb28): undefined reference to `effective_gid' atrun.c:(.text+0xb2d): undefined reference to `real_gid' atrun.c:(.text+0xb3a): undefined reference to `real_uid' *** Error code 1 Stop in /src/libexec/atrun. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-06 22:20:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-06 22:20:40 - ERROR: failed to build world TB --- 2011-11-06 22:20:40 - 4887.89 user 826.33 system 6040.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:21:50 2011 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 97CEA1065672; Sun, 6 Nov 2011 22:21:50 +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 44CF38FC27; Sun, 6 Nov 2011 22:21:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA6MLntF059773; Sun, 6 Nov 2011 17:21:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA6MLnlM059772; Sun, 6 Nov 2011 22:21:49 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 Nov 2011 22:21:49 GMT Message-Id: <201111062221.pA6MLnlM059772@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 amd64/amd64 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: Sun, 06 Nov 2011 22:21:50 -0000 TB --- 2011-11-06 20:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-06 20:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-06 20:40:00 - cleaning the object tree TB --- 2011-11-06 20:41:03 - cvsupping the source tree TB --- 2011-11-06 20:41:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-06 20:41:16 - building world TB --- 2011-11-06 20:41:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-06 20:41:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-06 20:41:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-06 20:41:16 - SRCCONF=/dev/null TB --- 2011-11-06 20:41:16 - TARGET=amd64 TB --- 2011-11-06 20:41:16 - TARGET_ARCH=amd64 TB --- 2011-11-06 20:41:16 - TZ=UTC TB --- 2011-11-06 20:41:16 - __MAKE_CONF=/dev/null TB --- 2011-11-06 20:41:16 - cd /src TB --- 2011-11-06 20:41:16 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 6 20:41:16 UTC 2011 >>> 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 [...] atrun.c:(.text+0x8f0): undefined reference to `real_uid' atrun.o: In function `main': atrun.c:(.text+0xaa7): undefined reference to `real_uid' atrun.c:(.text+0xaf3): undefined reference to `real_gid' atrun.c:(.text+0xafd): undefined reference to `effective_uid' atrun.c:(.text+0xb08): undefined reference to `real_gid' atrun.c:(.text+0xb0e): undefined reference to `effective_gid' atrun.c:(.text+0xb19): undefined reference to `real_uid' *** Error code 1 Stop in /src/libexec/atrun. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-06 22:21:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-06 22:21:49 - ERROR: failed to build world TB --- 2011-11-06 22:21:49 - 4931.68 user 828.86 system 6108.76 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 04:21:21 2011 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 5E9F11065670; Mon, 7 Nov 2011 04:21:21 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 871608FC0A; Mon, 7 Nov 2011 04:21:20 +0000 (UTC) Received: by wwp14 with SMTP id 14so6142099wwp.31 for ; Sun, 06 Nov 2011 20:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eEdJhLM/jDbRBYRBRrKJKfNdtA2PcIE5WvPsrTY5qi4=; b=EyBhqCnTTme+lGdiKEMjVnjFjt8sjbk8KBrBdQbqEsS3GWrxowRVAfu1ejpCWS1nsf JdX/bYgaL6IuufBYf5cZ/kaV7RsD77C9xAs4CtTZIFfK67lj6Qjo4OyY0Pr/cN06pQ48 I6GwewtpjWmFtp1SQtfFMFieAyOsopu+6Rgow= MIME-Version: 1.0 Received: by 10.180.93.168 with SMTP id cv8mr6802657wib.36.1320639679426; Sun, 06 Nov 2011 20:21:19 -0800 (PST) Received: by 10.180.80.195 with HTTP; Sun, 6 Nov 2011 20:21:19 -0800 (PST) In-Reply-To: <20111105141306.GW50300@deviant.kiev.zoral.com.ua> References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> Date: Sun, 6 Nov 2011 23:21:19 -0500 Message-ID: From: Arnaud Lacombe To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 04:21:21 -0000 Hi, On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov wrot= e: > On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: > > Below is the KBI patch after vm_page_bits_t merge is done. > Again, I did not spent time converting all in-tree consumers > from the (potentially) loadable modules to the new KPI until it > is agreed upon. > > diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c > index 305c189..7264cd1 100644 > --- a/sys/nfsclient/nfs_bio.c > +++ b/sys/nfsclient/nfs_bio.c > @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) > =A0 =A0 =A0 =A0 * can only occur at the file EOF. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0VM_OBJECT_LOCK(object); > - =A0 =A0 =A0 if (pages[ap->a_reqpage]->valid !=3D 0) { > + =A0 =A0 =A0 if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < npages; ++i) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (i !=3D ap->a_reqpage) = { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_lo= ck(pages[i]); > @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation filled a= n entire page > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D VM_PAGE_BITS_A= LL; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, VM_P= AGE_BITS_ALL); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dirty(= m) =3D=3D 0, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages: pa= ge %p is dirty", m)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (size > toff) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation filled a= partial page. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, 0); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_set_valid(m, 0, si= ze - toff); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dirty(= m) =3D=3D 0, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages: pa= ge %p is dirty", m)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > index 389aea5..2f41e70 100644 > --- a/sys/vm/vm_page.c > +++ b/sys/vm/vm_page.c > @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_dirty(m); > =A0} > > +void > +vm_page_lock_func(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); > +#endif > +} > + Why do you re-implement the wheel ? all the point of these assessors is to hide implementation detail. IMO, you should restrict yourself to the documented API from mutex(9), only. Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but wait LOCK_FILE is either just __FILE__, or NULL, depending on LOCK_DEBUG, but you wouldn't have those function without INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely fracked-up... If you don't want this code in INVARIANTS, but in LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. Btw, let me also question the use of non-inline functions. > +void > +vm_page_unlock_func(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); > +#endif > +} > + > +int > +vm_page_trylock_func(vm_page_t m, const char *file, int line) > +{ > + > + =A0 =A0 =A0 return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); > +} > + > +void > +vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line) > +{ > + > +#ifdef INVARIANTS > + =A0 =A0 =A0 _mtx_assert(vm_page_lockptr(m), a, file, line); > +#endif > +} > + same remark on all the above. > +vm_page_bits_t > +vm_page_read_dirty_func(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->dirty); > +} > + > +vm_page_bits_t > +vm_page_read_valid_func(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->valid); > +} > + > +void > +vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v) > +{ > + > + =A0 =A0 =A0 m->valid =3D v; > +} > + > + > =A0int so_zerocp_fullpage =3D 0; > > =A0/* > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 7099b70..4f8f71e 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -218,12 +218,50 @@ extern struct vpglocks pa_lock[]; > > =A0#define =A0 =A0 =A0 =A0PA_LOCK_ASSERT(pa, a) =A0 mtx_assert(PA_LOCKPTR= (pa), (a)) > > +#ifdef KLD_MODULE > +#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 vm_page_lock_func= ((m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 vm_page_unlock_func= ((m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0vm_page_trylock_fun= c((m), LOCK_FILE, LOCK_LINE) > +#ifdef INVARIANTS > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 \ > + =A0 =A0vm_page_lock_assert_func((m), (a), LOCK_FILE, LOCK_LINE) > +#else > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) > +#endif > + > +#define =A0 =A0 =A0 =A0vm_page_read_dirty(m) =A0 vm_page_read_dirty_func= ((m)) > +#define =A0 =A0 =A0 =A0vm_page_read_valid(m) =A0 vm_page_read_valid_func= ((m)) > +#define =A0 =A0 =A0 =A0vm_page_write_valid(m, v) =A0 =A0 =A0 vm_page_wri= te_valid_func((m), (v)) > + > +#else =A0/* KLD_MODULE */ > =A0#define =A0 =A0 =A0 =A0vm_page_lockptr(m) =A0 =A0 =A0(PA_LOCKPTR(VM_PA= GE_TO_PHYS((m)))) > =A0#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 mtx_lock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 mtx_unlock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0mtx_trylock(vm_pa= ge_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 mtx_asser= t(vm_page_lockptr((m)), (a)) > > +static inline vm_page_bits_t > +vm_page_read_dirty(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->dirty); > +} > + > +static inline vm_page_bits_t > +vm_page_read_valid(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->valid); > +} > + > +static inline void > +vm_page_write_valid(vm_page_t m, vm_page_bits_t v) > +{ > + > + =A0 =A0 =A0 m->valid =3D v; > +} > +#endif > + > =A0#define =A0 =A0 =A0 =A0vm_page_queue_free_mtx =A0vm_page_queue_free_lo= ck.data > =A0/* > =A0* These are the flags defined for vm_page. > @@ -403,6 +441,15 @@ void vm_page_cowfault (vm_page_t); > =A0int vm_page_cowsetup(vm_page_t); > =A0void vm_page_cowclear (vm_page_t); > > +void vm_page_lock_func(vm_page_t m, const char *file, int line); > +void vm_page_unlock_func(vm_page_t m, const char *file, int line); > +int vm_page_trylock_func(vm_page_t m, const char *file, int line); > +void vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int = line); > + > +vm_page_bits_t vm_page_read_dirty_func(vm_page_t m); > +vm_page_bits_t vm_page_read_valid_func(vm_page_t m); > +void vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v); > + > =A0#ifdef INVARIANTS > =A0void vm_page_object_lock_assert(vm_page_t m); > =A0#define =A0 =A0 =A0 =A0VM_PAGE_OBJECT_LOCK_ASSERT(m) =A0 vm_page_objec= t_lock_assert(m) > From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 04:50:43 2011 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 A06771065670; Mon, 7 Nov 2011 04:50:43 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ACC218FC08; Mon, 7 Nov 2011 04:50:42 +0000 (UTC) Received: by wwp14 with SMTP id 14so6156173wwp.31 for ; Sun, 06 Nov 2011 20:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NLFLH8PGWhfmVman1gua4f/f5+ttwYwsvkY+PLnib4U=; b=rMouRy42A7a1sbG9gt7f8MESymRTdOGV+TbhN+6Bhyaje9fqC7Usddas7kXbFn7F+7 gZMTytoJN43tMFxdNyMOYVxLPnsRrvUR1o5Uc4+75v6naXcb7vRYO0evQP0hNX7bwNSj xinQLPDfspwYeRHftxQnJDFZ2LvDKYUexZEAA= MIME-Version: 1.0 Received: by 10.180.3.33 with SMTP id 1mr6823680wiz.54.1320641441619; Sun, 06 Nov 2011 20:50:41 -0800 (PST) Received: by 10.180.80.195 with HTTP; Sun, 6 Nov 2011 20:50:41 -0800 (PST) In-Reply-To: <20111106164204.GY50300@deviant.kiev.zoral.com.ua> References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <20111106164204.GY50300@deviant.kiev.zoral.com.ua> Date: Sun, 6 Nov 2011 23:50:41 -0500 Message-ID: From: Arnaud Lacombe To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 04:50:43 -0000 Hi, On Sun, Nov 6, 2011 at 11:42 AM, Kostik Belousov wrot= e: > On Sun, Nov 06, 2011 at 07:22:51AM -0800, mdf@freebsd.org wrote: >> On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov wr= ote: >> > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has >> > a lot of violations in regard of the namespaces, IMO. The __* namespac= e >> > is reserved for the language implementation, so our freestanding progr= am >> > (kernel) ignores the requirements of the C standard with the names lik= e >> > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes >> > it not unreasonable for other developers to introduce reserved names. >> > So I decided to use the suffixes. vm_map.h locking is free of these >> > violations. >> >> I'm pretty sure that when the C standard says, "the implementation", >> they're referring to the compiler and OS it runs on. =A0Which makes the >> FreeBSD kernel part of "the implementation", which is precisely why so >> many headers have defines that start with __ and then, if certain >> posix defines are set, also uses non-__ versions of the name. > > For libc providing parts, required by standard, you are right. > But our kernel is a freestanding program using a compiler, so in-kernel > uses of the reserved namespace is a violation. > So you prefer to introduce a new notation which will confuses everybody for the sake of following an interpretation of the standard[0] ? Btw, which point of the standard are you quoting ? Section "7.1.3 Reserved identifiers" of ISO/IEC 9899 ? Thanks, - Arnaud ps: my vote is for a deep-sky-blue bikeshed. [0]: I'd be tempted to interpret "the implementation" as the non-visible part of an API, ie vm_page_lock() is public and rely on __vm_page_lock() for its implementation. As such, I would not consider "the kernel" as a single whole unit, but as a sum of public API and implementation. From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 08:54:03 2011 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 877E1106566B for ; Mon, 7 Nov 2011 08:54:03 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.freebsd.org (Postfix) with ESMTP id 0419B8FC0A for ; Mon, 7 Nov 2011 08:54:02 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail26.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pA78s03G024257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2011 19:54:00 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id pA77vYSl091505; Mon, 7 Nov 2011 18:57:34 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id pA77vYRG091504; Mon, 7 Nov 2011 18:57:34 +1100 (EST) (envelope-from peter) Date: Mon, 7 Nov 2011 18:57:34 +1100 From: Peter Jeremy To: Alexander Yerenkow Message-ID: <20111107075734.GC91353@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPJrCs/72TxItFYR" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Problem compiling kernel 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, 07 Nov 2011 08:54:03 -0000 --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow wrot= e: >And problem compiling kernel for amd64 arch. > >I attached full log: > >http://www.box.net/shared/juajg1o2lg1mxbht5x9b It looks like you did a parallel - in which case the actual error is buried somewhere in that output. Please repeat without any '-j' and post the last 50-100 lines of output. --=20 Peter Jeremy --GPJrCs/72TxItFYR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk63j24ACgkQ/opHv/APuIdEowCgrOoBn0VYF052rz5GoeCDo1sI nuEAoJ/KthygaDV0tUbDl9uBhCVwEzEJ =1wkd -----END PGP SIGNATURE----- --GPJrCs/72TxItFYR-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 09:00:05 2011 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 3A03A1065673 for ; Mon, 7 Nov 2011 09:00:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E73468FC13 for ; Mon, 7 Nov 2011 09:00:04 +0000 (UTC) Received: by qyk9 with SMTP id 9so3718939qyk.13 for ; Mon, 07 Nov 2011 01:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vBdDLNQQq6tLOPzeIEWRe1uyOZAW0sxaEnfPJq4IQQs=; b=uKE/bVedPlkvHs2la7iRKHEWzZMGjLOfdH4jsiXAiHkpOD5ct7ZIwJAwvxXNNEq7Pi PGoVieaCHuTcXlxwIzr0lBnN4PQ0RSwC+fur3fQLimFLvYdg4jqhFK/CmgoL/KkjNL3m MYyFgkqQi18lwmc3MIy31sP/MM6MQ+Xxlsmx4= Received: by 10.50.140.1 with SMTP id rc1mr43699387igb.25.1320656404030; Mon, 07 Nov 2011 01:00:04 -0800 (PST) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id p6sm22475207pbf.3.2011.11.07.01.00.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 01:00:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20111107075734.GC91353@server.vk2pj.dyndns.org> Date: Mon, 7 Nov 2011 00:59:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111107075734.GC91353@server.vk2pj.dyndns.org> To: Peter Jeremy X-Mailer: Apple Mail (2.1084) Cc: Alexander Yerenkow , freebsd-current@freebsd.org Subject: Re: Problem compiling kernel 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, 07 Nov 2011 09:00:05 -0000 On Nov 6, 2011, at 11:57 PM, Peter Jeremy wrote: > On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow = wrote: >> And problem compiling kernel for amd64 arch. >>=20 >> I attached full log: >>=20 >> http://www.box.net/shared/juajg1o2lg1mxbht5x9b >=20 > It looks like you did a parallel - in which case the actual error is > buried somewhere in that output. Please repeat without any '-j' > and post the last 50-100 lines of output. ip_fw_nat.o: In function = `del_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat= .c:123: undefined reference to `LibAliasRedirectDelete' ip_fw_nat.o: In function `ipfw_nat_destroy': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined = reference to `LibAliasUninit' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined = reference to `LibAliasUninit' ip_fw_nat.o: In function `ifaddr_change': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:80: undefined = reference to `LibAliasSetAddress' ip_fw_nat.o: In function `ipfw_nat_del': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:482: undefined = reference to `LibAliasUninit'ip_fw_nat.o: In function = `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:437:= undefined reference to = `LibAliasSetMode'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:43= 8: undefined reference to `LibAliasSetAddress' ip_fw_nat.o: In function = `add_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat= .c:193: undefined reference to = `LibAliasAddServer'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:= 158: undefined reference to = `LibAliasRedirectAddr'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat= .c:167: undefined reference to `LibAliasRedirectPort' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:178: undefined = reference to `LibAliasRedirectProto'ip_fw_nat.o: In function = `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:416:= undefined reference to `LibAliasInit'ip_fw_nat.o: In function = `ipfw_nat': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:216: undefined = reference to `m_megapullup' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:295: undefined = reference to `LibAliasOut' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:276: undefined = reference to `LibAliasOutTry' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:292: undefined = reference to `LibAliasIn' You need to compile with libalias support. -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 09:36:07 2011 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 00894106564A for ; Mon, 7 Nov 2011 09:36:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 29CEF8FC13 for ; Mon, 7 Nov 2011 09:36:05 +0000 (UTC) Received: by wwp14 with SMTP id 14so6370660wwp.31 for ; Mon, 07 Nov 2011 01:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=c8P4FXpYWJqOFkcD4wORoP7H7hEsNdIc6jZFRTQXQ+8=; b=hTSSwNE678BszQp/YOTgu8hjZKH274Y9I4ty6foQ9AYqA1DlNMUQ+O1qk8+OD1rphU QVTxkSgzPrlooJI2R9zt7XuMzznEn9uwKHb3yYf3FlRmumcB6jKXbdar343eNS00rQaK 7P3ud1nhbpWanuy1pe+dXMIWRmEjP3y8CSTlc= MIME-Version: 1.0 Received: by 10.216.166.212 with SMTP id g62mr5257133wel.29.1320658565218; Mon, 07 Nov 2011 01:36:05 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Mon, 7 Nov 2011 01:36:05 -0800 (PST) In-Reply-To: References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> Date: Mon, 7 Nov 2011 10:36:05 +0100 X-Google-Sender-Auth: BeRS1fA4sGozzyYh26DZ2tnLdg4 Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 09:36:07 -0000 2011/11/7 Arnaud Lacombe : > Hi, > > On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov wr= ote: >> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >> >> Below is the KBI patch after vm_page_bits_t merge is done. >> Again, I did not spent time converting all in-tree consumers >> from the (potentially) loadable modules to the new KPI until it >> is agreed upon. >> >> diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c >> index 305c189..7264cd1 100644 >> --- a/sys/nfsclient/nfs_bio.c >> +++ b/sys/nfsclient/nfs_bio.c >> @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * can only occur at the file EOF. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0VM_OBJECT_LOCK(object); >> - =C2=A0 =C2=A0 =C2=A0 if (pages[ap->a_reqpage]->valid !=3D 0) { >> + =C2=A0 =C2=A0 =C2=A0 if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D= 0) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; i <= npages; ++i) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0if (i !=3D ap->a_reqpage) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vm_page_lock(pages[i]); >> @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/* >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 * Read operation filled an entire page >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 */ >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 m->valid =3D VM_PAGE_BITS_ALL; >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 KASSERT(m->dirty =3D=3D 0, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 vm_page_write_valid(m, VM_PAGE_BITS_ALL); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 KASSERT(vm_page_read_dirty(m) =3D=3D 0, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0("nfs_getpages: page %p is dirty", m)); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else if (size >= toff) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/* >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 * Read operation filled a partial page. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 */ >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 m->valid =3D 0; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 vm_page_write_valid(m, 0); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0vm_page_set_valid(m, 0, size - toff); >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 KASSERT(m->dirty =3D=3D 0, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 KASSERT(vm_page_read_dirty(m) =3D=3D 0, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0("nfs_getpages: page %p is dirty", m)); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/* >> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >> index 389aea5..2f41e70 100644 >> --- a/sys/vm/vm_page.c >> +++ b/sys/vm/vm_page.c >> @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vm_page_dirty(m); >> =C2=A0} >> >> +void >> +vm_page_lock_func(vm_page_t m, const char *file, int line) >> +{ >> + >> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >> + =C2=A0 =C2=A0 =C2=A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line= ); >> +#else >> + =C2=A0 =C2=A0 =C2=A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); >> +#endif >> +} >> + > Why do you re-implement the wheel ? all the point of these assessors > is to hide implementation detail. IMO, you should restrict yourself to > the documented API from mutex(9), only. > > Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but > wait LOCK_FILE is either just __FILE__, or NULL, depending on > LOCK_DEBUG, but you wouldn't have those function without > INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely > fracked-up... If you don't want this code in INVARIANTS, but in > LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. > > Btw, let me also question the use of non-inline functions. My impression is that you don't really understand the patch, thus your disrespectful words used here are really unjustified. I think that kib@ intention is just to get "the most official way" to pass down file and line to locking functions from the consumers. His patch is "technically right", but I would prefer something different (see below). LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata section. Without INVARIANTS/WITNESS/etc. they will just be NULL and not pointing to a lot of datas that won't be used in the opposite case. I'm unsure if this replies to your concerns because you just criticize without making a real technical question in this post. >> +void >> +vm_page_unlock_func(vm_page_t m, const char *file, int line) >> +{ >> + >> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >> + =C2=A0 =C2=A0 =C2=A0 _mtx_unlock_flags(vm_page_lockptr(m), 0, file, li= ne); >> +#else >> + =C2=A0 =C2=A0 =C2=A0 __mtx_unlock(vm_page_lockptr(m), curthread, 0, fi= le, line); >> +#endif >> +} Kostik, we usually catered this case by having interfaces directly specified in mutex.h in order to keep the implementation details "compact enough" (see the thread_lock() case for this). I'm unsure what you prefer here, at least for the locking functions you could move over there as there are cons and prons for both approaches really and I'm fine with both. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 09:57:07 2011 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 054451065673 for ; Mon, 7 Nov 2011 09:57:07 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id B84B88FC12 for ; Mon, 7 Nov 2011 09:57:06 +0000 (UTC) Received: by ggnk3 with SMTP id k3so4874222ggn.13 for ; Mon, 07 Nov 2011 01:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UfBGS7COVpAr4dbwvGuetKkWmedsUgE68Paqa01q1Wk=; b=sPeveUUax4xE/wFZCnq+peJ9yxbH6153rpXBCRD6ws8g5Sm3to+iXQEyJVgQ0nesxe +loINyNURy8ZR6CdpW8l038FthBc7kmb2eN3TsQ8GfqaJfetweG3xjTF3lllmgNVMOBv PdaYuNYhEdzjtnHJsBvWF2HzQHkNJVQdqjdcw= MIME-Version: 1.0 Received: by 10.236.131.72 with SMTP id l48mr33566120yhi.90.1320659826085; Mon, 07 Nov 2011 01:57:06 -0800 (PST) Received: by 10.150.225.9 with HTTP; Mon, 7 Nov 2011 01:57:06 -0800 (PST) In-Reply-To: References: <20111107075734.GC91353@server.vk2pj.dyndns.org> Date: Mon, 7 Nov 2011 11:57:06 +0200 Message-ID: From: Alexander Yerenkow To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Peter Jeremy Subject: Re: Problem compiling kernel 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, 07 Nov 2011 09:57:07 -0000 2011/11/7 Garrett Cooper > On Nov 6, 2011, at 11:57 PM, Peter Jeremy wrote: > > > On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow > wrote: > >> And problem compiling kernel for amd64 arch. > >> > >> I attached full log: > >> > >> http://www.box.net/shared/juajg1o2lg1mxbht5x9b > > > > It looks like you did a parallel - in which case the actual error is > > buried somewhere in that output. Please repeat without any '-j' > > and post the last 50-100 lines of output. > > ip_fw_nat.o: In function > `del_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:123: > undefined reference to `LibAliasRedirectDelete' > ip_fw_nat.o: In function `ipfw_nat_destroy': > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined > reference to `LibAliasUninit' > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined > reference to `LibAliasUninit' > ip_fw_nat.o: In function `ifaddr_change': > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:80: undefined > reference to `LibAliasSetAddress' > ip_fw_nat.o: In function `ipfw_nat_del': > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:482: undefined > reference to `LibAliasUninit'ip_fw_nat.o: In function > `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:437: > undefined reference to > `LibAliasSetMode'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:438: > undefined reference to `LibAliasSetAddress' > ip_fw_nat.o: In function > `add_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:193: > undefined reference to > `LibAliasAddServer'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:158: > undefined reference to > `LibAliasRedirectAddr'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:167: > undefined reference to `LibAliasRedirectPort' > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:178: undefined > reference to `LibAliasRedirectProto'ip_fw_nat.o: In function > `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:416: > undefined reference to `LibAliasInit'ip_fw_nat.o: In function `ipfw_nat': > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:216: undefined > reference to `m_megapullup' > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:295: undefined > reference to `LibAliasOut' > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:276: undefined > reference to `LibAliasOutTry' > /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:292: undefined > reference to `LibAliasIn' > > You need to compile with libalias support. > Thanks, that does fix the problem. Is there somewhere request for feature that config must check kernel config for dependencies specified? Or maybe even auto-dependency :) What I mean, someone working at kernel configuration/sanity check util at all? Or mabye it's not requested feature? -Garrett -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 11:35:23 2011 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 0B9E9106564A; Mon, 7 Nov 2011 11:35:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 271D38FC12; Mon, 7 Nov 2011 11:35:21 +0000 (UTC) Received: by wyg36 with SMTP id 36so5944641wyg.13 for ; Mon, 07 Nov 2011 03:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=7aVDmGg0CjvG0PfaM2pwUDxPYXZnFW4oJH4usVLn76I=; b=QMZRwNa8i8Eb6j8VBu5/Mw2oNP0X6SLNuRAE748qzVWPpiHKMnwAIHBKdLTyLYosqh ZKYZNeKFLy7L7F9vCb78U8UdZqbTEJ1pacekk/SSK0BaIJjEFz1TBUVYVKNNL08+iMDY ZJp13cXdvYv8zPsuQGvfrWkyaS9+87jRBYTFM= MIME-Version: 1.0 Received: by 10.216.134.93 with SMTP id r71mr7059682wei.59.1320665720990; Mon, 07 Nov 2011 03:35:20 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Mon, 7 Nov 2011 03:35:20 -0800 (PST) In-Reply-To: References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> Date: Mon, 7 Nov 2011 12:35:20 +0100 X-Google-Sender-Auth: VDqX0fHkd9ovIJVYWrhWj76kfeM Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 11:35:23 -0000 2011/11/7 Attilio Rao : > 2011/11/7 Arnaud Lacombe : >> Hi, >> >> On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov w= rote: >>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>> >>> Below is the KBI patch after vm_page_bits_t merge is done. >>> Again, I did not spent time converting all in-tree consumers >>> from the (potentially) loadable modules to the new KPI until it >>> is agreed upon. >>> >>> diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c >>> index 305c189..7264cd1 100644 >>> --- a/sys/nfsclient/nfs_bio.c >>> +++ b/sys/nfsclient/nfs_bio.c >>> @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * can only occur at the file EOF. >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0VM_OBJECT_LOCK(object); >>> - =C2=A0 =C2=A0 =C2=A0 if (pages[ap->a_reqpage]->valid !=3D 0) { >>> + =C2=A0 =C2=A0 =C2=A0 if (vm_page_read_valid(pages[ap->a_reqpage]) != =3D 0) { >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; i = < npages; ++i) { >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0if (i !=3D ap->a_reqpage) { >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vm_page_lock(pages[i]); >>> @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/* >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 * Read operation filled an entire page >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 */ >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 m->valid =3D VM_PAGE_BITS_ALL; >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 KASSERT(m->dirty =3D=3D 0, >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 vm_page_write_valid(m, VM_PAGE_BITS_ALL); >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 KASSERT(vm_page_read_dirty(m) =3D=3D 0, >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0("nfs_getpages: page %p is dirty", m)); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else if (size = > toff) { >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/* >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 * Read operation filled a partial page. >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 */ >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 m->valid =3D 0; >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 vm_page_write_valid(m, 0); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0vm_page_set_valid(m, 0, size - toff); >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 KASSERT(m->dirty =3D=3D 0, >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 KASSERT(vm_page_read_dirty(m) =3D=3D 0, >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0("nfs_getpages: page %p is dirty", m)); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else { >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/* >>> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >>> index 389aea5..2f41e70 100644 >>> --- a/sys/vm/vm_page.c >>> +++ b/sys/vm/vm_page.c >>> @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vm_page_dirty(m)= ; >>> =C2=A0} >>> >>> +void >>> +vm_page_lock_func(vm_page_t m, const char *file, int line) >>> +{ >>> + >>> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >>> + =C2=A0 =C2=A0 =C2=A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, lin= e); >>> +#else >>> + =C2=A0 =C2=A0 =C2=A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); >>> +#endif >>> +} >>> + >> Why do you re-implement the wheel ? all the point of these assessors >> is to hide implementation detail. IMO, you should restrict yourself to >> the documented API from mutex(9), only. >> >> Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but >> wait LOCK_FILE is either just __FILE__, or NULL, depending on >> LOCK_DEBUG, but you wouldn't have those function without >> INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely >> fracked-up... If you don't want this code in INVARIANTS, but in >> LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. >> >> Btw, let me also question the use of non-inline functions. > > My impression is that you don't really understand the patch, thus your > disrespectful words used here are really unjustified. > > I think that kib@ intention is just to get "the most official way" to > pass down file and line to locking functions from the consumers. > His patch is "technically right", but I would prefer something > different (see below). > > LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata > section. Without INVARIANTS/WITNESS/etc. they will just be NULL and > not pointing to a lot of datas that won't be used in the opposite > case. > I'm unsure if this replies to your concerns because you just criticize > without making a real technical question in this post. > >>> +void >>> +vm_page_unlock_func(vm_page_t m, const char *file, int line) >>> +{ >>> + >>> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >>> + =C2=A0 =C2=A0 =C2=A0 _mtx_unlock_flags(vm_page_lockptr(m), 0, file, l= ine); >>> +#else >>> + =C2=A0 =C2=A0 =C2=A0 __mtx_unlock(vm_page_lockptr(m), curthread, 0, f= ile, line); >>> +#endif >>> +} > > Kostik, > we usually catered this case by having interfaces directly specified > in mutex.h in order to keep the implementation details "compact > enough" (see the thread_lock() case for this). > > I'm unsure what you prefer here, at least for the locking functions > you could move over there as there are cons and prons for both > approaches really and I'm fine with both. After thinking a bit about it, my guess is that the best approach would be patching mutex.h in order to offer a simple way to do what Kostik needs (i.e. a general interface to do that). I wouldn't encourage, infact, neither putting more things in mutex.h or growing checks in other files depending by the compiling options. I hope I can provide a patch asap. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 10:05:54 2011 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 3EDA1106566B; Mon, 7 Nov 2011 10:05:54 +0000 (UTC) (envelope-from ohartman@mail.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 F2D018FC0A; Mon, 7 Nov 2011 10:05:53 +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 <1RNLme-0002gH-H4>; Mon, 07 Nov 2011 10:46:28 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RNLme-0001RA-F4>; Mon, 07 Nov 2011 10:46:28 +0100 Message-ID: <4EB7A8F4.60403@mail.zedat.fu-berlin.de> Date: Mon, 07 Nov 2011 10:46:28 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org, "freebsd-current >> Current FreeBSD" Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Mon, 07 Nov 2011 12:20:20 +0000 Cc: Subject: multimedia/vlc: suddenly no graphical interface 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, 07 Nov 2011 10:05:54 -0000 On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all amd64 and CLANG compiled), I do not have a graphical user interface in VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: VLC media player 1.1.11 The Luggage (revision exported) Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") [0x8020521b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x80205ad70] main interface error: option qt-volume-complete does not exist [0x80205ad70] skins2 interface error: no suitable dialogs provider found (hint: compile the qt4 plugin, and make sure it is loaded properly) [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs provider [0x8020521b0] main libvlc error: interface "default" initialization failed Recompiling the multimedia/vlc port did not help, also unsuccessful was the recompilation of any qt4-port installed on the system. I also tried to find the local configuration files in my home directory and delete them, without any success. Is there something wrong with the DBUS subsystem named in the error? Help appreciated, thanks. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 14:16:04 2011 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 25BE9106566C for ; Mon, 7 Nov 2011 14:16:04 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A0B278FC0A for ; Mon, 7 Nov 2011 14:16:03 +0000 (UTC) Received: by faar19 with SMTP id r19so7321707faa.13 for ; Mon, 07 Nov 2011 06:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lJMRZbcbpfyCDLR3SgEZpDuJfLdJagGTg0UEdcmPRS0=; b=AuMz4o6ytN07mw+/PxH7V2RPRByNzO1H91SQygpcCiIkqydieYDMM5R5qPyD2skieB eBN/h3ZPMvIf59anIV8Arwjaq3UzoRCRlk4rXaXi4Zy+fgfr92dNfrjrj5vMQjeV8LuY n9sYEdyXBa1YMiyRay97pTVghNggxkuZdVm8Y= MIME-Version: 1.0 Received: by 10.223.77.71 with SMTP id f7mr47149900fak.33.1320675362485; Mon, 07 Nov 2011 06:16:02 -0800 (PST) Received: by 10.223.63.71 with HTTP; Mon, 7 Nov 2011 06:16:02 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Nov 2011 22:16:02 +0800 Message-ID: From: Paul Ambrose To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: [PATCH] Fix types of arguments to dtrace syscall return probes 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, 07 Nov 2011 14:16:04 -0000 Thank you for your work. I will give it a try in stable/9. I have another two PR: kern/160307 and bin/160275 that maybe you can help; the reason of bin/160275 is complicated, but the fix for kernel crash caused by module without ctf section(for example, nvidia.ko) missed somthing (my mistake) in kern/kern_ctf.c ---------------------------------------------------------------------------= ----- int link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc) .... struct nameidata nd; struct thread *td =3D curthread; uint8_t ctf_hdr[CTF_HDR_SIZE]; #endif int error =3D 0; if (lf =3D=3D NULL || lc =3D=3D NULL) return (EINVAL); /* Set the defaults for no CTF present. That's not a crime! */ bzero(lc, sizeof(*lc)); #ifdef DDB_CTF /* * First check if we've tried to load CTF data previously and the * CTF ELF section wasn't found. We flag that condition by setting * ctfcnt to -1. See below. */ if (ef->ctfcnt < 0) //second time with same module, return (0); /* Now check if we've already loaded the CTF data.. */ if (ef->ctfcnt > 0) { /* We only need to load once. */ lc->ctftab =3D ef->ctftab; lc->ctfcnt =3D ef->ctfcnt; lc->symtab =3D ef->ddbsymtab; lc->strtab =3D ef->ddbstrtab; lc->strcnt =3D ef->ddbstrcnt; lc->nsym =3D ef->ddbsymcnt; lc->ctfoffp =3D (uint32_t **) &ef->ctfoff; lc->typoffp =3D (uint32_t **) &ef->typoff; lc->typlenp =3D &ef->typlen; return (0); } /* * We need to try reading the CTF data. Flag no CTF data present * by default and if we actually succeed in reading it, we'll * update ctfcnt to the number of bytes read. */ ef->ctfcnt =3D -1; --------------------------------------------------------------------- fisrt time, set ctfcnt to -1, if module does not has ctf section, and ef->ctfcnt does NOT update with a valid value(>0) later, then second time enter this function with same module(ef), previous if (ef->ctfcnt < 0) return (0); // should not be 0 here pass over first time ctf section check, I think we need another fix . ---------------------------------------------------------------------------= --------- diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c index bdff96e..2737860 100644 --- a/sys/kern/kern_ctf.c +++ b/sys/kern/kern_ctf.c @@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc) * ctfcnt to -1. See below. */ if (ef->ctfcnt < 0) - return (0); + return (EFTYPE); /* Now check if we've already loaded the CTF data.. */ if (ef->ctfcnt > 0) { ---------------------------------------------------------------------------= ------------ And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you check it for me? kern/160307, I check the /boot/kernel/kernel with ctfdump, and found the kernel image has right ctf information, do you have any idea? And thank you again for your work! ---------------------------------------------------------------------------= ----------------------- [PATCH] Fix kernel panics when using dtrace fbt return probes on i386 [PATCH] Fix types of arguments to dtrace syscall return probes walltimestamp curpsinfo->pr_psargs has no args from "Shawn Webb lattera@gmail.com". commit ec734d4fb07fec8d1b5fb8d1d4c8caa0fada4eea Author: rstone Replace fasttrap_copyout() with uwrite(). FreeBSD copyout() is not abl= e to write to the .text section of a process. commit 83b04575eb8f73e557f245bb2814ac6db0a89696 Author: rstone Fix the DTrace pid return trap interrupt vector. Previously we were us= ing 31, but that vector is reserved. 2011/11/6 Ryan Stone : > Currently if you try to use the args[] array passed to a syscall > return probe, you get variables with the wrong type. =A0This is because > the systrace implementation is currently using the same function to > provide the same argument types for both the entry and return probes, > which is completely wrong. =A0For example: > > # dtrace -v -l -n syscall::mmap:return > =A0 ID =A0 PROVIDER =A0 =A0 =A0 =A0 =A0 =A0MODULE =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0FUNCTION NAME > 32159 =A0 =A0syscall =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mmap return > > =A0 =A0 =A0 =A0Probe Description Attributes > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Identifier Names: Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Data Semantics: =A0 Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dependency Class: ISA > > =A0 =A0 =A0 =A0Argument Attributes > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Identifier Names: Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Data Semantics: =A0 Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dependency Class: ISA > > =A0 =A0 =A0 =A0Argument Types > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[0]: caddr_t > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[1]: size_t > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[2]: int > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[3]: int > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[4]: int > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[5]: off_t > > The following patch[1] fixes this and provides the correct type to all > return probes. =A0For example, > > # dtrace -l -v -n syscall::mmap:return > =A0 ID =A0 PROVIDER =A0 =A0 =A0 =A0 =A0 =A0MODULE =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0FUNCTION NAME > =A02000 =A0 =A0syscall =A0 =A0 =A0 =A0 =A0 freebsd =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mmap return > > =A0 =A0 =A0 =A0Probe Description Attributes > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Identifier Names: Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Data Semantics: =A0 Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dependency Class: Unknown > > =A0 =A0 =A0 =A0Argument Attributes > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Identifier Names: Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Data Semantics: =A0 Private > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dependency Class: ISA > > =A0 =A0 =A0 =A0Argument Types > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[0]: caddr_t > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0args[1]: caddr_t > > > The patch: > diff --git a/sys/cddl/dev/systrace/systrace.c b/sys/cddl/dev/systrace/sys= trace.c > index cc48747..31c11c2 100644 > --- a/sys/cddl/dev/systrace/systrace.c > +++ b/sys/cddl/dev/systrace/systrace.c > @@ -220,8 +220,12 @@ systrace_getargdesc(void *arg, dtrace_id_t id, > void *parg, dtrace_argdesc_t *des > =A0{ > =A0 =A0 =A0 =A0int sysnum =3D SYSTRACE_SYSNUM((uintptr_t)parg); > > - =A0 =A0 =A0 systrace_setargdesc(sysnum, desc->dtargd_ndx, desc->dtargd_= native, > - =A0 =A0 =A0 =A0 =A0 sizeof(desc->dtargd_native)); > + =A0 =A0 =A0 if (SYSTRACE_ISENTRY((uintptr_t)parg)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 systrace_entry_setargdesc(sysnum, desc->dta= rgd_ndx, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 desc->dtargd_native, sizeof(desc->d= targd_native)); > + =A0 =A0 =A0 else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 systrace_return_setargdesc(sysnum, desc->dt= argd_ndx, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 desc->dtargd_native, sizeof(desc->d= targd_native)); > > =A0 =A0 =A0 =A0if (desc->dtargd_native[0] =3D=3D '\0') > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0desc->dtargd_ndx =3D DTRACE_ARGNONE; > diff --git a/sys/kern/makesyscalls.sh b/sys/kern/makesyscalls.sh > index d1162b5..1f081ce 100644 > --- a/sys/kern/makesyscalls.sh > +++ b/sys/kern/makesyscalls.sh > @@ -38,6 +38,7 @@ sysinc=3D"sysinc.switch.$$" > =A0sysarg=3D"sysarg.switch.$$" > =A0sysprotoend=3D"sysprotoend.$$" > =A0systracetmp=3D"systrace.$$" > +systraceret=3D"systraceret.$$" > > =A0if [ -r capabilities.conf ]; then > =A0 =A0 =A0 =A0capenabled=3D`cat capabilities.conf | grep -v "^#" | grep = -v "^$"` > @@ -46,9 +47,9 @@ else > =A0 =A0 =A0 =A0capenabled=3D"" > =A0fi > > -trap "rm $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 > $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl > $sysent $sysinc $sysarg $sysprotoend $systracetmp" 0 > +trap "rm $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 > $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl > $sysent $sysinc $sysarg $sysprotoend $systracetmp $systraceret" 0 > > -touch $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 > $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl > $sysent $sysinc $sysarg $sysprotoend $systracetmp > +touch $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 > $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl > $sysent $sysinc $sysarg $sysprotoend $systracetmp $systraceret > > =A0case $# in > =A0 =A0 0) echo "usage: $0 input-file " 1>&2 > @@ -96,6 +97,7 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sysmk =3D \"$sysmk\" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0systrace =3D \"$systrace\" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0systracetmp =3D \"$systracetmp\" > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 systraceret =3D \"$systraceret\" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compat =3D \"$compat\" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compat4 =3D \"$compat4\" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compat6 =3D \"$compat6\" > @@ -179,9 +181,12 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf "\tint64_t *iarg =A0=3D (int64_t *)= uarg;\n" > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf "\tswitch (sysnum) {\n" > systrace > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "static void\nsystrace_setargdesc(in= t sysnum, > int ndx, char *desc, size_t descsz)\n{\n\tconst char *p =3D NULL;\n" > > systracetmp > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "static void\nsystrace_entry_setargd= esc(int > sysnum, int ndx, char *desc, size_t descsz)\n{\n\tconst char *p =3D > NULL;\n" > systracetmp > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf "\tswitch (sysnum) {\n" > systracet= mp > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "static void\nsystrace_return_setarg= desc(int > sysnum, int ndx, char *desc, size_t descsz)\n{\n\tconst char *p =3D > NULL;\n" > systraceret > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "\tswitch (sysnum) {\n" > systracere= t > + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0NF =3D=3D 0 || $1 ~ /^;/ { > @@ -202,6 +207,7 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > sysnames > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > systracetmp > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 print > systraceret > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0savesyscall =3D syscall > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next > =A0 =A0 =A0 =A0} > @@ -216,6 +222,7 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > sysnames > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > systracetmp > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 print > systraceret > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0syscall =3D savesyscall > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next > =A0 =A0 =A0 =A0} > @@ -230,6 +237,7 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > sysnames > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0print > systracetmp > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 print > systraceret > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0syscall !=3D $1 { > @@ -303,7 +311,8 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parserr($end, ")") > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-- > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 f++ =A0 =A0 #function return type > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 syscallret=3D$f > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 f++ > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0funcname=3D$f > > @@ -387,6 +396,7 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parseline() > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("\t/* %s */\n\tcase %d: {\n", funcn= ame, > syscall) > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("\t/* %s */\n\tcase %d:\n", funcnam= e, syscall) >> systracetmp > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("\t/* %s */\n\tcase %d:\n", funcname= , syscall) >> systraceret > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (argc > 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("\t\tswitch(ndx) {\= n") > systracetmp > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("\t\tstruct %s *p = =3D params;\n", > argalias) > systrace > @@ -406,6 +416,10 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 argname[i], argtype[i]) > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("\t\tdefault:\n\t\t= \tbreak;\n\t\t};\n") >> systracetmp > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("\t\tif (ndx =3D=3D = 0 || ndx =3D=3D 1)\n") > systraceret > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("\t\t\tp =3D \"%s\";= \n", syscallret) > systraceret > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("\t\tbreak;\n") > sy= straceret > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("\t\t*n_args =3D %d;\n\t\tbreak;\n\= t}\n", argc) > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("\t\tbreak;\n") > systracetmp > @@ -623,6 +637,7 @@ s/\$//g > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> syshdr > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf "\tdefault:\n\t\t*n_args =3D > 0;\n\t\tbreak;\n\t};\n}\n" > systrace > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf "\tdefault:\n\t\tbreak;\n\t};\n\tif= (p !=3D > NULL)\n\t\tstrlcpy(desc, p, descsz);\n}\n" > systracetmp > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "\tdefault:\n\t\tbreak;\n\t};\n\tif = (p !=3D > NULL)\n\t\tstrlcpy(desc, p, descsz);\n}\n" > systraceret > =A0 =A0 =A0 =A0} ' > > =A0cat $sysinc $sysent >> $syssw > @@ -633,4 +648,5 @@ cat $sysarg $sysdcl \ > =A0 =A0 =A0 =A0$syscompat7 $syscompat7dcl \ > =A0 =A0 =A0 =A0$sysaue $sysprotoend > $sysproto > =A0cat $systracetmp >> $systrace > +cat $systraceret >> $systrace > > > [1] Can also be found at > http://people.freebsd.org/~rstone/patches/dtrace_syscall_ret.diff > _______________________________________________ > 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 Nov 7 16:46:04 2011 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 4C9E0106566B; Mon, 7 Nov 2011 16:46:04 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id A7F9F8FC0A; Mon, 7 Nov 2011 16:46:01 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNRu4-000GNl-TG; Mon, 07 Nov 2011 08:18:34 -0800 Message-ID: <4EB804D2.2090101@FreeBSD.org> Date: Mon, 07 Nov 2011 08:18:26 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , freebsd-net@FreeBSD.ORG Content-Type: multipart/mixed; boundary="------------010709080200050001090900" Sender: sobomax@sippysoft.com X-ssp-trusted: yes X-Mailman-Approved-At: Mon, 07 Nov 2011 17:09:10 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Panic in the udp_input() under heavy load 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, 07 Nov 2011 16:46:04 -0000 This is a multi-part message in MIME format. --------------010709080200050001090900 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Hi Gang, We are seeing repeatable panics under high PPS load on our production systems. It happens when the traffic gets into the range or 200MBps and 150-200K PPS. We have been managed to track it down to the following piece of code: (gdb) l *udp_input+0x5d2 0xffffffff806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628). 623 if (inp->inp_ip_minttl && inp->inp_ip_minttl > ip->ip_ttl) { 624 INP_RUNLOCK(inp); 625 goto badunlocked; 626 } 627 up = intoudpcb(inp); 628 if (up->u_tun_func == NULL) { 629 udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); 630 } else { 631 /* 632 * Engage the tunneling protocol. The faulty line appears to be 628, with up value is being NULL, attempt to deference it causes NULL pointer exception. I believe this particular piece of code has been introduced here: --- Author: bz Date: Thu Aug 13 15:16:30 2009 New Revision: 196192 URL: http://svn.freebsd.org/changeset/base/196192 Log: MFC: r192649 Implement UDP control block support. Add udpcb support with own fields and flags for UDP instead of further sticking things into in_pcb and flags fields. Attach the udpcb to the inp_ppcb in the kernel. Note: the udp tunneling parts are not (yet) existing in 7 and thus were not merged. Reviewed by: rwatson --- The screenshot of the panic message is attached. This is pretty recent 8.2-STABLE. Any help is greatly appreciated. This particular bug has haunted us for at least 4-5 months now. Thanks! -Maxim --------------010709080200050001090900-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 17:20:23 2011 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 47B45106564A for ; Mon, 7 Nov 2011 17:20:23 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 1951D8FC13 for ; Mon, 7 Nov 2011 17:20:22 +0000 (UTC) Received: from [127.0.0.1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pA7HK19s011236 for ; Mon, 7 Nov 2011 09:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1320686401; bh=04x/HI9O2JEw2a7dGU7R8Nu9HYluqORr0Mqy/a5iS/8=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=nZgH4PNRXbVfNdAf3ZWSXU9his7xxGE0JiyEVrS1xd0N1AuAW9mmEDeBdA74rmhzP lqnBKY5SNLJ6ayJ6vVonZUDV/ubhZYYSYJzvfiuibODkPqX8Bv78letu8/5gFg+cFi PeR74609BygZzRVm/HcqoBt8kqmt9xVnZddQUJQw= From: Sean Bruno To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Nov 2011 09:20:00 -0800 Message-ID: <1320686400.16024.17.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: 9.0 NFS Installs 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, 07 Nov 2011 17:20:23 -0000 I noted that we no longer have the disc1.iso in this release. What should I use to populate a NFS rootfs for netinstalls? This was what I had been using(8.2-RELEASE) to populate NFS roots for netinstalls. This allowed you to boot up into something that was self-contained. The other ISO's seem to have A LOT more stuff with symlinks pointing to absolute paths all over the f/s. This isn't quite as simple to copy over to a rootfs to use as a NFS target for booting. --- 8.2-RELEASE disc1.iso --- netboot# ls -l total 508 dr-xr-xr-x 14 root wheel 512 Nov 5 20:42 8.2-RELEASE -r--r--r-- 1 root wheel 4958 Nov 5 20:43 ERRATA.HTM -r--r--r-- 1 root wheel 3590 Nov 5 20:43 ERRATA.TXT -r--r--r-- 1 root wheel 192187 Nov 5 20:43 HARDWARE.HTM -r--r--r-- 1 root wheel 116657 Nov 5 20:43 HARDWARE.TXT -r--r--r-- 1 root wheel 19914 Nov 5 20:43 README.HTM -r--r--r-- 1 root wheel 14387 Nov 5 20:43 README.TXT -r--r--r-- 1 root wheel 105287 Nov 5 20:43 RELNOTES.HTM -r--r--r-- 1 root wheel 41124 Nov 5 20:43 RELNOTES.TXT dr-xr-xr-x 7 root wheel 1024 Nov 5 20:40 boot -r--r--r-- 1 root wheel 2048 Nov 5 20:43 boot.catalog -r--r--r-- 1 root wheel 39 Nov 5 20:43 cdrom.inf -r--r--r-- 1 root wheel 3802 Nov 5 20:43 docbook.css dr-xr-xr-x 5 root wheel 512 Nov 5 20:41 packages --- 9.0-RELEASE bootonly.iso --- total 492 -rw-r--r-- 2 root wheel 788 Oct 18 19:24 .cshrc -rw-r--r-- 2 root wheel 251 Oct 18 19:24 .profile drwxr-xr-x 2 root wheel 4096 Oct 18 19:24 .rr_moved -r--r--r-- 1 root wheel 6194 Oct 18 19:24 COPYRIGHT -r--r--r-- 1 root wheel 5167 Oct 18 19:24 ERRATA.HTM -r--r--r-- 1 root wheel 3727 Oct 18 19:24 ERRATA.TXT -r--r--r-- 1 root wheel 199303 Oct 18 19:24 HARDWARE.HTM -r--r--r-- 1 root wheel 121623 Oct 18 19:24 HARDWARE.TXT -r--r--r-- 1 root wheel 20698 Oct 18 19:24 README.HTM -r--r--r-- 1 root wheel 15103 Oct 18 19:24 README.TXT -r--r--r-- 1 root wheel 37081 Oct 18 19:24 RELNOTES.HTM -r--r--r-- 1 root wheel 18789 Oct 18 19:24 RELNOTES.TXT drwxr-xr-x 2 root wheel 6144 Oct 18 19:24 bin drwxr-xr-x 7 root wheel 6144 Oct 18 19:24 boot dr-xr-xr-x 2 root wheel 2048 Oct 18 19:24 dev -r--r--r-- 1 root wheel 3924 Oct 18 19:24 docbook.css drwxr-xr-x 20 root wheel 12288 Oct 18 19:24 etc drwxr-xr-x 3 root wheel 6144 Oct 18 19:24 lib drwxr-xr-x 3 root wheel 2048 Oct 18 19:24 libexec drwxr-xr-x 2 root wheel 2048 Oct 18 19:24 media drwxr-xr-x 2 root wheel 2048 Oct 18 19:24 mnt dr-xr-xr-x 2 root wheel 2048 Oct 18 19:24 proc drwxr-xr-x 2 root wheel 2048 Oct 18 19:24 rescue drwxr-xr-x 2 root wheel 2048 Oct 18 19:24 root drwxr-xr-x 2 root wheel 16384 Oct 18 19:24 sbin lrwxr-xr-x 1 root wheel 11 Oct 18 19:24 sys -> usr/src/sys drwxrwxrwt 2 root wheel 2048 Oct 18 19:24 tmp drwxr-xr-x 15 root wheel 2048 Oct 18 19:24 usr drwxr-xr-x 23 root wheel 4096 Oct 18 19:24 var From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 17:22:40 2011 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 5CDCE1065672; Mon, 7 Nov 2011 17:22:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 34F9E8FC0A; Mon, 7 Nov 2011 17:22:40 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNSu6-000Ga2-Uj; Mon, 07 Nov 2011 09:22:39 -0800 Message-ID: <4EB813D8.7020002@FreeBSD.org> Date: Mon, 07 Nov 2011 09:22:32 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , freebsd-net@FreeBSD.ORG, Jack Vogel References: <4EB804D2.2090101@FreeBSD.org> In-Reply-To: <4EB804D2.2090101@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 17:22:40 -0000 Panic screenshot is here: http://sobomax.sippysoft.com/ScreenShot859.png -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 17:45:41 2011 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 727211065670; Mon, 7 Nov 2011 17:45:41 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 31B428FC17; Mon, 7 Nov 2011 17:45:40 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 731DB290E56; Mon, 7 Nov 2011 11:45:40 -0600 (CST) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 5FB2E290E54; Mon, 7 Nov 2011 11:45:40 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id QM0h6t-2sOoh; Mon, 7 Nov 2011 11:45:40 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 89FCA290E59; Mon, 7 Nov 2011 11:45:39 -0600 (CST) Message-ID: <4EB81942.70501@rice.edu> Date: Mon, 07 Nov 2011 11:45:38 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111106124331.GP50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mdf@freebsd.org, "K. Macy" , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 17:45:41 -0000 On 11/06/2011 06:43, Kostik Belousov wrote: > On Sat, Nov 05, 2011 at 03:00:58PM -0500, Alan Cox wrote: >> On 11/05/2011 10:15, Kostik Belousov wrote: >>> On Sat, Nov 05, 2011 at 07:37:48AM -0700, mdf@freebsd.org wrote: >>>> On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov >>>> wrote: >>>>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>>>> >>>>> Below is the KBI patch after vm_page_bits_t merge is done. >>>>> Again, I did not spent time converting all in-tree consumers >>>> >from the (potentially) loadable modules to the new KPI until it >>>>> is agreed upon. >>>> I like my bikeshed orange... >>>> >>>> I would think a more canonical name would be get/set rather than >>>> read/write, especially since these operations aren't reading and >>>> writing the page (neither are they getting the page, but at least set >>>> is pretty unambiguous). >>> Look at the vm_page.h:385. vm_page_set_valid() is already taken. >> I don't feel good about creating an interface under which we have >> functions named vm_page_set_valid() and vm_page_write_valid(). I think >> that we should take a step back and look at the whole of set of >> functions that exist for manipulating the page's valid and dirty field >> and see if we can come up with a logical schema for naming them. I >> wouldn't then be surprised if this results in renaming some of the >> existing functions. >> >> However, this should not delay the changes to address the vm_page_lock >> problem. I had two questions about that part of your patch. First, is >> there any reason that you didn't include vm_page_lockptr()? If we >> created the page locking macros that you, jhb@, and I were talking about >> last week, then vm_page_lockptr() would be required. Second, there >> seems to be precedent for naming the locking functions _vm_page_lock() >> instead of vm_page_lock_func(), for example, the mutex code, i.e., >> sys/mutex.h, and the vm map locking functions. > I think vm_page_lockptr() should be included when some kind of > reloc-iterating macros are actually introduced into the tree. And, > I have a hope that they can be wrapped around a function with the > signature like > void vm_page_relock(vm_page_t locked_page, vm_page_t unlocked_page); > which moves the lock from locked_page to unlocked_page. > Ok. That sounds reasonable. > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has > a lot of violations in regard of the namespaces, IMO. The __* namespace > is reserved for the language implementation, so our freestanding program > (kernel) ignores the requirements of the C standard with the names like > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes > it not unreasonable for other developers to introduce reserved names. > So I decided to use the suffixes. vm_map.h locking is free of these > violations. > Ok. I'll offer one final suggestion. Please consider an alternative suffix to "func". Perhaps, "kbi" or "KBI". In other words, something that hints at the function's reason for existing. Alan From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:02:26 2011 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 BAD8C10656A3; Mon, 7 Nov 2011 18:02:26 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 189E18FC14; Mon, 7 Nov 2011 18:02:25 +0000 (UTC) Received: by faar19 with SMTP id r19so7646713faa.13 for ; Mon, 07 Nov 2011 10:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=WKJODiGx89F6rxjZQ2rwbLVw/MGi6Z3SHOaeB7KQ7jE=; b=ZAnUbp4v0q5fz1/vjps7hGz/ewFMSrWJmfIUNoXg0PALUazcd4AXU9HnUFaF7QpXUe HvseBeNGkS7B0/8Z/z6zNrDCJYFUPpACHrgiQuaYSbuINJSZ4bcvgZ/269PJ2SlhPQlk PIJ0tffDoFH/T3AuAf3nXwgRQMh1mGpeh8HrY= Received: by 10.152.162.10 with SMTP id xw10mr6884870lab.12.1320687233341; Mon, 07 Nov 2011 09:33:53 -0800 (PST) Received: from ernst.jennejohn.org (p578E35E4.dip.t-dialin.net. [87.142.53.228]) by mx.google.com with ESMTPS id or3sm9047473lab.8.2011.11.07.09.33.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 09:33:52 -0800 (PST) Date: Mon, 7 Nov 2011 18:33:49 +0100 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20111107183349.76e52976@ernst.jennejohn.org> In-Reply-To: <4EB7A8F4.60403@mail.zedat.fu-berlin.de> References: <4EB7A8F4.60403@mail.zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: multimedia/vlc: suddenly no graphical interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 18:02:26 -0000 On Mon, 07 Nov 2011 10:46:28 +0100 "O. Hartmann" wrote: > On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all > amd64 and CLANG compiled), I do not have a graphical user interface in > VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: > > VLC media player 1.1.11 The Luggage (revision exported) > Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") > Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") > [0x8020521b0] main libvlc: Running vlc with the default interface. Use > 'cvlc' to use vlc without interface. > [0x80205ad70] main interface error: option qt-volume-complete does not exist > [0x80205ad70] skins2 interface error: no suitable dialogs provider found > (hint: compile the qt4 plugin, and make sure it is loaded properly) > [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs > provider > [0x8020521b0] main libvlc error: interface "default" initialization failed > > > Recompiling the multimedia/vlc port did not help, also unsuccessful was > the recompilation of any qt4-port installed on the system. I also tried > to find the local configuration files in my home directory and delete > them, without any success. > > Is there something wrong with the DBUS subsystem named in the error? > No, this is what I seea and my GUI works: VLC media player 1.1.5 The Luggage (revision exported) Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") Blocked: call to setlocale(0, "") Blocked: call to sigaction(20, 0x7fffff9fbcb0, 0x7fffff9fbcd0) [0x801c86b70] qt4 interface error: Unable to load extensions module Warning: call to rand() Warning: call to rand() Warning: call to rand() Warning: call to rand() Warning: call to rand() Blocked: call to sigaction(20, 0x7fffffffd5e0, 0x7fffffffd600) Blocked: call to sigaction(20, 0x7fffffffd600, 0x0) The version of vlc which I'm using: drwxr-xr-x 2 root wheel 512 Sep 5 14:03 /var/db/pkg/vlc-1.1.5,3 -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:24:01 2011 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 830B91065674; Mon, 7 Nov 2011 18:24:01 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E13DD8FC16; Mon, 7 Nov 2011 18:24:00 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1699495bkb.13 for ; Mon, 07 Nov 2011 10:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ILvGmg5ggzbETUg9Thw1DcqXr5cBWazLCLz64PbZpNM=; b=bxIy+/AnTxbIRHc5CGHgpK3vxfNgUczVfF3SERidfErRENroWm4wcwqZvBf5W70ZgH kE00BfLSsudVbEa5AElimeB8vBRHUKcJq2UKhsFf69XQtatkgnS2fwXMsONTAD+39ZNF tq3yMe8Hnd0QeSvcJwfOgLv4kN/oYsAfVzMVc= MIME-Version: 1.0 Received: by 10.182.114.2 with SMTP id jc2mr9413487obb.27.1320690239506; Mon, 07 Nov 2011 10:23:59 -0800 (PST) Received: by 10.182.122.33 with HTTP; Mon, 7 Nov 2011 10:23:59 -0800 (PST) In-Reply-To: <1320686400.16024.17.camel@hitfishpass-lx.corp.yahoo.com> References: <1320686400.16024.17.camel@hitfishpass-lx.corp.yahoo.com> Date: Mon, 7 Nov 2011 10:23:59 -0800 Message-ID: From: Garrett Cooper To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" , sysinstall@freebsd.org Subject: Re: 9.0 NFS Installs 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, 07 Nov 2011 18:24:01 -0000 On Mon, Nov 7, 2011 at 9:20 AM, Sean Bruno wrote: > I noted that we no longer have the disc1.iso in this release. =A0What > should I use to populate a NFS rootfs for netinstalls? > > This was what I had been using(8.2-RELEASE) to populate NFS roots for > netinstalls. =A0This allowed you to boot up into something that was > self-contained. > > The other ISO's seem to have A LOT more stuff with symlinks pointing to > absolute paths all over the f/s. This isn't quite as simple to copy over > to a rootfs to use as a NFS target for booting. It's just a better idea to use the payload tarballs from here: ftp://ftp.freebsd.org/pub/FreeBSD/releases//// e.g. ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ as the basis for your system, and probably just run something like make distribution ala mergemaster afterwards and/or use a custom /boot/loader.conf, /etc/... . sysinstall hacked up the system using its custom memory disk with secret sauce binaries and pathing, s.t. it kept most things self-contained to /stand, whereas bsdinstall hacks the system up in different ways -- most of it pointing back to /tmp/bsdinstall_* or similar locations. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:25:46 2011 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 34DD3106568A for ; Mon, 7 Nov 2011 18:25:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAC38FC0C for ; Mon, 7 Nov 2011 18:25:45 +0000 (UTC) Received: by eyd10 with SMTP id 10so4981464eyd.13 for ; Mon, 07 Nov 2011 10:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hbP6LRqPJrAdVygJhYK3Tqcz9ySDpjoHNQE2ZV0cLLA=; b=b9o0cCFSwR8Di3wDw8yJAG1OQ5tr1bxrhDT6ZWnhv0mwCgcf8GnhINDteh3gLWPCK9 AMjHCQKty1+fZt1UaBeloy0JPxrCWt9lPkOKCmdHVrUHQZJInSIyZbgX8OpvX0nTQPsO U7+RAF7W6aCZaD0lB25uZ2OCWTEGV/z9JfrZ4= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr8190677obq.37.1320690344180; Mon, 07 Nov 2011 10:25:44 -0800 (PST) Received: by 10.182.122.33 with HTTP; Mon, 7 Nov 2011 10:25:44 -0800 (PST) In-Reply-To: <20111107183349.76e52976@ernst.jennejohn.org> References: <4EB7A8F4.60403@mail.zedat.fu-berlin.de> <20111107183349.76e52976@ernst.jennejohn.org> Date: Mon, 7 Nov 2011 10:25:44 -0800 Message-ID: From: Garrett Cooper To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "O. Hartmann" , freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: multimedia/vlc: suddenly no graphical interface 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, 07 Nov 2011 18:25:46 -0000 On Mon, Nov 7, 2011 at 9:33 AM, Gary Jennejohn wrote: > On Mon, 07 Nov 2011 10:46:28 +0100 > "O. Hartmann" wrote: > >> On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all >> amd64 and CLANG compiled), I do not have a graphical user interface in >> VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: >> >> VLC media player 1.1.11 The Luggage (revision exported) >> Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") >> Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") >> [0x8020521b0] main libvlc: Running vlc with the default interface. Use >> 'cvlc' to use vlc without interface. >> [0x80205ad70] main interface error: option qt-volume-complete does not exist >> [0x80205ad70] skins2 interface error: no suitable dialogs provider found >> (hint: compile the qt4 plugin, and make sure it is loaded properly) >> [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs >> provider >> [0x8020521b0] main libvlc error: interface "default" initialization failed >> >> >> Recompiling the multimedia/vlc port did not help, also unsuccessful was >> the recompilation of any qt4-port installed on the system. I also tried >> to find the local configuration files in my home directory and delete >> them, without any success. >> >> Is there something wrong with the DBUS subsystem named in the error? >> > > No, this is what I seea and my GUI works: > > VLC media player 1.1.5 The Luggage (revision exported) > Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") > Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") > Blocked: call to setlocale(0, "") > Blocked: call to sigaction(20, 0x7fffff9fbcb0, 0x7fffff9fbcd0) > [0x801c86b70] qt4 interface error: Unable to load extensions module ^^^ > Warning: call to rand() > Warning: call to rand() > Warning: call to rand() > Warning: call to rand() > Warning: call to rand() > Blocked: call to sigaction(20, 0x7fffffffd5e0, 0x7fffffffd600) > Blocked: call to sigaction(20, 0x7fffffffd600, 0x0) > > The version of vlc which I'm using: Your vlc install is broken too. You'll need to ktrace / truss vlc until you find the broken library as vlc likes to hide those details from the end-user (even when invoking vlc with --verbose). HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:27:44 2011 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 704DE1065679 for ; Mon, 7 Nov 2011 18:27:44 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB70F8FC0C for ; Mon, 7 Nov 2011 18:27:43 +0000 (UTC) Received: by dyk29 with SMTP id 29so105783dyk.13 for ; Mon, 07 Nov 2011 10:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kPoOTCKbdMLXN92KKtCSfHMQXCe1vWWgW0BI90E5Jtc=; b=GFGk53/q+5jOGTwR+lNR6GTmij3fSeYQkO0UZ1gjRGAStpdoa7susvNYecDqnVBQB6 TcQA0/YxFhe1JTDgA481gg+Ta02Zsu6u1tmwDDyNCUoPwqgm4NEMU/ov8K4wZxSV9mj6 JOUdfePUvC7grCHpkNJYFU2SlXBjAxpotWv4k= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr8191995obq.37.1320690462299; Mon, 07 Nov 2011 10:27:42 -0800 (PST) Received: by 10.182.122.33 with HTTP; Mon, 7 Nov 2011 10:27:42 -0800 (PST) In-Reply-To: <4EB7A8F4.60403@mail.zedat.fu-berlin.de> References: <4EB7A8F4.60403@mail.zedat.fu-berlin.de> Date: Mon, 7 Nov 2011 10:27:42 -0800 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-current >> Current FreeBSD" , freebsd-questions@freebsd.org Subject: Re: multimedia/vlc: suddenly no graphical interface 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, 07 Nov 2011 18:27:44 -0000 On Mon, Nov 7, 2011 at 1:46 AM, O. Hartmann wrote: > On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all > amd64 and CLANG compiled), I do not have a graphical user interface in > VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: > > VLC media player 1.1.11 The Luggage (revision exported) > Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") > Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") > [0x8020521b0] main libvlc: Running vlc with the default interface. Use > 'cvlc' to use vlc without interface. > [0x80205ad70] main interface error: option qt-volume-complete does not exist > [0x80205ad70] skins2 interface error: no suitable dialogs provider found > (hint: compile the qt4 plugin, and make sure it is loaded properly) > [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs > provider > [0x8020521b0] main libvlc error: interface "default" initialization failed > > > Recompiling the multimedia/vlc port did not help, also unsuccessful was > the recompilation of any qt4-port installed on the system. I also tried > to find the local configuration files in my home directory and delete > them, without any success. > > Is there something wrong with the DBUS subsystem named in the error? The best suggestion I have is ldd'ing the depends until you find the broken library (you can't figure this out typically by ldd'ing vlc because it dl_open's things IIRC -- can't verify because I blew away my install with vlc on it recently). -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:29:20 2011 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 531FC1065673 for ; Mon, 7 Nov 2011 18:29:20 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 276E88FC18 for ; Mon, 7 Nov 2011 18:29:20 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LUA00L0OZCPKZ00@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 07 Nov 2011 12:29:13 -0600 (CST) Received: from wanderer.tachypleus.net (i3-user-nat.icecube.wisc.edu [128.104.255.12]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LUA00H14ZCL7910@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 07 Nov 2011 12:29:09 -0600 (CST) Date: Mon, 07 Nov 2011 12:29:09 -0600 From: Nathan Whitehorn In-reply-to: <1320686400.16024.17.camel@hitfishpass-lx.corp.yahoo.com> To: freebsd-current@freebsd.org Message-id: <4EB82375.6070106@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.255.12 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.7.173016, SenderIP=128.104.255.12 References: <1320686400.16024.17.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110928 Thunderbird/7.0 Subject: Re: 9.0 NFS Installs 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, 07 Nov 2011 18:29:20 -0000 On 11/07/11 11:20, Sean Bruno wrote: > I noted that we no longer have the disc1.iso in this release. What > should I use to populate a NFS rootfs for netinstalls? > > This was what I had been using(8.2-RELEASE) to populate NFS roots for > netinstalls. This allowed you to boot up into something that was > self-contained. > > The other ISO's seem to have A LOT more stuff with symlinks pointing to > absolute paths all over the f/s. This isn't quite as simple to copy over > to a rootfs to use as a NFS target for booting. You can just copy the whole CD over and it will work fine. The CD is basically a vanilla installed system, so you can also just set up an install somewhere (with bsdinstall jail /path/to/nfsroot, for instance). Things on the CD different from a vanilla system: - /etc/rc.local script to start the installer at boot (copied from /usr/src/release/rc.local) - Distfiles copied to /usr/freebsd-dist If you don't copy the distfiles, bsdinstall will automatically download them, but you probably don't want to do that every time. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:42:07 2011 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 1D621106566B; Mon, 7 Nov 2011 18:42:07 +0000 (UTC) (envelope-from bz@FreeBSD.ORG) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id C11798FC14; Mon, 7 Nov 2011 18:42:06 +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 B640525D3893; Mon, 7 Nov 2011 18:24:16 +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 DA056BD465E; Mon, 7 Nov 2011 18:24:15 +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 dcCsXAtP3PFX; Mon, 7 Nov 2011 18:24:14 +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 9C035BD4660; Mon, 7 Nov 2011 18:24:14 +0000 (UTC) Date: Mon, 7 Nov 2011 18:24:14 +0000 (UTC) From: "Bjoern A. Zeeb" To: Maxim Sobolev In-Reply-To: <4EB804D2.2090101@FreeBSD.org> Message-ID: References: <4EB804D2.2090101@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.ORG, Robert Watson , "current@freebsd.org" Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@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: Mon, 07 Nov 2011 18:42:07 -0000 On Mon, 7 Nov 2011, Maxim Sobolev wrote: > Hi Gang, > > We are seeing repeatable panics under high PPS load on our production > systems. It happens when the traffic gets into the range or 200MBps and > 150-200K PPS. We have been managed to track it down to the following piece of > code: > > (gdb) l *udp_input+0x5d2 > 0xffffffff806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628). > 623 if (inp->inp_ip_minttl && inp->inp_ip_minttl > ip->ip_ttl) { > 624 INP_RUNLOCK(inp); > 625 goto badunlocked; > 626 } > 627 up = intoudpcb(inp); > 628 if (up->u_tun_func == NULL) { > 629 udp_append(inp, ip, m, iphlen + sizeof(struct > udphdr), &udp_in); > 630 } else { > 631 /* > 632 * Engage the tunneling protocol. > > The faulty line appears to be 628, with up value is being NULL, attempt to > deference it causes NULL pointer exception. I believe this particular piece > of code has been introduced here: Unlikely; the inp is properly locked there and the udp info attach better still be valid there; your problem is most likely elsewhere; try to see if you have other threads and see what they do at the same time, etc. You would need to race with udp_detach(); you also want to make sure that the inp still looks sane from either ddb or a dump and we are not talking about random memory corruption here. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:43:23 2011 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 769A3106564A for ; Mon, 7 Nov 2011 18:43:23 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F13248FC0C for ; Mon, 7 Nov 2011 18:43:22 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1723546bkb.13 for ; Mon, 07 Nov 2011 10:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/lmbwyC6HZATeIeK3FAt1lm54hJwMyWV+In52LXke1c=; b=dX2W0XokFskVVOeOyC+ecCJNLrXk+R4MRrKz4ytuTsZJYZ00y9c3GCHeV6W3rK2OwH HeCbhs9tZ0I6eG10K6gHoM4U+oTGov+yxGWoiqcfH2+4Ny2YplPWMhHBSP5+T4yEyL95 ffaUCIVqE015GEY9kDJfhVc6O6NQbrK6KRK8s= MIME-Version: 1.0 Received: by 10.182.225.3 with SMTP id rg3mr9331175obc.77.1320691400988; Mon, 07 Nov 2011 10:43:20 -0800 (PST) Received: by 10.182.122.33 with HTTP; Mon, 7 Nov 2011 10:43:20 -0800 (PST) In-Reply-To: References: <20111107075734.GC91353@server.vk2pj.dyndns.org> Date: Mon, 7 Nov 2011 10:43:20 -0800 Message-ID: From: Garrett Cooper To: Alexander Yerenkow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Peter Jeremy Subject: Re: Problem compiling kernel 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, 07 Nov 2011 18:43:23 -0000 On Mon, Nov 7, 2011 at 1:57 AM, Alexander Yerenkow wro= te: > > > 2011/11/7 Garrett Cooper >> >> On Nov 6, 2011, at 11:57 PM, Peter Jeremy wrote: >> >> > On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow >> > wrote: >> >> And problem compiling kernel for amd64 arch. >> >> >> >> I attached full log: >> >> >> >> http://www.box.net/shared/juajg1o2lg1mxbht5x9b >> > >> > It looks like you did a parallel - in which case the actual error is >> > buried somewhere in that output. =A0Please repeat without any '-j' >> > and post the last 50-100 lines of output. >> >> ip_fw_nat.o: In function >> `del_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_n= at.c:123: >> undefined reference to `LibAliasRedirectDelete' >> ip_fw_nat.o: In function `ipfw_nat_destroy': >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined >> reference to `LibAliasUninit' >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined >> reference to `LibAliasUninit' >> ip_fw_nat.o: In function `ifaddr_change': >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:80: undefined >> reference to `LibAliasSetAddress' >> ip_fw_nat.o: In function `ipfw_nat_del': >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:482: undefined >> reference to `LibAliasUninit'ip_fw_nat.o: In function >> `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:43= 7: >> undefined reference to >> `LibAliasSetMode'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:= 438: >> undefined reference to `LibAliasSetAddress' >> ip_fw_nat.o: In function >> `add_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_n= at.c:193: >> undefined reference to >> `LibAliasAddServer'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.= c:158: >> undefined reference to >> `LibAliasRedirectAddr'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_n= at.c:167: >> undefined reference to `LibAliasRedirectPort' >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:178: undefined >> reference to `LibAliasRedirectProto'ip_fw_nat.o: In function >> `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:41= 6: >> undefined reference to `LibAliasInit'ip_fw_nat.o: In function `ipfw_nat'= : >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:216: undefined >> reference to `m_megapullup' >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:295: undefined >> reference to `LibAliasOut' >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:276: undefined >> reference to `LibAliasOutTry' >> /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:292: undefined >> reference to `LibAliasIn' >> >> You need to compile with libalias support. > > Thanks, that does fix the problem. > Is there somewhere request for feature that config must check kernel conf= ig > for dependencies specified? Or maybe even auto-dependency :) > What I mean, someone working at kernel configuration/sanity check util at > all? Or mabye it's not requested feature? Unfortunately our build system isn't really kind in this regard, and typically the answer has been "you should understand what's going into your KERNCONF instead of having the build system automatically handle it for you" (or at least that was the song and dance I got on questions@ 9 years ago when I first started using FreeBSD). It would be nice if the ipfw authors actually generated a manpage that listed the requirements ;)... Also, FWIW: ./ip_fw_nat.c:MODULE_DEPEND(ipfw_nat, libalias, 1, 1, 1); Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:59:44 2011 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 BBA99106564A for ; Mon, 7 Nov 2011 18:59:44 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 83D3B8FC20 for ; Mon, 7 Nov 2011 18:59:44 +0000 (UTC) Received: from [127.0.0.1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pA7IxDbR061893; Mon, 7 Nov 2011 10:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1320692353; bh=AWZdTNO8Z5zMahNsa2MnYAzWdKEPKEtHI0cUir/6dco=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=DW6jIZiduZyxK0RCPGyRvLCmev6jbcDe8srOxsnB6qRyRj/tiAf6yPhySIvblPLmo i4SdBcQKeI7lOOA472mi7UFx/9kjxCxnaY+Sjnv4ilX+Mj6oLDZEvmifQzoOFCdUjr BBUIuXM1Oady8A291GNE6pzY4Om8dnOzXHlh8Ra8= From: Sean Bruno To: Nathan Whitehorn In-Reply-To: <4EB82375.6070106@freebsd.org> References: <1320686400.16024.17.camel@hitfishpass-lx.corp.yahoo.com> <4EB82375.6070106@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Nov 2011 10:59:13 -0800 Message-ID: <1320692353.16024.19.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: 9.0 NFS Installs 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, 07 Nov 2011 18:59:44 -0000 On Mon, 2011-11-07 at 10:29 -0800, Nathan Whitehorn wrote: > On 11/07/11 11:20, Sean Bruno wrote: > > I noted that we no longer have the disc1.iso in this release. What > > should I use to populate a NFS rootfs for netinstalls? > > > > This was what I had been using(8.2-RELEASE) to populate NFS roots for > > netinstalls. This allowed you to boot up into something that was > > self-contained. > > > > The other ISO's seem to have A LOT more stuff with symlinks pointing to > > absolute paths all over the f/s. This isn't quite as simple to copy over > > to a rootfs to use as a NFS target for booting. > > You can just copy the whole CD over and it will work fine. The CD is > basically a vanilla installed system, so you can also just set up an > install somewhere (with bsdinstall jail /path/to/nfsroot, for instance). > > Things on the CD different from a vanilla system: > - /etc/rc.local script to start the installer at boot > (copied from /usr/src/release/rc.local) > - Distfiles copied to /usr/freebsd-dist > > If you don't copy the distfiles, bsdinstall will automatically download > them, but you probably don't want to do that every time. > -Nathan Hah! Yes ... this is absolutely correct. I'm netbooting VMs now, excellent. Sean From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:03:59 2011 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 CF067106564A; Mon, 7 Nov 2011 19:03:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id C207E8FC0C; Mon, 7 Nov 2011 19:03:58 +0000 (UTC) Received: by eyd10 with SMTP id 10so5029784eyd.13 for ; Mon, 07 Nov 2011 11:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GP+oR1k2BxAz3qR+KOK/MHanGb+Wlr+hqLbN71eEqQQ=; b=YJvwDtXP1TQc8jWL7RG1KS+GFHSatUYfZ/QHznm+qD0Y7PWicC6RfujzikPEy9YVcc Fy6gDNOFBviCswuZ9YxufYv0BTW3SnfojdOPX5hGkuiXuXK21SlUAxVmV05QxG4RpYgZ DG+t6wB4G+y/6Zt3OP4ut7tBYuxztKz7lQXB0= MIME-Version: 1.0 Received: by 10.180.106.104 with SMTP id gt8mr9186674wib.6.1320692637370; Mon, 07 Nov 2011 11:03:57 -0800 (PST) Received: by 10.180.81.200 with HTTP; Mon, 7 Nov 2011 11:03:57 -0800 (PST) In-Reply-To: References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> Date: Mon, 7 Nov 2011 14:03:57 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 19:03:59 -0000 On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao wrote: > 2011/11/7 Arnaud Lacombe : >> Hi, >> >> On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov w= rote: >>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>> >>> Below is the KBI patch after vm_page_bits_t merge is done. >>> Again, I did not spent time converting all in-tree consumers >>> from the (potentially) loadable modules to the new KPI until it >>> is agreed upon. >>> >>> diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c >>> index 305c189..7264cd1 100644 >>> --- a/sys/nfsclient/nfs_bio.c >>> +++ b/sys/nfsclient/nfs_bio.c >>> @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) >>> =A0 =A0 =A0 =A0 * can only occur at the file EOF. >>> =A0 =A0 =A0 =A0 */ >>> =A0 =A0 =A0 =A0VM_OBJECT_LOCK(object); >>> - =A0 =A0 =A0 if (pages[ap->a_reqpage]->valid !=3D 0) { >>> + =A0 =A0 =A0 if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D 0) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < npages; ++i) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (i !=3D ap->a_reqpage= ) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_= lock(pages[i]); >>> @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation filled= an entire page >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D VM_PAGE_BITS= _ALL; >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D 0= , >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, VM= _PAGE_BITS_ALL); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dirt= y(m) =3D=3D 0, >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages: = page %p is dirty", m)); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (size > toff) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation filled= a partial page. >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D 0; >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, 0)= ; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_set_valid(m, 0, = size - toff); >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D 0= , >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dirt= y(m) =3D=3D 0, >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages: = page %p is dirty", m)); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >>> index 389aea5..2f41e70 100644 >>> --- a/sys/vm/vm_page.c >>> +++ b/sys/vm/vm_page.c >>> @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_dirty(m); >>> =A0} >>> >>> +void >>> +vm_page_lock_func(vm_page_t m, const char *file, int line) >>> +{ >>> + >>> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >>> + =A0 =A0 =A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); >>> +#else >>> + =A0 =A0 =A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); >>> +#endif >>> +} >>> + >> Why do you re-implement the wheel ? all the point of these assessors >> is to hide implementation detail. IMO, you should restrict yourself to >> the documented API from mutex(9), only. >> >> Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but >> wait LOCK_FILE is either just __FILE__, or NULL, depending on >> LOCK_DEBUG, but you wouldn't have those function without >> INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely >> fracked-up... If you don't want this code in INVARIANTS, but in >> LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. >> >> Btw, let me also question the use of non-inline functions. > > My impression is that you don't really understand the patch, thus your > disrespectful words used here are really unjustified. > Well, unfortunately, I wasn't around to comment 10 years ago when this got = in. > I think that kib@ intention is just to get "the most official way" to > pass down file and line to locking functions from the consumers. > His patch is "technically right", but I would prefer something > different (see below). > Yes, and that's not an excuse to use the _internal_ implementation details of mutex(9), and not the exposed API. This is especially true when applied to someone so eager to follow "standards". > LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata > section. Without INVARIANTS/WITNESS/etc. they will just be NULL and > not pointing to a lot of datas that won't be used in the opposite > case. > You comment just as if __FILE__ and __LINE__ were mandatory in a debug interface. This is _not_ true. __FILE__ and __LINE__ are just hideous for debugging of anything but early alpha code. LOCK_FILE and LOCK_LINE are a bad answer to a bad interface. Even if you just pass NULL and 0 as argument, you've got the bloat of passing unused argument. You might as well just pass a single argument that would do the exact same job and be _always_ available, eg. the IP of the caller, or the first return address. KDB magic still let you translate to something humanly understandable. If the toolchain does not support the feature on all supported platform, well, fix the toolchain. > I'm unsure if this replies to your concerns because you just criticize > without making a real technical question in this post. > I made comments on 3 points: - using internal implementation details of mutex(9) is broken - LOCK_FILE/LOCK_LINE are broken (a bit of a divergence on the original subject :/) - there is _no_ reason not to use inlines function for such trivial onelin= ers so obviously, we did not read the same comments. - Arnaud >>> +void >>> +vm_page_unlock_func(vm_page_t m, const char *file, int line) >>> +{ >>> + >>> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >>> + =A0 =A0 =A0 _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); >>> +#else >>> + =A0 =A0 =A0 __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line= ); >>> +#endif >>> +} > > Kostik, > we usually catered this case by having interfaces directly specified > in mutex.h in order to keep the implementation details "compact > enough" (see the thread_lock() case for this). > > I'm unsure what you prefer here, at least for the locking functions > you could move over there as there are cons and prons for both > approaches really and I'm fine with both. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:31:32 2011 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 B0D76106566B; Mon, 7 Nov 2011 19:31:32 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id DD98A8FC15; Mon, 7 Nov 2011 19:31:31 +0000 (UTC) Received: by eyd10 with SMTP id 10so5064469eyd.13 for ; Mon, 07 Nov 2011 11:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kLRUd1p4WICYXaV3QwZZDLuhCutxFbaO/X2YIliA0yw=; b=S6Il9ge4xpZq55tQ3Euujnesxbt0LXbzpecachfAS8yun+Uu+9auBdJNRP1UIhs2wM E2BjFRwMXzzuCszENegTeFI/GE2PvMKrYdCHqCSaoTxP+0QVQ7ctEoxEVawCoi/D6Seb fqmHZvILhVQuRKMMZlZMFFBcC79bGI/0RKEn8= MIME-Version: 1.0 Received: by 10.180.106.104 with SMTP id gt8mr9288131wib.6.1320694290900; Mon, 07 Nov 2011 11:31:30 -0800 (PST) Received: by 10.180.81.200 with HTTP; Mon, 7 Nov 2011 11:31:30 -0800 (PST) In-Reply-To: <4EB11C32.80106@FreeBSD.org> References: <4EB11C32.80106@FreeBSD.org> Date: Mon, 7 Nov 2011 14:31:30 -0500 Message-ID: From: Arnaud Lacombe To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Penta Upa , freebsd-current@freebsd.org, Benjamin Kaduk , "K. Macy" Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 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, 07 Nov 2011 19:31:32 -0000 Hi, On Wed, Nov 2, 2011 at 6:32 AM, Andriy Gapon wrote: > > [restored cc: to the original poster] > > on 02/11/2011 08:10 Benjamin Kaduk said the following: >> I am perhaps confused. =A0Last I checked, bsd.kmod.mk caused '-include >> opt_global.h' to be passed on the command line. =A0Is the issue just tha= t the >> opt_global.h used for the kmod could be different from the actual kernel= 's >> opt_global.h, because KERNCONF was not specified and the header is gener= ated at >> module-build time? =A0In this case, clearly the onus is on the user to p= ass >> KERNCONF at module build time. > > To be precise, this is what is actually passed to a compiler: > sys/conf/kmod.mk: > .if defined(KERNBUILDDIR) > CFLAGS+=3D =A0 =A0 -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/= opt_global.h > .endif > > where KERNBUILDDIR can be passed via environment from a kernel build: > sys/conf/kern.post.mk: > MKMODULESENV+=3D =A0KERNBUILDDIR=3D"${.CURDIR}" SYSDIR=3D"${SYSDIR}" > > KERNCONF does not have any meaning in a module build. > > To make sure that a module build sees exactly the same kernel options as = a > kernel with which the module should work, one has to either build the mod= ule > together with the kernel (within the kernel build; search for MODULES in > make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct k= ernel > build directory. =A0(Which to a certain degree implies impossibility to b= uild a > "perfect" module for a pre-built binary kernel or to provide a "perfect" > universal pre-built module for any custom kernel) > > Of course, the real problem is that modules should not care about any (or= at > least some) kernel options, they should be isolated from the options via = a > proper KPI/KBI (perhaps DDI or "module-to-kernel interface" or whatever).= =A0A > module should be able to work correctly with kernels built with different= options. > You cannot be make a point in shade of gray, it either "must care" or "must not care" about kernel option, not "care about some, but not other". Moreover, you cannot advocate stable internal KBI/KPI when you are not even able to provide a stable userland ABI... > P.P.S. [and tangential] I see that many module makefiles fake up various = kernel > options in a fashion similar to the following: > .if !defined(KERNBUILDDIR) > opt_compat.h: > =A0 =A0 =A0 =A0echo "#define COMPAT_FREEBSD6 1" > ${.TARGET} > > opt_kbd.h: > =A0 =A0 =A0 =A0echo "#define KBD_INSTALL_CDEV 1" > ${.TARGET} > .endif > > And handful of modules fake up opt_global.h, e.g.: > opt_global.h: > =A0 =A0 =A0 =A0echo "#define ALTQ 1" =A0 =A0 > ${.TARGET} This mess is utterly broken. FWIW, I advocate to make KERNBUILDDIR (ie. kernel option's configuration) mandatory for building any modules. - Arnaud > -- > Andriy Gapon > _______________________________________________ > 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 Nov 7 19:35:21 2011 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 61F61106566B; Mon, 7 Nov 2011 19:35:21 +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 EDEB68FC0A; Mon, 7 Nov 2011 19:35:20 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA7JZHNX084248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2011 21:35:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA7JZH8W061082; Mon, 7 Nov 2011 21:35:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA7JZGqA061081; Mon, 7 Nov 2011 21:35:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Nov 2011 21:35:16 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111107193516.GA50300@deviant.kiev.zoral.com.ua> References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="etnyxeYqjisoB5dq" Content-Disposition: inline In-Reply-To: <4EB81942.70501@rice.edu> 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=-3.9 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: mdf@freebsd.org, "K. Macy" , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 19:35:21 -0000 --etnyxeYqjisoB5dq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: > Ok. I'll offer one final suggestion. Please consider an alternative=20 > suffix to "func". Perhaps, "kbi" or "KBI". In other words, something=20 > that hints at the function's reason for existing. Sure. Below is the extraction of only vm_page_lock() bits, together with the suggested rename. When Attilio provides the promised simplification of the mutex KPI, this can be reduced. diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c index 389aea5..ea4ea34 100644 --- a/sys/vm/vm_page.c +++ b/sys/vm/vm_page.c @@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m) vm_page_dirty(m); } =20 +void +vm_page_lock_KBI(vm_page_t m, const char *file, int line) +{ + +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) + _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); +#else + __mtx_lock(vm_page_lockptr(m), 0, file, line); +#endif +} + +void +vm_page_unlock_KBI(vm_page_t m, const char *file, int line) +{ + +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) + _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); +#else + __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); +#endif +} + +int +vm_page_trylock_KBI(vm_page_t m, const char *file, int line) +{ + + return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); +} + +void +vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line) +{ + +#ifdef INVARIANTS + _mtx_assert(vm_page_lockptr(m), a, file, line); +#endif +} + int so_zerocp_fullpage =3D 0; =20 /* diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 7099b70..a5604b7 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[]; =20 #define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a)) =20 +#ifdef KLD_MODULE +#define vm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE, LOCK_LINE) +#define vm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE, LOCK_LINE) +#define vm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE, LOCK_LINE) +#ifdef INVARIANTS +#define vm_page_lock_assert(m, a) \ + vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE) +#else +#define vm_page_lock_assert(m, a) +#endif +#else /* KLD_MODULE */ #define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m)))) #define vm_page_lock(m) mtx_lock(vm_page_lockptr((m))) #define vm_page_unlock(m) mtx_unlock(vm_page_lockptr((m))) #define vm_page_trylock(m) mtx_trylock(vm_page_lockptr((m))) #define vm_page_lock_assert(m, a) mtx_assert(vm_page_lockptr((m)), (a)) +#endif =20 #define vm_page_queue_free_mtx vm_page_queue_free_lock.data /* @@ -403,6 +415,11 @@ void vm_page_cowfault (vm_page_t); int vm_page_cowsetup(vm_page_t); void vm_page_cowclear (vm_page_t); =20 +void vm_page_lock_KBI(vm_page_t m, const char *file, int line); +void vm_page_unlock_KBI(vm_page_t m, const char *file, int line); +int vm_page_trylock_KBI(vm_page_t m, const char *file, int line); +void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int lin= e); + #ifdef INVARIANTS void vm_page_object_lock_assert(vm_page_t m); #define VM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m) --etnyxeYqjisoB5dq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk64MvQACgkQC3+MBN1Mb4gTbwCg8s/W5utFC7JrcOQ2bZXrZDXD rO0An3XzVA512P2X7kcZpM9YQNz2fnZZ =RcUi -----END PGP SIGNATURE----- --etnyxeYqjisoB5dq-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:37:28 2011 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 C7D27106566C; Mon, 7 Nov 2011 19:37:28 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C7A988FC0C; Mon, 7 Nov 2011 19:37:27 +0000 (UTC) Received: by wwp14 with SMTP id 14so7197365wwp.31 for ; Mon, 07 Nov 2011 11:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GNwCkcRBQdx76CKtQAD9fPNuKW/+RVij8tHt5Na+wQo=; b=Yh2gmEqkw+9xAzdjB3iOK+dOVHvZuM+e34u8uVuegd9Xhe/zvmNHUNa0HAaOv06z35 zg2JAS9EiiRb24uIEmqJvNR6tHb3bynmQXyXyNjQm22j8ukUXKYPfqou2628zc6yBumk LsuzIJ7jFfkCMm10wzc2oc2yPJXZzxwttW98s= MIME-Version: 1.0 Received: by 10.181.13.165 with SMTP id ez5mr9320294wid.51.1320694646792; Mon, 07 Nov 2011 11:37:26 -0800 (PST) Received: by 10.180.81.200 with HTTP; Mon, 7 Nov 2011 11:37:26 -0800 (PST) In-Reply-To: References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> Date: Mon, 7 Nov 2011 14:37:26 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 19:37:28 -0000 Hi, On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe wrote: > On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao wrote: >> I'm unsure if this replies to your concerns because you just criticize >> without making a real technical question in this post. >> > I made comments on 3 points: > =A0- using internal implementation details of mutex(9) is broken > =A0- LOCK_FILE/LOCK_LINE are broken (a bit of a divergence on the > original subject :/) > =A0- there is _no_ reason not to use inlines function for such trivial on= eliners > ok, I read the original thread, now that I understand the purpose of the patch. It would make the third comment irrelevant, but I still do not agree about the reason of the patch. - ARnaud From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:48:00 2011 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 752EA1065673; Mon, 7 Nov 2011 19:48:00 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0548FC13; Mon, 7 Nov 2011 19:47:59 +0000 (UTC) Received: by pzk32 with SMTP id 32so183505pzk.3 for ; Mon, 07 Nov 2011 11:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=ci3msyrgrvjzL9BU8/AlR2uHmUEIDZ5aKlcWsUbnXJY=; b=Hg5ne2+nhOxla4fC/sol7cLya0NU3TvRSgxLmt8iB+5qtyswlQP6LEc75pQwzBty8y cSuqK0f6jtLRekraE8Ptcz+RAszkqUlkxydtk3qgJ/W1iyp5WEYi2ojnDfMF4JOdKjT3 4cu497XW0fuGiYye/ORMd3mZPQ2VB44FxkBVQ= MIME-Version: 1.0 Received: by 10.68.34.2 with SMTP id v2mr1642120pbi.112.1320695279497; Mon, 07 Nov 2011 11:47:59 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.49.35 with HTTP; Mon, 7 Nov 2011 11:47:59 -0800 (PST) In-Reply-To: <20111107193516.GA50300@deviant.kiev.zoral.com.ua> References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Date: Mon, 7 Nov 2011 11:47:59 -0800 X-Google-Sender-Auth: LR9P98FRelNvNf5bmIonO5oWkm4 Message-ID: From: mdf@FreeBSD.org To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 19:48:00 -0000 On Mon, Nov 7, 2011 at 11:35 AM, Kostik Belousov wrot= e: > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >> Ok. =A0I'll offer one final suggestion. =A0Please consider an alternativ= e >> suffix to "func". =A0Perhaps, "kbi" or "KBI". =A0In other words, somethi= ng >> that hints at the function's reason for existing. > > Sure. Below is the extraction of only vm_page_lock() bits, together > with the suggested rename. When Attilio provides the promised simplificat= ion > of the mutex KPI, this can be reduced. > > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > index 389aea5..ea4ea34 100644 > --- a/sys/vm/vm_page.c > +++ b/sys/vm/vm_page.c > @@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_dirty(m); > =A0} > > +void > +vm_page_lock_KBI(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); > +#endif > +} > + > +void > +vm_page_unlock_KBI(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); > +#endif > +} > + > +int > +vm_page_trylock_KBI(vm_page_t m, const char *file, int line) > +{ > + > + =A0 =A0 =A0 return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); > +} > + > +void > +vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line) > +{ > + > +#ifdef INVARIANTS > + =A0 =A0 =A0 _mtx_assert(vm_page_lockptr(m), a, file, line); > +#endif > +} > + > =A0int so_zerocp_fullpage =3D 0; > > =A0/* > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 7099b70..a5604b7 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[]; > > =A0#define =A0 =A0 =A0 =A0PA_LOCK_ASSERT(pa, a) =A0 mtx_assert(PA_LOCKPTR= (pa), (a)) > > +#ifdef KLD_MODULE > +#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 vm_page_lock_KBI(= (m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 vm_page_unlock_KBI(= (m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0vm_page_trylock_KBI= ((m), LOCK_FILE, LOCK_LINE) > +#ifdef INVARIANTS > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 \ > + =A0 =A0vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE) > +#else > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) > +#endif > +#else =A0/* KLD_MODULE */ > =A0#define =A0 =A0 =A0 =A0vm_page_lockptr(m) =A0 =A0 =A0(PA_LOCKPTR(VM_PA= GE_TO_PHYS((m)))) Is it not possible to have vm_page_lockptr() be a function for the KLD_MODULE case? Because then the vm_page_lock() functions and friends would all just use mtx_lock, etc., in both the KLD and non-KLD case. Or am I missing something? Thanks, matthew > =A0#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 mtx_lock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 mtx_unlock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0mtx_trylock(vm_pa= ge_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 mtx_asser= t(vm_page_lockptr((m)), (a)) > +#endif > > =A0#define =A0 =A0 =A0 =A0vm_page_queue_free_mtx =A0vm_page_queue_free_lo= ck.data > =A0/* > @@ -403,6 +415,11 @@ void vm_page_cowfault (vm_page_t); > =A0int vm_page_cowsetup(vm_page_t); > =A0void vm_page_cowclear (vm_page_t); > > +void vm_page_lock_KBI(vm_page_t m, const char *file, int line); > +void vm_page_unlock_KBI(vm_page_t m, const char *file, int line); > +int vm_page_trylock_KBI(vm_page_t m, const char *file, int line); > +void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int l= ine); > + > =A0#ifdef INVARIANTS > =A0void vm_page_object_lock_assert(vm_page_t m); > =A0#define =A0 =A0 =A0 =A0VM_PAGE_OBJECT_LOCK_ASSERT(m) =A0 vm_page_objec= t_lock_assert(m) > From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:58:37 2011 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 A22011065673; Mon, 7 Nov 2011 19:58:37 +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 372D78FC13; Mon, 7 Nov 2011 19:58:36 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA7JwXhX085850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2011 21:58:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA7JwX3h061202; Mon, 7 Nov 2011 21:58:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA7JwXZe061201; Mon, 7 Nov 2011 21:58:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Nov 2011 21:58:33 +0200 From: Kostik Belousov To: mdf@FreeBSD.org Message-ID: <20111107195833.GB50300@deviant.kiev.zoral.com.ua> References: <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Iyp50ur6m8WkwkNM" 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=-3.9 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: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@FreeBSD.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 19:58:37 -0000 --Iyp50ur6m8WkwkNM Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 07, 2011 at 11:47:59AM -0800, mdf@FreeBSD.org wrote: > On Mon, Nov 7, 2011 at 11:35 AM, Kostik Belousov wr= ote: > > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: > >> Ok. =9AI'll offer one final suggestion. =9APlease consider an alternat= ive > >> suffix to "func". =9APerhaps, "kbi" or "KBI". =9AIn other words, somet= hing > >> that hints at the function's reason for existing. > > > > Sure. Below is the extraction of only vm_page_lock() bits, together > > with the suggested rename. When Attilio provides the promised simplific= ation > > of the mutex KPI, this can be reduced. > > > > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > > index 389aea5..ea4ea34 100644 > > --- a/sys/vm/vm_page.c > > +++ b/sys/vm/vm_page.c > > @@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m) > > =9A =9A =9A =9A =9A =9A =9A =9Avm_page_dirty(m); > > =9A} > > > > +void > > +vm_page_lock_KBI(vm_page_t m, const char *file, int line) > > +{ > > + > > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > > + =9A =9A =9A _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); > > +#else > > + =9A =9A =9A __mtx_lock(vm_page_lockptr(m), 0, file, line); > > +#endif > > +} > > + > > +void > > +vm_page_unlock_KBI(vm_page_t m, const char *file, int line) > > +{ > > + > > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > > + =9A =9A =9A _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); > > +#else > > + =9A =9A =9A __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line= ); > > +#endif > > +} > > + > > +int > > +vm_page_trylock_KBI(vm_page_t m, const char *file, int line) > > +{ > > + > > + =9A =9A =9A return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); > > +} > > + > > +void > > +vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line) > > +{ > > + > > +#ifdef INVARIANTS > > + =9A =9A =9A _mtx_assert(vm_page_lockptr(m), a, file, line); > > +#endif > > +} > > + > > =9Aint so_zerocp_fullpage =3D 0; > > > > =9A/* > > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > > index 7099b70..a5604b7 100644 > > --- a/sys/vm/vm_page.h > > +++ b/sys/vm/vm_page.h > > @@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[]; > > > > =9A#define =9A =9A =9A =9APA_LOCK_ASSERT(pa, a) =9A mtx_assert(PA_LOCKP= TR(pa), (a)) > > > > +#ifdef KLD_MODULE > > +#define =9A =9A =9A =9Avm_page_lock(m) =9A =9A =9A =9A vm_page_lock_KB= I((m), LOCK_FILE, LOCK_LINE) > > +#define =9A =9A =9A =9Avm_page_unlock(m) =9A =9A =9A vm_page_unlock_KB= I((m), LOCK_FILE, LOCK_LINE) > > +#define =9A =9A =9A =9Avm_page_trylock(m) =9A =9A =9Avm_page_trylock_K= BI((m), LOCK_FILE, LOCK_LINE) > > +#ifdef INVARIANTS > > +#define =9A =9A =9A =9Avm_page_lock_assert(m, a) =9A =9A =9A \ > > + =9A =9Avm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE) > > +#else > > +#define =9A =9A =9A =9Avm_page_lock_assert(m, a) > > +#endif > > +#else =9A/* KLD_MODULE */ > > =9A#define =9A =9A =9A =9Avm_page_lockptr(m) =9A =9A =9A(PA_LOCKPTR(VM_= PAGE_TO_PHYS((m)))) >=20 > Is it not possible to have vm_page_lockptr() be a function for the > KLD_MODULE case? Because then the vm_page_lock() functions and > friends would all just use mtx_lock, etc., in both the KLD and non-KLD > case. >=20 > Or am I missing something? It is possible, but I tried to avoid exposing lockptr. IMHO vm_page_lockptr() is an implementation detail. Please also see my other response to Alan regarding the relocking macros. --Iyp50ur6m8WkwkNM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk64OGkACgkQC3+MBN1Mb4jJqwCglyA2fHh1mVljLEMhXz6p2dgX MNQAn2uDvMejSJFSA7ISTaWrNnEDGYcb =8Xfz -----END PGP SIGNATURE----- --Iyp50ur6m8WkwkNM-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 20:00:52 2011 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 1A3481065674; Mon, 7 Nov 2011 20:00:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4E18FC15; Mon, 7 Nov 2011 20:00:50 +0000 (UTC) Received: by wyg36 with SMTP id 36so6619258wyg.13 for ; Mon, 07 Nov 2011 12:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qdWPIJ7KwLK5EhXrFYU82B7bN/RbLQ/74oDYO4jIars=; b=HL07IigEZ0FOexWBLN0rkB9ztI6s9uraOW5Zwt0yKSWBgt8zNegGrafI3Dw7mDGRq7 FdyJR0PE04JFVlUBfpP9DXJ4ptx4YgoOeOmQ0W+tXDPRFmdwjEWIfCUzBA/Is3EkK5zo pSbcPYSntvwzViMX7Hl6T/HOvg7X7XtxQ7jrs= MIME-Version: 1.0 Received: by 10.180.90.148 with SMTP id bw20mr9670738wib.33.1320696049963; Mon, 07 Nov 2011 12:00:49 -0800 (PST) Received: by 10.180.81.200 with HTTP; Mon, 7 Nov 2011 12:00:49 -0800 (PST) In-Reply-To: <20111107193516.GA50300@deviant.kiev.zoral.com.ua> References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Date: Mon, 7 Nov 2011 15:00:49 -0500 Message-ID: From: Arnaud Lacombe To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] 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, 07 Nov 2011 20:00:52 -0000 Hi, On Mon, Nov 7, 2011 at 2:35 PM, Kostik Belousov wrote= : > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >> Ok. =A0I'll offer one final suggestion. =A0Please consider an alternativ= e >> suffix to "func". =A0Perhaps, "kbi" or "KBI". =A0In other words, somethi= ng >> that hints at the function's reason for existing. > > Sure. Below is the extraction of only vm_page_lock() bits, together > with the suggested rename. When Attilio provides the promised simplificat= ion > of the mutex KPI, this can be reduced. > If you want to be pedantic, you also must hide the definition of `struct vm_page' when KLD_MODULE is defined. You want to be sure no one is gonna mess with the internal of the structure (ie. either directly dereference fields, compute size or any offset...) and will have no other choice but to use assessors. Maybe you are addressing this in another patch. - Arnaud > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > index 389aea5..ea4ea34 100644 > --- a/sys/vm/vm_page.c > +++ b/sys/vm/vm_page.c > @@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_dirty(m); > =A0} > > +void > +vm_page_lock_KBI(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); > +#endif > +} > + > +void > +vm_page_unlock_KBI(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); > +#endif > +} > + > +int > +vm_page_trylock_KBI(vm_page_t m, const char *file, int line) > +{ > + > + =A0 =A0 =A0 return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); > +} > + > +void > +vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line) > +{ > + > +#ifdef INVARIANTS > + =A0 =A0 =A0 _mtx_assert(vm_page_lockptr(m), a, file, line); > +#endif > +} > + > =A0int so_zerocp_fullpage =3D 0; > > =A0/* > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 7099b70..a5604b7 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[]; > > =A0#define =A0 =A0 =A0 =A0PA_LOCK_ASSERT(pa, a) =A0 mtx_assert(PA_LOCKPTR= (pa), (a)) > > +#ifdef KLD_MODULE > +#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 vm_page_lock_KBI(= (m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 vm_page_unlock_KBI(= (m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0vm_page_trylock_KBI= ((m), LOCK_FILE, LOCK_LINE) > +#ifdef INVARIANTS > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 \ > + =A0 =A0vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE) > +#else > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) > +#endif > +#else =A0/* KLD_MODULE */ > =A0#define =A0 =A0 =A0 =A0vm_page_lockptr(m) =A0 =A0 =A0(PA_LOCKPTR(VM_PA= GE_TO_PHYS((m)))) > =A0#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 mtx_lock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 mtx_unlock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0mtx_trylock(vm_pa= ge_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 mtx_asser= t(vm_page_lockptr((m)), (a)) > +#endif > > =A0#define =A0 =A0 =A0 =A0vm_page_queue_free_mtx =A0vm_page_queue_free_lo= ck.data > =A0/* > @@ -403,6 +415,11 @@ void vm_page_cowfault (vm_page_t); > =A0int vm_page_cowsetup(vm_page_t); > =A0void vm_page_cowclear (vm_page_t); > > +void vm_page_lock_KBI(vm_page_t m, const char *file, int line); > +void vm_page_unlock_KBI(vm_page_t m, const char *file, int line); > +int vm_page_trylock_KBI(vm_page_t m, const char *file, int line); > +void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int l= ine); > + > =A0#ifdef INVARIANTS > =A0void vm_page_object_lock_assert(vm_page_t m); > =A0#define =A0 =A0 =A0 =A0VM_PAGE_OBJECT_LOCK_ASSERT(m) =A0 vm_page_objec= t_lock_assert(m) > From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 22:58:06 2011 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 E6AF51065677; Mon, 7 Nov 2011 22:58:06 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id BCD298FC0C; Mon, 7 Nov 2011 22:58:06 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNY8j-000HLp-DG; Mon, 07 Nov 2011 14:58:05 -0800 Message-ID: <4EB86276.6080801@sippysoft.com> Date: Mon, 07 Nov 2011 14:57:58 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4EB804D2.2090101@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ssp-trusted: yes X-Mailman-Approved-At: Mon, 07 Nov 2011 23:17:43 +0000 Cc: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 22:58:07 -0000 On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: > Unlikely; the inp is properly locked there and the udp info attach > better still be valid there; your problem is most likely elsewhere; > try to see if you have other threads and see what they do at the same > time, etc. You would need to race with udp_detach(); you also want > to make sure that the inp still looks sane from either ddb or a dump > and we are not talking about random memory corruption here. Well, as you can see from the trace it points pretty strongly to that piece of code. And as I said this panic is completely reproducible, we've seen it at least 5 times to date in exactly this location. Unfortunately the trace is rather long so we could not capture it in full before, until we've switched to the 80x50 mode. If it was a memory corruption it would be just random fault, while here we have it failing in this point reliably. Unfortunately the panic happens in the driver thread context (I believe), so the KDB/dump is not working. After panicing the machine just hangs there. Keyboard is not working and I need to do a hard reset. Is there any other explanation that you can think of? Is it possible for some other portion of the code (i.e. network driver, DMA engine etc) to trash this structure by writing something off bound? Or something along the lines? Thanks! Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 23:23:24 2011 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 40D82106564A; Mon, 7 Nov 2011 23:23:24 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6668FC1A; Mon, 7 Nov 2011 23:23:23 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNYXC-000HQ8-Oc; Mon, 07 Nov 2011 15:23:22 -0800 Message-ID: <4EB86866.9060102@sippysoft.com> Date: Mon, 07 Nov 2011 15:23:18 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> In-Reply-To: <4EB86276.6080801@sippysoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ssp-trusted: yes X-Mailman-Approved-At: Mon, 07 Nov 2011 23:42:44 +0000 Cc: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 23:23:24 -0000 On 11/7/2011 2:57 PM, Maxim Sobolev wrote: > On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: >> Unlikely; the inp is properly locked there and the udp info attach >> better still be valid there; your problem is most likely elsewhere; >> try to see if you have other threads and see what they do at the same >> time, etc. You would need to race with udp_detach(); you also want >> to make sure that the inp still looks sane from either ddb or a dump >> and we are not talking about random memory corruption here. > > Well, as you can see from the trace it points pretty strongly to that > piece of code. And as I said this panic is completely reproducible, > we've seen it at least 5 times to date in exactly this location. > Unfortunately the trace is rather long so we could not capture it in > full before, until we've switched to the 80x50 mode. > > If it was a memory corruption it would be just random fault, while here > we have it failing in this point reliably. > > Unfortunately the panic happens in the driver thread context (I > believe), so the KDB/dump is not working. After panicing the machine > just hangs there. Keyboard is not working and I need to do a hard reset. > > Is there any other explanation that you can think of? Is it possible for > some other portion of the code (i.e. network driver, DMA engine etc) to > trash this structure by writing something off bound? Or something along > the lines? OK, I've put the following catch to prove the case: up = intoudpcb(inp); if (up == NULL) { printf("BZZT! Something is terribly wrong, up == NULL!\n"); INP_RUNLOCK(inp); goto badunlocked; } if (up->u_tun_func == NULL) { I am going to give it a spin on two busiest boxes and see if I can log anything. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 09:26:45 2011 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 6FF67106566C for ; Tue, 8 Nov 2011 09:26:45 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 280B98FC0C for ; Tue, 8 Nov 2011 09:26:45 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id B2318119C6E; Tue, 8 Nov 2011 03:26:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320744404; bh=5gZzGjlNC8LK/p4yz8D365ui577LGuNmg4Wo4YbJXrc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=PsGb9rIoSxliKu/9o/2OVHJbCVqrr6ushEwpmUl8B+aaZrqTC0yipOk3kZoGW3ndq uVar9hedlXHo3T9n4afV4tyEu+DrbWtR+dP5iXVvpKbSMnmVZj5Fbv2DKa8wd4678R kTJzr8k9z7YyPxJi5T2VCZt1bYYlEL6tWExdfhv4= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id AD05B119C6D; Tue, 8 Nov 2011 03:26:44 -0600 (CST) Date: Tue, 8 Nov 2011 03:26:44 -0600 (CST) From: Dan The Man To: Garrett Cooper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: samba+zfs 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, 08 Nov 2011 09:26:45 -0000 Ok here is some specs: this been running fine on 8.2 stable and i was sure it was running fine on RC1 as well. I did some testing against samba 34 35 and 36 in the ports collection all with the same slow write problems. I did further testing mounting drive in question with NFS and it did not suffer the same problem, so it seems just samba related here, where samba would actually outperform my NFS mount before, now its taking 10x as long to write anything. This is really most simplistic setup I have, all I want to do is map a network drive at the house read/write so my laptop, desktop etc all have access to it. I have played with all the smb.conf options, and can't seem to find where the issue is, further research suggests others are experiencing same problems with beta3 from following forum post: http://forums.freebsd.org/showthread.php?t=27300 Hardware this is running on: I beleive a 4 year old amd chip and board, with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi drives for my storage space,which is mirrored nightly with rsync with another duplicate machine(cause I know someone is going to say why not use raid5-raidz) Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 addresses to he.net. I've played with nearly every option in smb.conf disabling, enabling etc and can't seem to find the issue: here are my current config file settings on machine that could apply to samba: asterisk:~# cat /boot/loader.conf autoboot_delay="5" accf_data_load="YES" aio_load="YES" zfs_load="YES" kern.maxbcache=64M kern.ipc.maxpipekva=4M vfs.zfs.prefetch_disable=1 vm.kmem_size="1844M" vfs.zfs.arc_min="1024M" vfs.zfs.arc_max="1536M" vfs.zfs.vdev.min_pending=2 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.zil_disable="1" ahci_load="YES" asterisk:~# asterisk:~# cat /usr/local/etc/smb.conf # Global parameters [global] workgroup = HOME netbios name = ASTERISK server string = "Primary backups" interfaces = sk0 #smb ports = 139 #security = USER security = SHARE encrypt passwords = Yes #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 domain master = no wins support = yes guest account = root socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = no level2 oplocks = True read raw = no write cache size = 262144 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes dns proxy = no max log size = 50 #log file = /dev/null log file = /var/log/samba.log debug level = 1 syslog = 0 [data] comment = "Primary backups" path = /data/public read only = No guest ok = Yes valid users = root asterisk:~# asterisk:~# cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 #raise file descriptors on the system kern.maxfiles=204916 kern.maxfilesperproc=204916 #raise sockets we can accept kern.ipc.somaxconn=32768 #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations net.inet.icmp.icmplim=500 kern.ipc.nmbjumbop=192000 kern.ipc.nmbclusters=229376 kern.ipc.maxsockets=204800 net.inet.tcp.maxtcptw=163840 #also add following to /boot/loader.conf #vm.kmem_size=1844M #kern.maxbcache=64M #kern.ipc.maxpipekva=4M #default setting of net.inet.ip.portrange.first is to low, causing us problems with bind net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 #DOS protection net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=50 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 #some stuff for samba kern.ipc.nmbclusters=32768 kern.maxvnodes=800000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=524288 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65535 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.tcp.mssdflt=1460 #IPSEC net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules #NFS--not concerned with data integrity when playing mostly already stored movies vfs.nfsrv.async=1 #JAIL #i like to use ping etc inside jail! security.jail.allow_raw_sockets=1 asterisk:~# Here are logs of me trying to mux a DTS mkv file from samba.log on debug level 10, I get the following over and over again: [2011/11/08 03:24:00.067974, 10] ../lib/util/util.c:415(dump_data) [2011/11/08 03:24:00.067981, 3] smbd/process.c:1466(switch_message) switch message SMBwriteX (pid 64308) conn 0x805008450 [2011/11/08 03:24:00.067990, 4] smbd/uid.c:345(change_to_user) Skipping user change - already user [2011/11/08 03:24:00.068001, 10] locking/locking.c:120(strict_lock_default) is_locked: optimisation - exclusive oplock on file torrent_downloads_finished/Point.Break.1991.720p (1).mkv [2011/11/08 03:24:00.068010, 10] locking/locking.c:162(strict_lock_default) strict_lock_default: flavour = WINDOWS_LOCK brl start=83431665 len=65536 unlocked for fnum 49966 file torrent_downloads_finished/Point.Break.1991.720p (1).mkv [2011/11/08 03:24:00.068021, 10] lib/recvfile.c:65(default_sys_recvfile) default_sys_recvfile: from = 33, to = 39, offset=83431665, count = 65536 [2011/11/08 03:24:00.068995, 10] smbd/fileio.c:143(real_write_file) real_write_file (torrent_downloads_finished/Point.Break.1991.720p (1).mkv): pos = 83431665, size = 65536, returned 65536 [2011/11/08 03:24:00.069013, 3] smbd/reply.c:4639(reply_write_and_X) writeX fnum=49966 num=65536 wrote=65536 [2011/11/08 03:24:00.069038, 10] lib/util_sock.c:516(read_smb_length_return_keepalive) got smb length of 65600 [2011/11/08 03:24:00.069052, 10] smbd/reply.c:4459(is_valid_writeX_buffer) is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 [2011/11/08 03:24:00.069062, 6] smbd/process.c:1659(process_smb) got message type 0x0 of len 0x3f [2011/11/08 03:24:00.069072, 3] smbd/process.c:1661(process_smb) Transaction 15398 of length 67 (65536 toread) [2011/11/08 03:24:00.069081, 5] lib/util.c:332(show_msg) [2011/11/08 03:24:00.069087, 5] lib/util.c:342(show_msg) size=63 smb_com=0x2f smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=24 smb_flg2=51207 smb_tid=1 smb_pid=65279 smb_uid=0 smb_mid=36032 smt_wct=14 smb_vwv[ 0]= 255 (0xFF) smb_vwv[ 1]=57054 (0xDEDE) smb_vwv[ 2]=49966 (0xC32E) smb_vwv[ 3]= 4337 (0x10F1) smb_vwv[ 4]= 1274 (0x4FA) smb_vwv[ 5]=65535 (0xFFFF) smb_vwv[ 6]=65535 (0xFFFF) smb_vwv[ 7]= 0 (0x0) smb_vwv[ 8]= 0 (0x0) smb_vwv[ 9]= 1 (0x1) smb_vwv[10]= 0 (0x0) smb_vwv[11]= 64 (0x40) smb_vwv[12]= 0 (0x0) smb_vwv[13]= 0 (0x0) smb_bcc=0 [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) [2011/11/08 03:24:00.069170, 3] smbd/process.c:1466(switch_message) switch message SMBwriteX (pid 64308) conn 0x805008450 [2011/11/08 03:24:00.069179, 4] smbd/uid.c:345(change_to_user) Skipping user change - already user [2011/11/08 03:24:00.069188, 10] locking/locking.c:120(strict_lock_default) is_locked: optimisation - exclusive oplock on file torrent_downloads_finished/Point.Break.1991.720p (1).mkv [2011/11/08 03:24:00.069197, 10] locking/locking.c:162(strict_lock_default) strict_lock_default: flavour = WINDOWS_LOCK brl start=83497201 len=65536 unlocked for fnum 49966 file torrent_downloads_finished/Point.Break.1991.720p (1).mkv [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfile) default_sys_recvfile: from = 33, to = 39, offset=83497201, count = 65536 [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) real_write_file (torrent_downloads_finished/Point.Break.1991.720p (1).mkv): pos = 83497201, size = 65536, returned 65536 [2011/11/08 03:24:00.070004, 3] smbd/reply.c:4639(reply_write_and_X) writeX fnum=49966 num=65536 wrote=65536 [2011/11/08 03:24:00.070030, 10] lib/util_sock.c:516(read_smb_length_return_keepalive) got smb length of 65600 [2011/11/08 03:24:00.070044, 10] smbd/reply.c:4459(is_valid_writeX_buffer) is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 [2011/11/08 03:24:00.070053, 6] smbd/process.c:1659(process_smb) got message type 0x0 of len 0x3f [2011/11/08 03:24:00.070063, 3] smbd/process.c:1661(process_smb) Transaction 15399 of length 67 (65536 toread) [2011/11/08 03:24:00.070072, 5] lib/util.c:332(show_msg) [2011/11/08 03:24:00.070077, 5] lib/util.c:342(show_msg) size=63 smb_com=0x2f smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=24 smb_flg2=51207 smb_tid=1 smb_pid=65279 smb_uid=0 smb_mid=36102 smt_wct=14 smb_vwv[ 0]= 255 (0xFF) smb_vwv[ 1]=57054 (0xDEDE) smb_vwv[ 2]=49966 (0xC32E) smb_vwv[ 3]= 4337 (0x10F1) smb_vwv[ 4]= 1275 (0x4FB) smb_vwv[ 5]=65535 (0xFFFF) smb_vwv[ 6]=65535 (0xFFFF) smb_vwv[ 7]= 0 (0x0) smb_vwv[ 8]= 0 (0x0) smb_vwv[ 9]= 1 (0x1) smb_vwv[10]= 0 (0x0) smb_vwv[11]= 64 (0x40) smb_vwv[12]= 0 (0x0) smb_vwv[13]= 0 (0x0) smb_bcc=0 Hopefully maybe someone can shine some light on this.... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com On Fri, 28 Oct 2011, Garrett Cooper wrote: > On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote: >> >> >> Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs >> its taking over an hour to just mux in things like DTS english, where it was >> 15 minutes on beta3. > > Hi Dan, > - Can you do more deterministic / scientific benchmarks? > - Did you upgrade Samba? > - What is your system's operating hardware profile? > Thanks! > -Garrett > From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 09:32:34 2011 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 72802106564A for ; Tue, 8 Nov 2011 09:32:34 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2A33E8FC19 for ; Tue, 8 Nov 2011 09:32:34 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id BF98B119C6F; Tue, 8 Nov 2011 03:32:33 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320744753; bh=A9p4zyDMrMN9xz8kzDh+nqLN5QkxEoNLv1M75ubIX3A=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=HRVpWMJZ1KqAZCBKTYt8N7SzgsChCJpzf2xANIZoZ9XA5tRZzobkW0DcoT424yHyk pgKiK+gtweOsAdTECTs8P80Dl9a4sG1QTega6IoCsX0bURayoA1iaji7g1PNpUgbx0 17yR2UAQptPG1d9D1sB2HbKqkYCo2mmqwONILgP4= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id BEACA119C6E; Tue, 8 Nov 2011 03:32:33 -0600 (CST) Date: Tue, 8 Nov 2011 03:32:33 -0600 (CST) From: Dan The Man To: Garrett Cooper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: samba+zfs 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, 08 Nov 2011 09:32:34 -0000 Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: asterisk:~# uname -a FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 19:46:53 CDT 2011 droot@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 asterisk:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com On Tue, 8 Nov 2011, Dan The Man wrote: > > Ok here is some specs: this been running fine on 8.2 stable and i was sure it > was running fine on RC1 as well. I did some testing against samba 34 35 and > 36 in the ports collection all with the same slow write problems. > > I did further testing mounting drive in question with NFS and it did not > suffer the same problem, so it seems just samba related here, where samba > would actually outperform my NFS mount before, now its taking 10x as long > to write anything. > > This is really most simplistic setup I have, all I want to do is map a > network drive at the house read/write so my laptop, desktop etc all have > access to it. I have played with all the smb.conf options, and can't seem > to find where the issue is, further research suggests others are experiencing > same problems with beta3 from following forum post: > > http://forums.freebsd.org/showthread.php?t=27300 > > Hardware this is running on: I beleive a 4 year old amd chip and board, with > 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS > boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi > drives for my storage space,which is mirrored nightly with rsync with another > duplicate machine(cause I know someone is going to say why not use > raid5-raidz) > > Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 > addresses to he.net. > > I've played with nearly every option in smb.conf disabling, enabling etc and > can't seem to find the issue: here are my current config file settings on > machine that could apply to samba: > > asterisk:~# cat /boot/loader.conf > autoboot_delay="5" > accf_data_load="YES" > aio_load="YES" > zfs_load="YES" > kern.maxbcache=64M > kern.ipc.maxpipekva=4M > > vfs.zfs.prefetch_disable=1 > vm.kmem_size="1844M" > vfs.zfs.arc_min="1024M" > vfs.zfs.arc_max="1536M" > vfs.zfs.vdev.min_pending=2 > vfs.zfs.vdev.max_pending=8 > vfs.zfs.txg.timeout=5 > vfs.zfs.zil_disable="1" > ahci_load="YES" > asterisk:~# > > asterisk:~# cat /usr/local/etc/smb.conf > # Global parameters > [global] > workgroup = HOME > netbios name = ASTERISK > server string = "Primary backups" > interfaces = sk0 > #smb ports = 139 > #security = USER > security = SHARE > encrypt passwords = Yes > #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 > domain master = no > wins support = yes > guest account = root > socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY > use sendfile = no > level2 oplocks = True > read raw = no > write cache size = 262144 > min receivefile size = 16384 > aio read size = 16384 > aio write size = 16384 > aio write behind = yes > dns proxy = no > max log size = 50 > #log file = /dev/null > log file = /var/log/samba.log > debug level = 1 > syslog = 0 > > [data] > comment = "Primary backups" > path = /data/public > read only = No > guest ok = Yes > valid users = root > asterisk:~# asterisk:~# cat /etc/sysctl.conf > # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ > # > # This file is read when going to multi-user and its contents piped thru > # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. > # > > # Uncomment this to prevent users from seeing information about processes > that > # are being run under another UID. > #security.bsd.see_other_uids=0 > > #raise file descriptors on the system > kern.maxfiles=204916 > kern.maxfilesperproc=204916 > > #raise sockets we can accept > kern.ipc.somaxconn=32768 > > #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html > kern.ipc.maxsockbuf=16777216 > net.inet.tcp.rfc1323=1 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.sendspace=65536 > net.inet.tcp.recvspace=131072 > > #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations > net.inet.icmp.icmplim=500 > kern.ipc.nmbjumbop=192000 > kern.ipc.nmbclusters=229376 > kern.ipc.maxsockets=204800 > net.inet.tcp.maxtcptw=163840 > #also add following to /boot/loader.conf > #vm.kmem_size=1844M > #kern.maxbcache=64M > #kern.ipc.maxpipekva=4M > > #default setting of net.inet.ip.portrange.first is to low, causing us > problems with bind > net.inet.ip.portrange.last=65535 > net.inet.ip.portrange.first=1024 > > #DOS protection > net.inet.tcp.msl=7500 > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > net.inet.icmp.icmplim=50 > net.inet.ip.accept_sourceroute=0 > net.inet.ip.sourceroute=0 > > #some stuff for samba > kern.ipc.nmbclusters=32768 > kern.maxvnodes=800000 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.recvbuf_auto=1 > net.inet.tcp.recvbuf_inc=524288 > net.inet.tcp.sendbuf_auto=1 > net.inet.tcp.sendbuf_inc=524288 > net.inet.udp.maxdgram=57344 > net.inet.udp.recvspace=65535 > net.local.stream.recvspace=65535 > net.local.stream.sendspace=65535 > net.inet.tcp.mssdflt=1460 > > #IPSEC > net.inet.ip.forwarding=1 > net.inet6.ip6.forwarding=1 > kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules > > > #NFS--not concerned with data integrity when playing mostly already stored > movies > vfs.nfsrv.async=1 > > #JAIL > #i like to use ping etc inside jail! > security.jail.allow_raw_sockets=1 > asterisk:~# > > > Here are logs of me trying to mux a DTS mkv file from samba.log on debug > level 10, I get the following over and over again: > > [2011/11/08 03:24:00.067974, 10] ../lib/util/util.c:415(dump_data) > [2011/11/08 03:24:00.067981, 3] smbd/process.c:1466(switch_message) > switch message SMBwriteX (pid 64308) conn 0x805008450 > [2011/11/08 03:24:00.067990, 4] smbd/uid.c:345(change_to_user) > Skipping user change - already user > [2011/11/08 03:24:00.068001, 10] locking/locking.c:120(strict_lock_default) > is_locked: optimisation - exclusive oplock on file > torrent_downloads_finished/Point.Break.1991.720p (1).mkv > [2011/11/08 03:24:00.068010, 10] locking/locking.c:162(strict_lock_default) > strict_lock_default: flavour = WINDOWS_LOCK brl start=83431665 len=65536 > unlocked for fnum 49966 file torrent_downloads_finished/Point.Break.1991.720p > (1).mkv > [2011/11/08 03:24:00.068021, 10] lib/recvfile.c:65(default_sys_recvfile) > default_sys_recvfile: from = 33, to = 39, offset=83431665, count = 65536 > [2011/11/08 03:24:00.068995, 10] smbd/fileio.c:143(real_write_file) > real_write_file (torrent_downloads_finished/Point.Break.1991.720p (1).mkv): > pos = 83431665, size = 65536, returned 65536 > [2011/11/08 03:24:00.069013, 3] smbd/reply.c:4639(reply_write_and_X) > writeX fnum=49966 num=65536 wrote=65536 > [2011/11/08 03:24:00.069038, 10] > lib/util_sock.c:516(read_smb_length_return_keepalive) > got smb length of 65600 > [2011/11/08 03:24:00.069052, 10] smbd/reply.c:4459(is_valid_writeX_buffer) > is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 > [2011/11/08 03:24:00.069062, 6] smbd/process.c:1659(process_smb) > got message type 0x0 of len 0x3f > [2011/11/08 03:24:00.069072, 3] smbd/process.c:1661(process_smb) > Transaction 15398 of length 67 (65536 toread) > [2011/11/08 03:24:00.069081, 5] lib/util.c:332(show_msg) > [2011/11/08 03:24:00.069087, 5] lib/util.c:342(show_msg) > size=63 > smb_com=0x2f > smb_rcls=0 > smb_reh=0 > smb_err=0 > smb_flg=24 > smb_flg2=51207 > smb_tid=1 > smb_pid=65279 > smb_uid=0 > smb_mid=36032 > smt_wct=14 > smb_vwv[ 0]= 255 (0xFF) > smb_vwv[ 1]=57054 (0xDEDE) > smb_vwv[ 2]=49966 (0xC32E) > smb_vwv[ 3]= 4337 (0x10F1) > smb_vwv[ 4]= 1274 (0x4FA) > smb_vwv[ 5]=65535 (0xFFFF) > smb_vwv[ 6]=65535 (0xFFFF) > smb_vwv[ 7]= 0 (0x0) > smb_vwv[ 8]= 0 (0x0) > smb_vwv[ 9]= 1 (0x1) > smb_vwv[10]= 0 (0x0) > smb_vwv[11]= 64 (0x40) > smb_vwv[12]= 0 (0x0) > smb_vwv[13]= 0 (0x0) > smb_bcc=0 > [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) > [2011/11/08 03:24:00.069170, 3] smbd/process.c:1466(switch_message) > switch message SMBwriteX (pid 64308) conn 0x805008450 > [2011/11/08 03:24:00.069179, 4] smbd/uid.c:345(change_to_user) > Skipping user change - already user > [2011/11/08 03:24:00.069188, 10] locking/locking.c:120(strict_lock_default) > is_locked: optimisation - exclusive oplock on file > torrent_downloads_finished/Point.Break.1991.720p (1).mkv > [2011/11/08 03:24:00.069197, 10] locking/locking.c:162(strict_lock_default) > strict_lock_default: flavour = WINDOWS_LOCK brl start=83497201 len=65536 > unlocked for fnum 49966 file torrent_downloads_finished/Point.Break.1991.720p > (1).mkv > [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfile) > default_sys_recvfile: from = 33, to = 39, offset=83497201, count = 65536 > [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) > real_write_file (torrent_downloads_finished/Point.Break.1991.720p (1).mkv): > pos = 83497201, size = 65536, returned 65536 > [2011/11/08 03:24:00.070004, 3] smbd/reply.c:4639(reply_write_and_X) > writeX fnum=49966 num=65536 wrote=65536 > [2011/11/08 03:24:00.070030, 10] > lib/util_sock.c:516(read_smb_length_return_keepalive) > got smb length of 65600 > [2011/11/08 03:24:00.070044, 10] smbd/reply.c:4459(is_valid_writeX_buffer) > is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 > [2011/11/08 03:24:00.070053, 6] smbd/process.c:1659(process_smb) > got message type 0x0 of len 0x3f > [2011/11/08 03:24:00.070063, 3] smbd/process.c:1661(process_smb) > Transaction 15399 of length 67 (65536 toread) > [2011/11/08 03:24:00.070072, 5] lib/util.c:332(show_msg) > [2011/11/08 03:24:00.070077, 5] lib/util.c:342(show_msg) > size=63 > smb_com=0x2f > smb_rcls=0 > smb_reh=0 > smb_err=0 > smb_flg=24 > smb_flg2=51207 > smb_tid=1 > smb_pid=65279 > smb_uid=0 > smb_mid=36102 > smt_wct=14 > smb_vwv[ 0]= 255 (0xFF) > smb_vwv[ 1]=57054 (0xDEDE) > smb_vwv[ 2]=49966 (0xC32E) > smb_vwv[ 3]= 4337 (0x10F1) > smb_vwv[ 4]= 1275 (0x4FB) > smb_vwv[ 5]=65535 (0xFFFF) > smb_vwv[ 6]=65535 (0xFFFF) > smb_vwv[ 7]= 0 (0x0) > smb_vwv[ 8]= 0 (0x0) > smb_vwv[ 9]= 1 (0x1) > smb_vwv[10]= 0 (0x0) > smb_vwv[11]= 64 (0x40) > smb_vwv[12]= 0 (0x0) > smb_vwv[13]= 0 (0x0) > smb_bcc=0 > > > Hopefully maybe someone can shine some light on this.... > > > Dan. > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: Dan@SunSaturn.com > > On Fri, 28 Oct 2011, Garrett Cooper wrote: > >> On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote: >>> >>> >>> Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs >>> its taking over an hour to just mux in things like DTS english, where it >>> was >>> 15 minutes on beta3. >> >> Hi Dan, >> - Can you do more deterministic / scientific benchmarks? >> - Did you upgrade Samba? >> - What is your system's operating hardware profile? >> Thanks! >> -Garrett >> > _______________________________________________ > 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 Nov 8 09:41:35 2011 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 18DC51065672 for ; Tue, 8 Nov 2011 09:41:35 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id E24DD8FC12 for ; Tue, 8 Nov 2011 09:41:34 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 787DE119C6E; Tue, 8 Nov 2011 03:41:34 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320745294; bh=3myOnq8v2crksGdj7U4MN39LpKYNZsJd5cnxJSfWvlw=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-ID; b=VFk/bh0baM+f/dWZmv3Pn8dAWRAZGo5rH212eZUFqBmN8IAkWqqS4Ah96bvtSD0gH yGqpKmt7RDruoAQtpUb9l71623Tb5aiYIxnSL2yuDtwhsAv/y9VuDGlEYPMTs2Q23f eqLIbAKNs/3rJ56gGY8RC77a19IUak41RfeN9Lyk= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 7398B119C6D for ; Tue, 8 Nov 2011 03:41:34 -0600 (CST) Date: Tue, 8 Nov 2011 03:41:34 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="_----------=_131779211244141" Content-ID: Subject: Proftpd + Freebsd 9 + mod_mysql 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, 08 Nov 2011 09:41:35 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --_----------=_131779211244141 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Not sure if anyone else is having problem with proftpd on freebsd 9, but here is a patch to stop it terminating, should be included in next release, courtesy of TJ saunders working with me on it. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com --_----------=_131779211244141 Content-Type: APPLICATION/OCTET-STREAM; NAME=freebsd-mysql-signal.patch Content-Transfer-Encoding: BASE64 Content-ID: <4790cbe4f85a3f2df2d90011d7a4215864a11887@messagingengine.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=freebsd-mysql-signal.patch SW5kZXg6IHNyYy90aW1lcnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJD UyBmaWxlOiAvY3Zzcm9vdC9wcm9mdHAvcHJvZnRwZC9zcmMvdGltZXJzLmMs dgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzcKZGlmZiAtdSAtcjEuMzcgdGlt ZXJzLmMKLS0tIHNyYy90aW1lcnMuYwkyMyBNYXkgMjAxMSAyMToyMjoyNCAt MDAwMAkxLjM3CisrKyBzcmMvdGltZXJzLmMJNSBPY3QgMjAxMSAwNToxOTo1 MyAtMDAwMApAQCAtMTU5LDE4ICsxNTksMjYgQEAKIH0KIAogc3RhdGljIFJF VFNJR1RZUEUgc2lnX2FsYXJtKGludCBzaWdubykgeworI2lmZGVmIFNBX0lO VEVSUlVQVAogICBzdHJ1Y3Qgc2lnYWN0aW9uIGFjdDsKIAogICBhY3Quc2Ff aGFuZGxlciA9IHNpZ19hbGFybTsKICAgc2lnZW1wdHlzZXQoJmFjdC5zYV9t YXNrKTsKLSAgYWN0LnNhX2ZsYWdzID0gMDsKLQotI2lmZGVmIFNBX0lOVEVS UlVQVAotICBhY3Quc2FfZmxhZ3MgfD0gU0FfSU5URVJSVVBUOwotI2VuZGlm CisgIGFjdC5zYV9mbGFncyA9IFNBX0lOVEVSUlVQVDsKIAogICAvKiBJbnN0 YWxsIHRoaXMgaGFuZGxlciBmb3IgU0lHQUxSTS4gKi8KLSAgc2lnYWN0aW9u KFNJR0FMUk0sICZhY3QsIE5VTEwpOworICBpZiAoc2lnYWN0aW9uKFNJR0FM Uk0sICZhY3QsIE5VTEwpIDwgMCkgeworICAgIHByX2xvZ19wcmkoUFJfTE9H X05PVElDRSwKKyAgICAgICJ1bmFibGUgdG8gaW5zdGFsbCBTSUdBTFJNIGhh bmRsZXIgdmlhIHNpZ2FjdGlvbigyKTogJXMiLAorICAgICAgc3RyZXJyb3Io ZXJybm8pKTsKKyAgfQorI2Vsc2UKKyAgaWYgKHNpZ25hbChTSUdBTFJNLCBz aWdfYWxhcm0pID09IFNJR19FUlIpIHsKKyAgICBwcl9sb2dfcHJpKFBSX0xP R19OT1RJQ0UsCisgICAgICAidW5hYmxlIHRvIGluc3RhbGwgU0lHQUxSTSBo YW5kbGVyIHZpYSBzaWduYWwoMyk6ICVzIiwKKyAgICAgIHN0cmVycm9yKGVy cm5vKSk7CisgIH0KKyNlbmRpZgogCiAjaWZkZWYgSEFWRV9TSUdJTlRFUlJV UFQKICAgc2lnaW50ZXJydXB0KFNJR0FMUk0sIDEpOwpAQCAtMTg4LDE3ICsx OTYsMjYgQEAKIH0KIAogc3RhdGljIHZvaWQgc2V0X3NpZ19hbGFybSh2b2lk KSB7CisjaWZkZWYgU0FfSU5URVJSVVBUCiAgIHN0cnVjdCBzaWdhY3Rpb24g YWN0OwogCiAgIGFjdC5zYV9oYW5kbGVyID0gc2lnX2FsYXJtOwogICBzaWdl bXB0eXNldCgmYWN0LnNhX21hc2spOwotICBhY3Quc2FfZmxhZ3MgPSAwOwot I2lmZGVmIFNBX0lOVEVSUlVQVAotICBhY3Quc2FfZmxhZ3MgfD0gU0FfSU5U RVJSVVBUOwotI2VuZGlmCisgIGFjdC5zYV9mbGFncyA9IFNBX0lOVEVSUlVQ VDsKIAogICAvKiBJbnN0YWxsIHRoaXMgaGFuZGxlciBmb3IgU0lHQUxSTS4g Ki8KLSAgc2lnYWN0aW9uKFNJR0FMUk0sICZhY3QsIE5VTEwpOworICBpZiAo c2lnYWN0aW9uKFNJR0FMUk0sICZhY3QsIE5VTEwpIDwgMCkgeworICAgIHBy X2xvZ19wcmkoUFJfTE9HX05PVElDRSwKKyAgICAgICJ1bmFibGUgdG8gaW5z dGFsbCBTSUdBTFJNIGhhbmRsZXIgdmlhIHNpZ2FjdGlvbigyKTogJXMiLAor ICAgICAgc3RyZXJyb3IoZXJybm8pKTsKKyAgfQorI2Vsc2UKKyAgaWYgKHNp Z25hbChTSUdBTFJNLCBzaWdfYWxhcm0pID09IFNJR19FUlIpIHsKKyAgICBw cl9sb2dfcHJpKFBSX0xPR19OT1RJQ0UsCisgICAgICAidW5hYmxlIHRvIGlu c3RhbGwgU0lHQUxSTSBoYW5kbGVyIHZpYSBzaWduYWwoMyk6ICVzIiwKKyAg ICAgIHN0cmVycm9yKGVycm5vKSk7CisgIH0KKyNlbmRpZgogCiAjaWZkZWYg SEFWRV9TSUdJTlRFUlJVUFQKICAgc2lnaW50ZXJydXB0KFNJR0FMUk0sIDEp Owo= --_----------=_131779211244141-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 09:55:09 2011 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 442B11065672; Tue, 8 Nov 2011 09:55:09 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 265258FC17; Tue, 8 Nov 2011 09:55:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA89t9ZN081491; Tue, 8 Nov 2011 09:55:09 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA89t9Zu081490; Tue, 8 Nov 2011 09:55:09 GMT (envelope-from danger) Date: Tue, 8 Nov 2011 09:55:09 +0000 From: Daniel Gerzo To: stable@freebsd.org Message-ID: <20111108095508.GA81445@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org, current@freebsd.org Subject: FreeBSD Status Report July-September, 2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@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: Tue, 08 Nov 2011 09:55:09 -0000 FreeBSD Quarterly Status Report - Q3/2011 Introduction This report covers FreeBSD-related projects between July and September 2011. It is the third of the four reports planned for 2011. This quarter was mainly devoted to polishing the bits for the next major version of FreeBSD, 9.0, which is to be released by then end of this year. Thanks to all the reporters for the excellent work! This report contains 28 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between October and December 2011 is January 15th, 2012. __________________________________________________________________ Projects * GELI status update * HAST (Highly Available Storage) status update * pfSense * Tool for providing FreeBSD VM Images * ZFSguru * ZRouter.org project -- a FreeBSD-based firmware for embedded devices FreeBSD Team Reports * Ports Collection * The FreeBSD Foundation * The FreeBSD Release Engineering Team Network Infrastructure * 802.11n / atheros * DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) * Ethernet Switch Framework Kernel * The new CARP * VM layer for allocations larger than a page Documentation * Doc sprint on IRC, September 5, 2011 * The FreeBSD German Documentation Project Status Report * The FreeBSD Greek Documentation Project * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on Marvell Armada XP * FreeBSD/powerpc on AppliedMicro APM86290 Ports * FreeBSD Haskell Ports * KDE-FreeBSD * OpenAFS port * Portmaster Miscellaneous * bsd_day(2011) * EuroBSDcon 2011 * FreeBSD Developer Summit, Maarssen Google Summer of Code * Multibyte Encoding Support in Nvi __________________________________________________________________ 802.11n / atheros URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosTxAgg Contact: Adrian Chadd AR5416, AR9160, and AR9280 functions in both station and hostap mode. Performance is good. Software retry of frames is implemented. Aggregation is implemented. BAR TX is not yet handled. HT protection is not implemented; neither is MIMO powersave. Open tasks: 1. BAR TX 2. MIMO powersave 3. Correct handling of flushing TX queues during interface reset/reconfigure 4. Correct handling of 20<->20/40mhz transitions (without dropping frames) 5. More intelligent rate control __________________________________________________________________ bsd_day(2011) URL: http://bsdday.eu/2011 Contact: Martin Matuska Contact: Gabor Pali The purpose of this one-day event was to gather Central European developers of today's open-source BSD systems to popularize their work and their organizations, and to meet each other in the real life. We wanted to motivate potential future developers and users, especially undergraduate university students, to work with BSD systems. This year's BSD-Day was be held in Bratislava, Slovakia at Slovak University of Technology, Faculty of Electrical Engineering and Information Technology on November 5, 2011. __________________________________________________________________ DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) URL: http://caia.swin.edu.au/freebsd/diffused/ URL: http://www.FreeBSDFoundation.org/project%20announcements.shtml#diffuse URL: http://caia.swin.edu.au/urp/diffuse/ URL: http://caia.swin.edu.au/urp/diffuse/downloads.html Contact: Sebastian Zander Contact: Lawrence Stewart Contact: Grenville Armitage DIFFUSE enables FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) to classify flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc.) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. The FreeBSD Foundation has funded the Centre for Advanced Internet Architectures at Swinburne University of Technology to undertake the DIFFUSED (DIFFUSE for freebsD) project, which aims to refine our publicly released DIFFUSE prototype and integrate all components of the architecture into FreeBSD. The project is progressing well in the diffused_head project branch of the FreeBSD Subversion repository, and is due to be completed by the end of October 2011. Once the project is completed, the code will be merged from the project branch into the head branch. An MFC of the code to 8.x and 9.x should be possible after an appropriate amount of soak time has elapsed. __________________________________________________________________ Doc sprint on IRC, September 5, 2011 URL: http://people.FreeBSD.org/~bcr/doc/sprints/20110905-final.html Contact: Benedict Reuschling Contact: Dru Lavigne On September 5, we held another documentation sprint on IRC channel #bsddocs to discuss various issues that are important for the whole FreeBSD documentation community. We talked about the status of the planned documentation repository conversion to SVN and the status of the XML docbook conversion. At that point in time, we did not have any documentation regarding the new bsdinstaller in the upcoming release, which would have been very bad for users that were trying to install the release. Luckily, a small team formed quickly to start working on a new bsdinstall chapter from scratch using a separate google code repository that gjb@ had set up. Some of the topics we discussed were moved forward and their status was revisited at EuroBSDcon's devsummit documentation session. Before the end of the conference, we had a new bsdinstall chapter committed into the official documentation tree, thanks to the efforts put into the new chapter by Gavin Atkinson, Warren Block, and Glen Barber. Garrett Cooper provided valuable instructions on the various installation methods that are possible with the new bsdinstaller. Thanks to all who helped make this a reality. It is nice to see that the things we talked about at the documentation sprint developed further, which is why we are trying to do these sprints in regular intervalls. Open tasks: 1. Plan the next documentation sprint 2. Continue working on the issues that are still open like the conversion of the repository to SVN __________________________________________________________________ Ethernet Switch Framework URL: http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/switch Contact: Aleksandr Rybalko Many embedded devices have an Ethernet switch on board; such switches are even embedded on some multiport NICs. This embedded switch framework is designed to give users the ability to easily control basic features present in managed switches, such as VLANs, QoS, port mirroring, etc. Currently we are able to control only VLANs on: * Atheros AR8216/AR8316 (standalone and embedded in AR724X) * Broadcom BCM5325 switch family (also embedded in BCM5354 SoC) * Ralink RT3050F/RT3052F internal switch * Realtek RTL8309 * IP175X * IP178X Open tasks: 1. Fix AR8216/AR8316 driver 2. Fix BCM5325 driver, not all ports pass data 3. Add tick handler for RTL8309 to automatically unisolate ports 4. Unify MIB statistic counters access 5. Add mii read/write bus methods 6. Implement pseudo interfaces for switch PHYs __________________________________________________________________ EuroBSDcon 2011 URL: http://2011.eurobsdcon.org/ Contact: EuroBSDcon Organizers Contact: Gabor Pali The 10th anniversary European BSD Conference was organized in Maarssen, The Netherlands with more than 250 registered visitors. There were many interesting tutorials, including introductions to DTrace and working with Netgraph. It featured 26 high-quality talks and 2 keynote speakers on various topics related to FreeBSD, OpenBSD, NetBSD, or even MINIX: OpenBSD PF, NetBSD NPF, IPv6 support in FreeBSD, virtualization in the BSD domain, recent developments in OpenSSH, exploration of the recent FreeNAS, system management with ZFS, practical capabilities for UNIX known as Capsicum. It also had a dedicated track for the attendees of the FreeBSD developer summit, where one could learn more about what is happening currently in the Project. We had presentations on the new package management solution, Google Summer of Code 2011, a stacked cryptographic file system, conversion of documents of different formats, and status reports on the sparc64 port and the NAND flash support. __________________________________________________________________ FreeBSD Developer Summit, Maarssen URL: http://wiki.FreeBSD.org/201110DevSummit Contact: Gabor Pali We had 60 FreeBSD developers and invited guests attending the FreeBSD Developer Summit organized as part of EuroBSDcon 2011 in Maarssen, The Netherlands. This year EuroBSDcon organizers offered us their generous support in handling the details, like registrations, renting the venue, and providing food for keeping attendees happy. The Maarssen developer summit spanned over 3 days. It is generally a workshop-style event that has now adopted the layout of the developer summit organized successfully in Canada earlier in May. On the first day, there were working groups on various topics, e.g. Capsicum, toolchain issues, ports, and documentation. On the second day, there were various plenary discussions, like how FreeBSD relates to virtualization or how vendors relate to FreeBSD. Finally, on the third day, there were many interesting work-in-progress reports given in a dedicated developer summit track at the main conference. Photos and slides for the most of the talks are available on the home page of the summit. __________________________________________________________________ FreeBSD Haskell Ports Contact: Gabor Janos PaLI Contact: Ashish SHUKLA We updated existing ports to their latest versions and hunted down a bug in the 9-CURRENT rtld which was causing GHC to crash intermittently. We also started work on Haskell Platform 2011.3.0.0 (development version) in a separate git branch in our development repository. Open tasks: 1. Test GHC to work with clang/LLVM. 2. Add an option to the GHC port to be able to build it with already installed GHC instead of requiring a separate GHC boostrap tarball. 3. Update Haskell Platform (along with GHC) to 2011.4.0.0 as soon as it gets out. 4. Add more ports to the Ports collection. __________________________________________________________________ FreeBSD/arm on Marvell Armada XP Contact: Grzegorz Bernacki Contact: Rafal Jaworowski Marvell Armada XP is a complete system-on-chip solution based on the Sheeva embedded CPUs. These devices integrate up to four ARMv6/v7 compliant Sheeva CPU cores with shared L2 cache. This work is extending FreeBSD/arm infrastructure towards support for recent ARM architecture variations along with a basic set of device drivers for integrated peripherals. The following code has been implemented since the last status report: * PCI-Express support * SMP support * + Created framework for ARM platform dependent code. + Initialization and starting of Application Processor. + Implementation of sending/handling IPI Next steps: * Finalize SMP support (TLB/cache operation broadcast, etc.) * L2 cache support * SATA driver __________________________________________________________________ FreeBSD/powerpc on AppliedMicro APM86290 Contact: Grzegorz Bernacki Contact: Rafal Jaworowski The APM86290 system-on-chip device is a member of AppliedMicro's PACKETpro family of embedded processors. The chip includes two Power Architecture PPC465 processor cores, which are compliant with the Book-E specification of the architecture, and a number of integrated peripherals. This work is extending current Book-E support in FreeBSD towards PPC4xx processor variants along with device drivers for integrated peripherials. The following drivers have been created since the last report: * Interrupt controller * EHCI USB driver attachment * Queue Manager/Traffic Manager support * Initial support of Ethernet controller * GPIO, I2C Next steps: * Finalize Ethernet controller driver * L2 cache support __________________________________________________________________ GELI status update Contact: Pawel Jakub Dawidek Selected GELI (disk encryption GEOM class) changes since 2010/Q3 report: * Implementation of suspend/resume functionality. * New version subcommand to check GELI providers version. * New -V option for init subcommand, which allows to create GELI providers for older FreeBSD versions. * Significant aesni(4) performance improvements for AES-XTS algorithm. __________________________________________________________________ HAST (Highly Available Storage) status update Contact: Pawel Jakub Dawidek Contact: Mikolaj Golub HAST is under active development. Some changes since Q1 report: * Async replication mode. Unfortunately it will not make it into 9.0-RELEASE (pjd@). * IPv6 support (pjd@). * Activemap fix that significantly reduces number of metadata updates (trociny@). * Provider's write cache flush after metadata updates (pjd@). * Possibility to specify pidfile in configuration file (pjd@). * Many bug fixes and other improvments. __________________________________________________________________ KDE-FreeBSD URL: FreeBSD.kde.org URL: http://dot.kde.org/2011/06/29/platform-frameworks-kde-hackers-meet-swit zerland URL: http://blogs.FreeBSDish.org/avilla/2011/06/14/call-for-tests-kde-pim-4- 6-0 URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD Alberto Villa and Raphael Kubo da Costa went to Randa, Switzerland, to attend, respectively, the KDE Multimedia/Kdenlive sprint and the Platform 11 sprint. The sprints afforded them the opportunity to form closer bonds with the upstream KDE community, to learn about the future of Qt and KDE and make sure FreeBSD's needs are taken into account. For more information see the article "From Platform to Frameworks -- KDE hackers meet in Switzerland" at dot.kde.org. The KDE on FreeBSD team have continued to improve the experience of KDE and Qt under FreeBSD. The latest round of improvements include: * Qt supports Clang as a compiler The team has also made many releases and upstreamed many fixes and patches. The latest round of releases include: * Qt: 4.7.3 * KDE: 4.6.3; 4.6.4; 4.6.5 * Amarok: 2.4.1 * Digikam (and KIPI-plugins): 1.9.0 Further testing is requested for KDE PIM 4.6.0 and Calligra 2.3.72 before the ports are committed. To test the ports please visit Alberto Villa's call for test and area51. The team is always looking for more testers and porters so please visit us at kde-freebsd@kde.org and our homepage. Open tasks: 1. Testing KDE PIM 4.6.0 __________________________________________________________________ Multibyte Encoding Support in Nvi URL: http://wiki.FreeBSD.org/ZhihaoSoC2011 URL: https://github.com/lichray/nvi2 Contact: Zhihao Yuan nvi-iconv keeps the behaviors and the license of nvi-1.79 in the base system and adopts the multibyte encoding support from nvi-1.8x. Status: * Known memory leaks, bugs are fixed. make buildworld clear, under WARNS=1 (the old one was WARNS=0). * UTF-16 is supported with less hacks. * The 'windowname' option now restores the xterm title through xprop. * The file encoding detection modified from file(1) is finished and considered stable. The detection is always on since nvi-iconv never change the actual encoding, and the detection failbacks to locale. * Pavel Timofeev provided a full Russian translation of the catalog. Thanks to him. * Now nvi-iconv is able to be compiled with widechar only and without iconv (inspired by a user on FreeBSDChina.org). In that case, it only supports your locale. Open tasks: 1. The wide character support in nvi's message (feedback over the last line) system. 2. Collect more testing results and get code review. __________________________________________________________________ OpenAFS port URL: http://openafs.org URL: http://wiki.FreeBSD.org/afs Contact: Benjamin Kaduk Contact: Derrick Brashear AFS is a distributed network filesystem that originated from the Andrew Project at Carnegie-Mellon University. OpenAFS 1.6.0 has released, and is available in the FreeBSD Ports Collection; it is usable under light load, but heavy usage reveals some issues that remain unresolved. The OpenAFS kernel module is now built using the bsd.kmod.mk infrastructure on the git master branch; unfortunately this change required a minor change in the OS-independent Makefiles and could not be merged in time for 1.6.0. Some attention has been given to memory leaks, but only one small leak has been patched so far. There are several known outstanding issues that are being worked on, but detailed bug reports are welcome at port-freebsd@openafs.org. Open tasks: 1. Update VFS locking to allow the use of disk-based client caches as well as memory-based caches. 2. Track down races and deadlocks that may appear under load. 3. Eliminate a moderate memory leak from the kernel module. 4. PAG (Process Authentication Group) support is not functional. __________________________________________________________________ pfSense URL: http://www.pfsense.org/ Contact: Scott Ullrich Contact: Chris Buechler pfSense 2.0 has been released to the world. This brings the past three years of new feature additions, with significant enhancements to almost every portion of the system. The changes and new features are summarized here. This is by far the most widely deployed release we have put out, thanks to the efforts of thousands of members of the community. Open tasks: 1. Work on 2.1 is underway with the biggest changes being IPV6 support and PBI packaged binaries for the package system. __________________________________________________________________ Portmaster URL: http://dougbarton.us/portmaster-proposal.html Contact: Doug Barton Portmaster offers several new features since the last quarterly update; some bug fixes for the package installation code, and various internal optimizations. The most exciting new feature is probably the ability to specify the -r option more than once for the same portmaster run. This greatly increases efficiency when several "branch" and/or "trunk" ports need updates at the same time, especially for package-building systems. Open tasks: 1. Splitting out the fetch code is still "on the list" of work to be done, but it was sidetracked by other priorities in the past months. I hope to complete it in the quarter to come. 2. Another new feature in the works is support for a list of files for portmaster to preserve and restore during upgrades of a port. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 Contact: Thomas Abthorpe Contact: Port Management Team The ports tree slowly moves up closer to the 23,000 mark. The PR count still remains at about 1000. In Q2 we added 4 new committers, but took in 6 commit bits for safe keeping. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * Python update * Boost updates * Gtk3 updates * clang testing * pkgng testing * testing ruby19 * setting the default fortran to lang/gcc46 * setting apache22 as default * setting the default LDFLAGS in CONFIGURE_ENV Work continues to refine the new build master pointyhat-west. An upgrade to -current done in September has proven problematic. We have enlisted ISC and Josh Paetzel to try to determine a fix. In the meantime, the source will be downgraded to RELENG_9. The portsmon instance is being re-homed at Yahoo. Users should not see any changes. The new instance is currently visible at portsmonj.FreeBSD.org but will soon take on the portsmon.FreeBSD.org name. The team would like to express its appreciation to TDC A/S for the loan of the existing machine for several years. Work is underway to create a new QAT instance at NYI/NJ. portmgr also assisted in setting up a sparc64 machine for general develop access at Yahoo. Thanks to on-site work by Sean Bruno and Ben Haga, we once again have access to the powerpc build machine at ISC, and powerpc builds have been restarted. They also helped us get one more i386 machine back online. linimon is working on a set of scripts to more quickly produce pre-configured PXEboot images for package build nodes. The update of __FreeBSD_version in param.h to 1000000 proved very disruptive to the ports tree, triggering lots of bad assumption in code that interpreted it as FreeBSD 1. A great deal of work has gone into identifying the instances of broken code and fixing and upstreaming them. While this is taking place, one recommended workaround is to set your version to 999999. Open tasks: 1. Looking for help getting ports to build with clang. 2. Looking for help fixing ports broken on CURRENT. (List needs updating, too) 3. Looking for help with Tier-2 architectures. (List needs updating, too) 4. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ Contact: Deb Goodkin The Foundation sponsored KyivBSD 2011 which was held in Kiev, Ukraine on September 24. We were represented at Ohio LinuxFest in Columbus, Ohio. And, we approved six travel grants for EuroBSDCon. Stop by and visit us at the FreeBSD booth during LISA '11, December 7-8, in Boston, MA. Three Foundation funded projects were completed during this period: implementing xlocale APIs to enable porting libc++ by David Chisnall, implementing DIFFUSE for FreeBSD by Swinburne University, and adding GEM, KMS, and DRI support for Intel drivers by Konstantin Belousov. We published our semi-annual newsletter. We purchased servers and other hardware for the FreeBSD co-location centers at Sentex and NYI. The work above, as well as many other tasks which we do for the FreeBSD Project, could not be done without donations. Please help us by making a donation or asking your company to make a donation. We would be happy to send marketing literature to you or your company. Find out how to make a donation at our donate page. Find out more up-to-date Foundation news by reading our blog and Facebook page. __________________________________________________________________ The FreeBSD German Documentation Project Status Report URL: https://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling We managed to update the German version of the documentation just in time to get it included in the upcoming 9.0-RELEASE. The website translations were also kept in sync with the ones on FreeBSD.org. We tried to re-activate committers who did not contribute for some time but most of them are currently unable to free up enough time. We hope to gain fresh contributor blood as we are getting occasional reports about bugs and grammar in the German translation. Open tasks: 1. Submit grammar, spelling or other errors you find in the German documents and the website 2. Translate more articles and other open handbook sections (especially the new chapter about the new FreeBSD installer). __________________________________________________________________ The FreeBSD Greek Documentation Project URL: http://www.FreeBSDgr.org URL: http://www.FreeBSD.org/doc/el/books/handbook Contact: Manolis Kiagias Contact: Giorgos Keramidas After a few rather quiet months, the FreeBSD Greek Documentation Project is back on track, translating and improving the Handbook, FAQ and FreeBSD articles. The new bsdinstall chapter has been translated and is now present in the Handbook. Our experimental Handbook builds are also available at the project's hub. Three new status pages have been added: * Merge Status for the en_US tree shows whether the local en_US repo is in sync with the official CVS * Merge Status for the el_GR tree - as above but for the Greek tree * Pending Commits shows newer yet to be committed versions of the Greek docs For more information, please visit http://www.freebsdgr.org. Patches, fixes and contributions are always welcome. Open tasks: 1. Translate the remaining chapters of the Handbook to Greek. 2. Complete the translation of the FreeBSD FAQ. 3. Keep the currently translated docs in sync with the English versions. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki The www/ja and doc/ja_JP.eucJP/books/handbook subtrees have constantly been updated since the last report. www/ja: During this period, many areas of outdated content in the www/ja subtree were updated to the latest versions in the English counterparts. The Japanese version of 8.2R release announcement was added and the upcoming 9.0R announcement will be translated in a timely manner. Handbook: The Japanese "kernelconfig" section finally caught up with the original English version. The next targets are "cutting-edge" and new installer section. Open tasks: 1. Further translation work for outdated documents in both doc/ja_JP.eucJP and www/ja. __________________________________________________________________ The FreeBSD Release Engineering Team URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team has been coordinating the upcoming FreeBSD 9.0-RELEASE. Thanks to work done by many of the developers. The release, though delayed, is taking the shape nicely. We have reached the stage of doing the second Release Candidate. At this time we expect to have one more Release Candidate, to be followed by the final release itself. __________________________________________________________________ The new CARP URL: http://people.FreeBSD.org/~glebius/newcarp/ Contact: Gleb Smirnoff I am now working on significant rewrite of CARP in FreeBSD. The reason for this work is that the CARP protocol actually does not bring a new interface, but is a property of interface address. Rewriting it in this way helps to remove several hacks from incoming packet processing, simplifies some code, makes CARP addresses more sane from the viewpoint of routing daemons such as quagga/zebra and closes many CARP-related PRs in GNATS. It also brings support for a single redundant address on the subnet, the thing that is called "carpdev feature" in OpenBSD, long awaited in FreeBSD. For this moment I have a patch against head/ that compiles and works in my test environment that I am going to deploy soon on some of servers under my control. The patch has been reviewed by Bjoern Zeeb (bz@). Open tasks: 1. More testing requested! 2. Implement arpbalance and ipbalance features. This requires a next step of rewriting, probably borrowing some ideas from OpenBSD. 3. Update documentation. __________________________________________________________________ Tool for providing FreeBSD VM Images URL: https://github.com/yerenkow/freebsd-vm-image Contact: Alexander Yerenkow A set of scripts to make building FreeBSD VM images easy. Providing a way to make regular build images of the latest version from SVN. Images currently can be copied with `dd` to USB flash (for testing on real hardware) and VirtualBox (.vdi). Open tasks: 1. Build images with ports-set from main port-tree 2. Build images with ports-set from main port-tree plus overrides form area51 (like experimental images) 3. Build images with special development branches included (like for testing drivers) __________________________________________________________________ VM layer for allocations larger than a page Contact: Alan Cox Contact: Davide Italiano The aim of this project is to create a new layer that sits between UMA and the virtual memory system managing chunks of kernel virtual memory on the order of 2 to 4 MB in size. At the end of the work, UMA page_alloc() would no longer call directly into the VM system. It would instead call into this new layer. Thus, uma_large_malloc() and uma_large_free() would no longer be immediately allocating and deallocating kernel virtual memory. This results in a gain in terms of performances (there is a relatively high cost in the approach adopted until now), and also in terms of reduction of fragmentation (the VM system uses a first-fit policy of allocation so there is room for improvements). __________________________________________________________________ ZFSguru URL: http://zfsguru.com URL: http://zfsguru.com Contact: Jason Edwards ZFSguru is a newly designed Network Attached Storage operating system, much like FreeNAS. The difference is that ZFSguru focuses heavily on ZFS and user friendly operation, and uses a full FreeBSD distribution with no elements stripped down. This allows people new to FreeBSD and UNIX in general to access the power of ZFS, while still allowing more advanced users to tweak their NAS with additional functionality and use it as a normal FreeBSD distribution. Started a little over a year ago, the ZFSguru project is making good progress. It should already be one of the most user friendly distributions focused on ZFS, and sports some very unique features. The advanced ZFS benchmarking and convenient Root-on-ZFS installation are good examples. Priority is given to finishing the missing core functionality, and extending the number of available service addons which currently are limited to iSCSI-target and VirtualBox extensions. Open tasks: 1. Finish ZFS and network related functionality in the web-interface. 2. Introduce new service addons, adding optional functionality to ZFSguru. 3. Extend the documentation. __________________________________________________________________ ZRouter.org project -- a FreeBSD-based firmware for embedded devices URL: http://zrouter.org URL: http://lists.zrouter.org URL: http://zrouter.org/hg/zrouter/ URL: http://zrouter.org/hg/FreeBSD/head/ Contact: Aleksandr Rybalko ZRouter.org is a young project that aims to produce FreeBSD-based firmware for small boxes such as SOHO router, APs, etc. At the present time ZRouter.org is able to build working firmware for: * D-Link DAP-1350 * D-Link DIR-320 * D-Link DIR-320-NRU * D-Link DIR-330 * D-Link DIR-615-E4 * D-Link DIR-620 * D-Link DIR-632 * D-Link DSA-3110-A1 * D-Link DSR-1000N * NorthQ NQ-900 * TPLink TL-WR941ND-v3_2 * Ubiquiti RSPRO Currently we are working on most parts of the core system but we are also in the planning phase for implementing a simple web-based GUI which we hope will have taken form before the next FreeBSD status report. We still have many items not done, so devices in that list cannot be called "Production Ready" yet. But we work on that. It is easy to add new devices, because we have separate definition of board and SoC(System on Chip), so if you have "Asus WL-500g Premium v2" for example, you can copy D-Link/DIR-320 directory and tweak to work for your device. We already have basic support for: * Broadcom BCM5354 * Broadcom BCM5836 * Ralink RT3052F * Ralink RT3050F * Ralink RT5350F * Atheros AR7161 * Atheros AR7242 * Atheros AR7241 * Atheros AR7240 * Atheros AR9132 * Intel ixp435 * Cavium CN5010 If you have ability and time, please join us at http://zrouter.org (Redmine iface and mailing lists) Open tasks: 1. Device drivers 2. Web UI 3. Control scripts 4. Watchdog 5. etc. __________________________________________________________________ (c) 1995-2011 The FreeBSD Project. All rights reserved. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 11:36:20 2011 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 835B9106566C; Tue, 8 Nov 2011 11:36:20 +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 3EC9E8FC19; Tue, 8 Nov 2011 11:36:20 +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 <1RNjyV-0007tZ-5n>; Tue, 08 Nov 2011 12:36:19 +0100 Received: from e178022054.adsl.alicedsl.de ([85.178.22.54] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RNjyV-0004o8-1O>; Tue, 08 Nov 2011 12:36:19 +0100 Message-ID: <4EB9142D.3090705@zedat.fu-berlin.de> Date: Tue, 08 Nov 2011 12:36:13 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111105 Thunderbird/7.0.1 MIME-Version: 1.0 To: Current FreeBSD , freebsd-questions@freebsd.org X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC0A4B5BCC971857FD24C6E8" X-Originating-IP: 85.178.22.54 Cc: Subject: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 11:36:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC0A4B5BCC971857FD24C6E8 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Sorry for the boring question, but is the default configuration file /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration file for the kernel while building the kernel? I looked for include statements in GENERIC, but didn't find one. I use custom kernel config files and adapt most changes from the NOTES files in the sources tree. With the today's update of README in /sys/amd64/conf I realised some important changes, so this triggered my question. I simply made an additional "include" in the custom config file, but if this isn't necessary, I'll delete it again. And I'm interested in how the kernel is built from. It is a very convenient way to type simply "make kerne" in /usr/src/, but it vanishes to much of the complexity and understanding how the system builds and could cause problems. Thanks for your patience and tahnks in advance, Regards, Oliver --------------enigAC0A4B5BCC971857FD24C6E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOuRQyAAoJEOgBcD7A/5N8N98IAKtzU0oNSakeny3v7T6iB2V8 vePFG0WvEMXSbOg2A69g87WDhBnJANuaN6wlZcRvnfgU7zz+lsie7/y+HceIQ6BU 1UWzQ+CG/gC/hmV6eEdRta+H8TorfSbGGuombWMmRU7u0ysC1IvbBjWCzqIALtJG cLzMQ5ArKqmXp1KezVhCYbAWV2MBf2gI9OO/T4PeGEq29eVnGF1kzEWTK3SZLcN3 Q2IYjKVT0AE0W/kvLx+agqqrmDW1V52qFH+QD38DGU36WZvpaLaWvHu2Scou6hPI tgyugL0DI9pPDLw9i7dst5GfmASM6toPbVXnROxBIDyThXNn8Y2mzYbKfzacYY0= =IV2v -----END PGP SIGNATURE----- --------------enigAC0A4B5BCC971857FD24C6E8-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 12:13:27 2011 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 17F2D106564A; Tue, 8 Nov 2011 12:13:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF168FC16; Tue, 8 Nov 2011 12:13:25 +0000 (UTC) Received: by wwp14 with SMTP id 14so558991wwp.31 for ; Tue, 08 Nov 2011 04:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bVInmB15V5d/S/QFTdomLYJ4cUCoE4bV+Mv6bfmm850=; b=eqgwxZB/x6SLQTQynygVL0H+lCvlvTQlgrKlzSUZaoYVOY+/OFtrlGQFQwALYJrkYI RZfVmVMr5K10U3AnMRnkVlJQpXNRtOKdw4BEHC1w8SOdIBM7U5X0Jr5+fBEc7jftdv4T h6zSPBbIpem6i7kjvu+YiXf34aiK9a050HFTs= MIME-Version: 1.0 Received: by 10.227.198.140 with SMTP id eo12mr32596432wbb.20.1320754405096; Tue, 08 Nov 2011 04:13:25 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Tue, 8 Nov 2011 04:13:25 -0800 (PST) In-Reply-To: <201111081018.pA8AI7ha027020@svn.freebsd.org> References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Tue, 8 Nov 2011 13:13:25 +0100 X-Google-Sender-Auth: AeKyKV7w0IkfNv45encLOKw1atM Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf 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, 08 Nov 2011 12:13:27 -0000 2011/11/8 Attilio Rao : > Author: attilio > Date: Tue Nov =C2=A08 10:18:07 2011 > New Revision: 227333 > URL: http://svn.freebsd.org/changeset/base/227333 > > Log: > =C2=A0Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default = on > =C2=A0all the architectures. > =C2=A0The option allows to mount non-MPSAFE filesystem. Without it, the > =C2=A0kernel will refuse to mount a non-MPSAFE filesytem. > > =C2=A0This patch is part of the effort of killing non-MPSAFE filesystems > =C2=A0from the tree. This is just a gentle reminder in order to point you further to the "official" page: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS and encourage once again people in adopting a dying FS if it really matters to them. So far, unfortunately, I didn't see a lot of activity in this area but I hope that this would change soon. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 13:13:11 2011 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 EFFDB106566C; Tue, 8 Nov 2011 13:13:11 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 79C6B8FC1B; Tue, 8 Nov 2011 13:13:10 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BA78E4003A; Tue, 8 Nov 2011 14:13:08 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id AFDCB40039; Tue, 8 Nov 2011 14:13:08 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 6FCD540038; Tue, 8 Nov 2011 14:13:08 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 20CFA119C08; Tue, 8 Nov 2011 14:13:08 +0100 (CET) Received: from tifa.daemonic.se (b-76-233.eduroam.liu.se [130.236.76.233]) by mail.daemonic.se (Postfix) with ESMTPSA id C7DF612B0A1; Tue, 8 Nov 2011 14:13:07 +0100 (CET) Received: from tifa.daemonic.se (localhost [127.0.0.1]) by tifa.daemonic.se (Postfix) with ESMTP id B03071D; Tue, 8 Nov 2011 14:13:05 +0100 (CET) Message-ID: <4EB92ADA.6080309@daemonic.se> Date: Tue, 08 Nov 2011 14:12:58 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: "O. Hartmann" References: <4EB9142D.3090705@zedat.fu-berlin.de> In-Reply-To: <4EB9142D.3090705@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Tue, 08 Nov 2011 13:20:04 +0000 Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 13:13:12 -0000 On 11/08/11 12:36, O. Hartmann wrote: > Sorry for the boring question, but is the default configuration file > /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration > file for the kernel while building the kernel? > > I looked for include statements in GENERIC, but didn't find one. I use > custom kernel config files and adapt most changes from the NOTES files > in the sources tree. > > With the today's update of README in /sys/amd64/conf I realised some > important changes, so this triggered my question. > > I simply made an additional "include" in the custom config file, but if > this isn't necessary, I'll delete it again. And I'm interested in how > the kernel is built from. It is a very convenient way to type simply > "make kerne" in /usr/src/, but it vanishes to much of the complexity and > understanding how the system builds and could cause problems. > > Thanks for your patience and tahnks in advance, > > Regards, > Oliver From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the "include" statement. It was first added 6 years ago, on October 27 2005. Regards! -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 13:27:10 2011 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 71910106566C; Tue, 8 Nov 2011 13:27:10 +0000 (UTC) (envelope-from ohartman@mail.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 2F2CB8FC17; Tue, 8 Nov 2011 13:27:09 +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 <1RNlhl-0006XN-7I>; Tue, 08 Nov 2011 14:27:09 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RNlhl-0005i0-5C>; Tue, 08 Nov 2011 14:27:09 +0100 Message-ID: <4EB92E2C.2010402@mail.zedat.fu-berlin.de> Date: Tue, 08 Nov 2011 14:27:08 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Niclas Zeising References: <4EB9142D.3090705@zedat.fu-berlin.de> <4EB92ADA.6080309@daemonic.se> In-Reply-To: <4EB92ADA.6080309@daemonic.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Tue, 08 Nov 2011 13:33:01 +0000 Cc: Current FreeBSD , "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 13:27:10 -0000 Am 11/08/11 14:12, schrieb Niclas Zeising: > On 11/08/11 12:36, O. Hartmann wrote: >> Sorry for the boring question, but is the default configuration file >> /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration >> file for the kernel while building the kernel? >> >> I looked for include statements in GENERIC, but didn't find one. I use >> custom kernel config files and adapt most changes from the NOTES files >> in the sources tree. >> >> With the today's update of README in /sys/amd64/conf I realised some >> important changes, so this triggered my question. >> >> I simply made an additional "include" in the custom config file, but if >> this isn't necessary, I'll delete it again. And I'm interested in how >> the kernel is built from. It is a very convenient way to type simply >> "make kerne" in /usr/src/, but it vanishes to much of the complexity and >> understanding how the system builds and could cause problems. >> >> Thanks for your patience and tahnks in advance, >> >> Regards, >> Oliver > > From my understanding of things, the DEFAULTS kernel configuration file > is automatically included into the build by config(8). There is no need > to include it into the generic using the "include" statement. It was > first added 6 years ago, on October 27 2005. > Regards! Thank you very much. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 13:57:11 2011 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 6967F1065670 for ; Tue, 8 Nov 2011 13:57:11 +0000 (UTC) (envelope-from chuck@thesouthernlibertarian.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 2F0E58FC17 for ; Tue, 8 Nov 2011 13:57:10 +0000 (UTC) Received: by ywt32 with SMTP id 32so796038ywt.13 for ; Tue, 08 Nov 2011 05:57:10 -0800 (PST) Received: by 10.236.191.73 with SMTP id f49mr26168886yhn.50.1320759151617; Tue, 08 Nov 2011 05:32:31 -0800 (PST) Received: from funbeast.localnet (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id q57sm2179492yhi.22.2011.11.08.05.32.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 05:32:30 -0800 (PST) From: Chuck Burns To: freebsd-current@freebsd.org Date: Tue, 08 Nov 2011 07:31:49 -0600 Message-ID: <30719078.XD2KNDdpQA@funbeast> User-Agent: KMail/4.7.3 (Linux/3.1.0-gentoo; KDE/4.7.3; x86_64; ; ) In-Reply-To: <4EB92ADA.6080309@daemonic.se> References: <4EB9142D.3090705@zedat.fu-berlin.de> <4EB92ADA.6080309@daemonic.se> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Tue, 08 Nov 2011 14:10:57 +0000 Subject: Re: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 13:57:11 -0000 On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: > From my understanding of things, the DEFAULTS kernel configuration file > is automatically included into the build by config(8). There is no need > to include it into the generic using the "include" statement. It was > first added 6 years ago, on October 27 2005. > Regards! Not sure if you already know this, or not but another thing to keep in mind, if a module is not mentioned, or is commented out, then it will still be built, just not included into the monolithic kernel. If you were already aware of this, then my apologies. Chuck From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 15:30:02 2011 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 3B1361065674 for ; Tue, 8 Nov 2011 15:30:02 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B8EED8FC19 for ; Tue, 8 Nov 2011 15:30:01 +0000 (UTC) Received: by wyg36 with SMTP id 36so833262wyg.13 for ; Tue, 08 Nov 2011 07:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pLNZILDZfcMEZQJcv3GYaatKtRv1kw8PFWlQPveplAg=; b=i2CCzO7AYdPErOXDPp++Dx5U399nsZ4xzH3asvGtkoJ29mNta3hKFkphIIwaP23+1+ p2B9OxbgbEyuYZLn08wjztKDrXIiQts0HcLzI9UE9mp7+iG5H67DGzVkg5KTaaIJMBYu l5plXedxNpfisZ+yqSVbqih0P9PiGcynNhnjM= MIME-Version: 1.0 Received: by 10.180.95.134 with SMTP id dk6mr12545021wib.59.1320766200838; Tue, 08 Nov 2011 07:30:00 -0800 (PST) Received: by 10.180.8.34 with HTTP; Tue, 8 Nov 2011 07:30:00 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 10:30:00 -0500 Message-ID: From: Ryan Stone To: Paul Ambrose Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: [PATCH] Fix types of arguments to dtrace syscall return probes 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, 08 Nov 2011 15:30:02 -0000 On Mon, Nov 7, 2011 at 9:16 AM, Paul Ambrose wrote: > diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c > index bdff96e..2737860 100644 > --- a/sys/kern/kern_ctf.c > +++ b/sys/kern/kern_ctf.c > @@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc) > =A0 =A0 =A0 =A0 * ctfcnt to -1. See below. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0if (ef->ctfcnt < 0) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EFTYPE); > > =A0 =A0 =A0 =A0/* Now check if we've already loaded the CTF data.. */ > =A0 =A0 =A0 =A0if (ef->ctfcnt > 0) { > -------------------------------------------------------------------------= -------------- I have committed this as r227342. Thanks for the fix. > And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you > check it for me? Yes, I can take a look. > =A0kern/160307, I check the /boot/kernel/kernel with ctfdump, and found > the kernel image has right ctf information, do you > have any idea? Offhand, no. I'll try to find some time to look at your PRs. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:07:46 2011 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 C5BA2106564A; Tue, 8 Nov 2011 16:07:46 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id 699F48FC1F; Tue, 8 Nov 2011 16:07:46 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 45B911198B; Tue, 8 Nov 2011 16:49:07 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id U1n58rCpafDJ; Tue, 8 Nov 2011 16:49:01 +0100 (CET) Received: from [192.168.250.199] (unknown [217.67.16.66]) by mail.vx.sk (Postfix) with ESMTPSA id D8AD21197A; Tue, 8 Nov 2011 16:49:01 +0100 (CET) Message-ID: <4EB94F6D.3020100@FreeBSD.org> Date: Tue, 08 Nov 2011 16:49:01 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jamie Gritton References: <4E316E19.9040309@FreeBSD.org> <4E318D75.608@FreeBSD.org> <4E31A3CD.60500@FreeBSD.org> <4E31AEC6.8080106@FreeBSD.org> <4E331DC1.5000108@FreeBSD.org> <4E348673.6080406@FreeBSD.org> In-Reply-To: <4E348673.6080406@FreeBSD.org> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features) 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, 08 Nov 2011 16:07:46 -0000 I have improved the jail etc script significantly (in addition to ZFS support and other improvements). - you can now set a jail_name="" parameter to set the name for your jail - the jails are still searched by "name", so you cannot manage the jail with the script if "name" in /etc/rc.conf changes while running. - the "status" subcommand now also shows the number of running processes, this way you can identify an empty jail - there are also two new subcommands - "create" and "remove", intended for persistent jail operation - if a jail is set to persistent, you can do the following sequence: create start stop remove. - non-persistent jails may also be created (won't be started) but will be removed on a "stop" http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch On 31. 7. 2011 0:32, Jamie Gritton wrote: > Yes, that looks good. It keeps what I'd call expected behavior for > persist (at least on the startup side). > > - Jamie > > > On 07/29/11 14:53, Martin Matuska wrote: >> So what do you think about this updated patch (attached)? >> Here we leave everything possible for jail_example_params. >> Btw. you can also set jid=xxx in params to have a "static" jail id for >> this jail. >> >> Also stopping a persistent jail doesn't delete it (but you cannot start >> it again). >> >> Dňa 28. 7. 2011 20:47, Jamie Gritton wrote / napĂ­sal(a): >>> Yes, it was intentional to move away from the global sysctls and to >>> the per-jail parameters instead. It makes more sense once config >>> files come into play, which can do a better job of providing global >>> defaults as well as per-jail parameters. >>> >>> The connection between ZFS and persist makes sense. So for ZFS-based >>> jail you'd want to set (and then reset) persist. For others, this >>> could be left to the user. The changes to jail(8) for config files >>> also sets persist when creating jails, and then clears it at a later >>> stage unless the user specifies to keep it set. It looks like I might >>> want to add some ZFS support to the new jail(8). >>> >>> I would prefer to keep things simpler regarding create/start and >>> remove/stop, and keep them tied together. >>> >>> - Jamie >>> >>> >>> On 07/28/11 12:00, Martin Matuska wrote: >>>> If you start jail(8) witth "-c" (the new "param" way,) the values >>>> of the >>>> actual security.jail. variables are not initialized inside the jail, >>>> default values are used instead. I don't know if this is intentional, >>>> but probably yes. Default enforce_statfs=2, allow.mount=0. >>>> As of me we can leave everything for ${_params}, but then ${_zfs} >>>> makes >>>> sense only if enforce_statfs<2 and allow.mount=1. >>>> >>>> Regarding zfs, if you want to operate zfs from the very start of a >>>> jail >>>> (and e.g. make use of /etc/rc.d/zfs which has jail support), you >>>> have to >>>> pair datasets with an existing jail. In simple words, you have to >>>> create >>>> a process-less jail (persist=1), attach zfs datasets and then run the >>>> command. The persist option can be made optional - but we always start >>>> with persist=1, then we can set (or not) persist=0 depending on user >>>> setting. >>>> >>>> The question that opens, should we remove a persisting jail on "stop"? >>>> Or should we support new commands "create" and "remove" in addition to >>>> "start" and "stop"? Create would just make a processless jail, remove >>>> would wipe out a jail and start/stop would just deal with the >>>> processes >>>> (if persist=0 the old way, of course)? >>>> >>>> Cheers, >>>> mm >>>> >>>> Dňa 28. 7. 2011 18:25, Jamie Gritton wrote / napĂ­sal(a): >>>>> Since I missed the 9.0 boat with jail config file capability, >>>>> something >>>>> like this seems necessary; rc.d/jail has long been unable to >>>>> handle the >>>>> full scale of what jail(8) can do. >>>>> >>>>> I gather that setting persist is necessary for the ZFS operation. As >>>>> long as we're making the parameter setting more generic from rc, we >>>>> should handle the case where persist is specified in ${_params}, and >>>>> not >>>>> always set/reset it around the jail creation unless ZFS is used. >>>>> >>>>> Also, why the specific inclusion of the security-related parameters? >>>>> They could just be folded into ${_params}, and if left unspecified >>>>> then >>>>> jail(8) should by default do the right thing. >>>>> >>>>> - Jamie >>>>> >>>>> >>>>> On 07/28/11 08:11, Martin Matuska wrote: >>>>>> The attached patch allows better fine-tuning of jails started via >>>>>> /etc/rc.d, uses the new jail(8) flags (-c -m), the persist >>>>>> parameter and >>>>>> adds ZFS support. >>>>>> Patch is fully backward compatible. >>>>>> >>>>>> Please review, comment and/or test my attached patch. >>>>>> >>>>>> Cheers, >>>>>> mm >> >> -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:26:44 2011 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 3C67B106564A; Tue, 8 Nov 2011 16:26:44 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [64.34.175.71]) by mx1.freebsd.org (Postfix) with ESMTP id 12C3D8FC19; Tue, 8 Nov 2011 16:26:43 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.4/8.14.4) with ESMTP id pA8GDFiv020051; Tue, 8 Nov 2011 09:13:16 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <4EB95516.7030408@FreeBSD.org> Date: Tue, 08 Nov 2011 09:13:10 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110727 Thunderbird/5.0 MIME-Version: 1.0 To: Martin Matuska References: <4E316E19.9040309@FreeBSD.org> <4E318D75.608@FreeBSD.org> <4E31A3CD.60500@FreeBSD.org> <4E31AEC6.8080106@FreeBSD.org> <4E331DC1.5000108@FreeBSD.org> <4E348673.6080406@FreeBSD.org> <4EB94F6D.3020100@FreeBSD.org> In-Reply-To: <4EB94F6D.3020100@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: Re: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features) 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, 08 Nov 2011 16:26:44 -0000 I've been waiting for 9.0 to get fully released before I started in with the new conf-based jail(8). While this patch has a bunch of good stuff, some of it goes at cross purposes with the new jail program. I haven't worked at all on the rc script part of things, so I think I'd want to use a lot of this, but I want to make it all fit together. So how about sitting on it for a while longer until it can be part of a unified effort? - Jamie On 11/08/11 08:49, Martin Matuska wrote: > I have improved the jail etc script significantly (in addition to ZFS > support and other improvements). > > - you can now set a jail_name="" parameter to set the name for your jail > - the jails are still searched by "name", so you cannot manage the jail > with the script if "name" in /etc/rc.conf changes while running. > - the "status" subcommand now also shows the number of running > processes, this way you can identify an empty jail > - there are also two new subcommands - "create" and "remove", intended > for persistent jail operation > - if a jail is set to persistent, you can do the following sequence: > create start stop remove. > - non-persistent jails may also be created (won't be started) but will > be removed on a "stop" > > http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch > http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch > > On 31. 7. 2011 0:32, Jamie Gritton wrote: >> Yes, that looks good. It keeps what I'd call expected behavior for >> persist (at least on the startup side). >> >> - Jamie >> >> >> On 07/29/11 14:53, Martin Matuska wrote: >>> So what do you think about this updated patch (attached)? >>> Here we leave everything possible for jail_example_params. >>> Btw. you can also set jid=xxx in params to have a "static" jail id for >>> this jail. >>> >>> Also stopping a persistent jail doesn't delete it (but you cannot start >>> it again). >>> >>> Dňa 28. 7. 2011 20:47, Jamie Gritton wrote / napĂ­sal(a): >>>> Yes, it was intentional to move away from the global sysctls and to >>>> the per-jail parameters instead. It makes more sense once config >>>> files come into play, which can do a better job of providing global >>>> defaults as well as per-jail parameters. >>>> >>>> The connection between ZFS and persist makes sense. So for ZFS-based >>>> jail you'd want to set (and then reset) persist. For others, this >>>> could be left to the user. The changes to jail(8) for config files >>>> also sets persist when creating jails, and then clears it at a later >>>> stage unless the user specifies to keep it set. It looks like I might >>>> want to add some ZFS support to the new jail(8). >>>> >>>> I would prefer to keep things simpler regarding create/start and >>>> remove/stop, and keep them tied together. >>>> >>>> - Jamie >>>> >>>> >>>> On 07/28/11 12:00, Martin Matuska wrote: >>>>> If you start jail(8) witth "-c" (the new "param" way,) the values >>>>> of the >>>>> actual security.jail. variables are not initialized inside the jail, >>>>> default values are used instead. I don't know if this is intentional, >>>>> but probably yes. Default enforce_statfs=2, allow.mount=0. >>>>> As of me we can leave everything for ${_params}, but then ${_zfs} >>>>> makes >>>>> sense only if enforce_statfs<2 and allow.mount=1. >>>>> >>>>> Regarding zfs, if you want to operate zfs from the very start of a >>>>> jail >>>>> (and e.g. make use of /etc/rc.d/zfs which has jail support), you >>>>> have to >>>>> pair datasets with an existing jail. In simple words, you have to >>>>> create >>>>> a process-less jail (persist=1), attach zfs datasets and then run the >>>>> command. The persist option can be made optional - but we always start >>>>> with persist=1, then we can set (or not) persist=0 depending on user >>>>> setting. >>>>> >>>>> The question that opens, should we remove a persisting jail on "stop"? >>>>> Or should we support new commands "create" and "remove" in addition to >>>>> "start" and "stop"? Create would just make a processless jail, remove >>>>> would wipe out a jail and start/stop would just deal with the >>>>> processes >>>>> (if persist=0 the old way, of course)? >>>>> >>>>> Cheers, >>>>> mm >>>>> >>>>> Dňa 28. 7. 2011 18:25, Jamie Gritton wrote / napĂ­sal(a): >>>>>> Since I missed the 9.0 boat with jail config file capability, >>>>>> something >>>>>> like this seems necessary; rc.d/jail has long been unable to >>>>>> handle the >>>>>> full scale of what jail(8) can do. >>>>>> >>>>>> I gather that setting persist is necessary for the ZFS operation. As >>>>>> long as we're making the parameter setting more generic from rc, we >>>>>> should handle the case where persist is specified in ${_params}, and >>>>>> not >>>>>> always set/reset it around the jail creation unless ZFS is used. >>>>>> >>>>>> Also, why the specific inclusion of the security-related parameters? >>>>>> They could just be folded into ${_params}, and if left unspecified >>>>>> then >>>>>> jail(8) should by default do the right thing. >>>>>> >>>>>> - Jamie >>>>>> >>>>>> >>>>>> On 07/28/11 08:11, Martin Matuska wrote: >>>>>>> The attached patch allows better fine-tuning of jails started via >>>>>>> /etc/rc.d, uses the new jail(8) flags (-c -m), the persist >>>>>>> parameter and >>>>>>> adds ZFS support. >>>>>>> Patch is fully backward compatible. >>>>>>> >>>>>>> Please review, comment and/or test my attached patch. >>>>>>> >>>>>>> Cheers, >>>>>>> mm >>> >>> From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 14:52:29 2011 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 12AD1106566B for ; Tue, 8 Nov 2011 14:52:29 +0000 (UTC) (envelope-from ohartman@mail.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 C435B8FC13 for ; Tue, 8 Nov 2011 14:52:28 +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 <1RNn2J-0002D1-FT>; Tue, 08 Nov 2011 15:52:27 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RNn2J-0004IQ-Dd>; Tue, 08 Nov 2011 15:52:27 +0100 Message-ID: <4EB9422B.1080909@mail.zedat.fu-berlin.de> Date: Tue, 08 Nov 2011 15:52:27 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Chuck Burns References: <4EB9142D.3090705@zedat.fu-berlin.de> <4EB92ADA.6080309@daemonic.se> <30719078.XD2KNDdpQA@funbeast> In-Reply-To: <30719078.XD2KNDdpQA@funbeast> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Tue, 08 Nov 2011 17:01:57 +0000 Cc: freebsd-current@freebsd.org Subject: Re: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 14:52:29 -0000 Am 11/08/11 14:31, schrieb Chuck Burns: > On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: >> From my understanding of things, the DEFAULTS kernel configuration file >> is automatically included into the build by config(8). There is no need >> to include it into the generic using the "include" statement. It was >> first added 6 years ago, on October 27 2005. >> Regards! > > Not sure if you already know this, or not but another thing to keep in mind, > if a module is not mentioned, or is commented out, then it will still be > built, just not included into the monolithic kernel. > > If you were already aware of this, then my apologies. > > Chuck Hello. well, I'm aware of that, but it doesn't matter. As long as I do not use a broken or commented out module, it is all right. I was a little bit surprised having options already set I never set in the usual config file named after the host's name or GENERIC. And for FBSD 10.0/amd64, it has been started to use a VFS-option for loading thread safe filesystems. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 17:56:10 2011 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 EFD89106564A for ; Tue, 8 Nov 2011 17:56:10 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id AAE588FC1A for ; Tue, 8 Nov 2011 17:56:10 +0000 (UTC) Received: by qabj40 with SMTP id j40so808607qab.13 for ; Tue, 08 Nov 2011 09:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rKNbB0l6IuZVQDJYh4KWqO452qJUKLbGoWnL0b5l7a0=; b=XAz0Y21jGMVMosjnLUuUxZVW1+h8mEPhY4MkluN6uLYW0s4/AUTbG4JupJRlLzWBBP vt5ZqbNaleYz8NFi08/efQmMzIGYyoUyt2AHncecBQQ+krUTIHMP7ne/5V/3kbR070ri KcmIz07Fxz7zX5z58eJ9L8PT7+BTgAQAkuyZ0= MIME-Version: 1.0 Received: by 10.229.100.12 with SMTP id w12mr3677233qcn.293.1320773396937; Tue, 08 Nov 2011 09:29:56 -0800 (PST) Received: by 10.229.1.216 with HTTP; Tue, 8 Nov 2011 09:29:56 -0800 (PST) In-Reply-To: <4EB9422B.1080909@mail.zedat.fu-berlin.de> References: <4EB9142D.3090705@zedat.fu-berlin.de> <4EB92ADA.6080309@daemonic.se> <30719078.XD2KNDdpQA@funbeast> <4EB9422B.1080909@mail.zedat.fu-berlin.de> Date: Tue, 8 Nov 2011 18:29:56 +0100 Message-ID: From: Giovanni Trematerra To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Chuck Burns , freebsd-current@freebsd.org Subject: Re: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 17:56:11 -0000 On Tue, Nov 8, 2011 at 3:52 PM, O. Hartmann wrote: > Am 11/08/11 14:31, schrieb Chuck Burns: > > And for FBSD 10.0/amd64, it has been started to use a VFS-option for > loading thread safe filesystems. > That will be removed. see http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS -- Gianni From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 18:05:21 2011 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 677181065670 for ; Tue, 8 Nov 2011 18:05:21 +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 276328FC12 for ; Tue, 8 Nov 2011 18:05:20 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id pA8HXM7h097975; Tue, 8 Nov 2011 10:33:22 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4EB9422B.1080909@mail.zedat.fu-berlin.de> Date: Tue, 8 Nov 2011 10:33:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00E1440E-FFEB-4701-849F-86BBDEEABD31@samsco.org> References: <4EB9142D.3090705@zedat.fu-berlin.de> <4EB92ADA.6080309@daemonic.se> <30719078.XD2KNDdpQA@funbeast> <4EB9422B.1080909@mail.zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Chuck Burns , freebsd-current@freebsd.org Subject: Re: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 18:05:21 -0000 On Nov 8, 2011, at 7:52 AM, O. Hartmann wrote: > Am 11/08/11 14:31, schrieb Chuck Burns: >> On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: >>> =46rom my understanding of things, the DEFAULTS kernel configuration = file >>> is automatically included into the build by config(8). There is no = need >>> to include it into the generic using the "include" statement. It was >>> first added 6 years ago, on October 27 2005. >>> Regards! >>=20 >> Not sure if you already know this, or not but another thing to keep = in mind,=20 >> if a module is not mentioned, or is commented out, then it will still = be=20 >> built, just not included into the monolithic kernel. >>=20 >> If you were already aware of this, then my apologies. >>=20 >> Chuck >=20 >=20 > Hello. >=20 > well, I'm aware of that, but it doesn't matter. As long as I do not = use > a broken or commented out module, it is all right. >=20 > I was a little bit surprised having options already set I never set in > the usual config file named after the host's name or GENERIC. >=20 > And for FBSD 10.0/amd64, it has been started to use a VFS-option for > loading thread safe filesystems. >=20 I've never liked that DEFAULTS is magically invisible. I know that the = intention was to keep users from shooting their feet off by accidentally = excluding it from their configs, but I think it creates more confusion = that it solves. Scott From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 18:49:14 2011 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 39412106566B; Tue, 8 Nov 2011 18:49:14 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 336FB8FC21; Tue, 8 Nov 2011 18:49:12 +0000 (UTC) Received: by wyg36 with SMTP id 36so1129744wyg.13 for ; Tue, 08 Nov 2011 10:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TD0RHFqWfRztgZ/7C/LlINmD/sjFi9ebkzE4YlLtuyY=; b=giK7brY2pWlfbGL7kWbf4zqon7BGBKfaRLBq7nVgd3dD7kKXalOwBDu4IPGDIy2b7n HYV3CqndI5+czXeIaxY7Wx2mQjt+49/nvOzrurvTJkZbS3HKxKLmpZy2HjWndYCaT18c mZ7Qdp0ICQKl9E6vNbeXT7Zr63aamixtOYQ6M= MIME-Version: 1.0 Received: by 10.181.13.165 with SMTP id ez5mr14769497wid.51.1320778151716; Tue, 08 Nov 2011 10:49:11 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 10:49:10 -0800 (PST) Date: Tue, 8 Nov 2011 13:49:10 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 08 Nov 2011 18:49:14 -0000 Hi, On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe wrote: > On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao wrote: >> 2011/11/7 Arnaud Lacombe : >>> Hi, >>> >>> On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov = wrote: >>>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>>> >>>> Below is the KBI patch after vm_page_bits_t merge is done. >>>> Again, I did not spent time converting all in-tree consumers >>>> from the (potentially) loadable modules to the new KPI until it >>>> is agreed upon. >>>> >>>> diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c >>>> index 305c189..7264cd1 100644 >>>> --- a/sys/nfsclient/nfs_bio.c >>>> +++ b/sys/nfsclient/nfs_bio.c >>>> @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) >>>> =A0 =A0 =A0 =A0 * can only occur at the file EOF. >>>> =A0 =A0 =A0 =A0 */ >>>> =A0 =A0 =A0 =A0VM_OBJECT_LOCK(object); >>>> - =A0 =A0 =A0 if (pages[ap->a_reqpage]->valid !=3D 0) { >>>> + =A0 =A0 =A0 if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D 0) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < npages; ++i) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (i !=3D ap->a_reqpag= e) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page= _lock(pages[i]); >>>> @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation fille= d an entire page >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D VM_PAGE_BIT= S_ALL; >>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D = 0, >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, V= M_PAGE_BITS_ALL); >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dir= ty(m) =3D=3D 0, >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages:= page %p is dirty", m)); >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (size > toff) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation fille= d a partial page. >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D 0; >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, 0= ); >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_set_valid(m, 0,= size - toff); >>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D = 0, >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dir= ty(m) =3D=3D 0, >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages:= page %p is dirty", m)); >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>>> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >>>> index 389aea5..2f41e70 100644 >>>> --- a/sys/vm/vm_page.c >>>> +++ b/sys/vm/vm_page.c >>>> @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_dirty(m); >>>> =A0} >>>> >>>> +void >>>> +vm_page_lock_func(vm_page_t m, const char *file, int line) >>>> +{ >>>> + >>>> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >>>> + =A0 =A0 =A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); >>>> +#else >>>> + =A0 =A0 =A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); >>>> +#endif >>>> +} >>>> + >>> Why do you re-implement the wheel ? all the point of these assessors >>> is to hide implementation detail. IMO, you should restrict yourself to >>> the documented API from mutex(9), only. >>> >>> Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but >>> wait LOCK_FILE is either just __FILE__, or NULL, depending on >>> LOCK_DEBUG, but you wouldn't have those function without >>> INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely >>> fracked-up... If you don't want this code in INVARIANTS, but in >>> LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. >>> >>> Btw, let me also question the use of non-inline functions. >> >> My impression is that you don't really understand the patch, thus your >> disrespectful words used here are really unjustified. >> > Well, unfortunately, I wasn't around to comment 10 years ago when this go= t in. > >> I think that kib@ intention is just to get "the most official way" to >> pass down file and line to locking functions from the consumers. >> His patch is "technically right", but I would prefer something >> different (see below). >> > Yes, and that's not an excuse to use the _internal_ implementation > details of mutex(9), and not the exposed API. This is especially true > when applied to someone so eager to follow "standards". > >> LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata >> section. Without INVARIANTS/WITNESS/etc. they will just be NULL and >> not pointing to a lot of datas that won't be used in the opposite >> case. >> > You comment just as if __FILE__ and __LINE__ were mandatory in a debug > interface. This is _not_ true. __FILE__ and __LINE__ are just hideous > for debugging of anything but early alpha code. LOCK_FILE and > LOCK_LINE are a bad answer to a bad interface. Even if you just pass > NULL and 0 as argument, you've got the bloat of passing unused > argument. You might as well just pass a single argument that would do > the exact same job and be _always_ available, eg. the IP of the > caller, or the first return address. KDB magic still let you translate > to something humanly understandable. If the toolchain does not support > the feature on all supported platform, well, fix the toolchain. > To avoid future complaints about the fact that I would be only "talk" without "action", I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug It convert a bunch of debug interface to use the caller instruction pointer, as well as a proof-of-concept teaching printf(9) to convert IP to symbol_name+offset. It translates in a direct saving of about +250kB on i386's GENERIC, just in kernel text size. Even the worst case, ie LOCK_DEBUG =3D=3D 0, translates to a save of +80kB. Please note that this is still WIP code. Comments welcome. - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:10:53 2011 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 A76D1106564A; Tue, 8 Nov 2011 19:10:53 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D95918FC08; Tue, 8 Nov 2011 19:10:52 +0000 (UTC) Received: by faar19 with SMTP id r19so1228989faa.13 for ; Tue, 08 Nov 2011 11:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Rv3ACUddTfZR5KsFsd2pHShjarW+bSMh9rLpx2weshE=; b=vTc440nTiCnEkhFDebmcyaF7KWdE8QHz0kMpvdFlKhcI6QgW1jdi2DHmKx47xFUMJq CmLlNMVHfc9aBtm/qmJlAr/XEkgGixg/kQ5owbWWmp7Wqbdl2hAvLI/zKfxBa7qBJCZL cFW3KMn8NSd/UuYzkGMqQnMNUPrBti21vuB3M= MIME-Version: 1.0 Received: by 10.152.144.73 with SMTP id sk9mr9360767lab.34.1320779451577; Tue, 08 Nov 2011 11:10:51 -0800 (PST) Received: by 10.152.9.10 with HTTP; Tue, 8 Nov 2011 11:10:51 -0800 (PST) In-Reply-To: <201110251555.23066.jhb@freebsd.org> References: <20111024214020.GA60109@neveragain.de> <201110251555.23066.jhb@freebsd.org> Date: Tue, 8 Nov 2011 23:10:51 +0400 Message-ID: From: Pavel Timofeev To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 08 Nov 2011 19:13:38 +0000 Cc: Andriy Gapon , freebsd-current@freebsd.org, Dennis Koegel , Gunnar Schaefer Subject: Re: Fresh installed Freebsd 9 don't boot from hd 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, 08 Nov 2011 19:10:53 -0000 FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK 2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64 RC2 is coming. Nothing changed. 2011/10/25 John Baldwin : > On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote: >> On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote: >> >> > On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote: >> >> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch >> > >> > GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type": >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0v86.ds =3D VTOPSEG(params); >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0v86.esi =3D VTOPOFF(params); >> > >> > Changed this to ¶ms. Also changed sector_size to uint16_t as noted >> > by Andriy. Boots perfectly! (Tested with gcc and clang) >> >> I'd like to test these patches on my Supermicro machine as well. > Unfortunately, I don't know how to go about it, but I'm hopeful to be abl= e to > figure it out with some basic instructions. I'm currently running a fresh= RC1 > install, and I'm able to boot the system if I set the BIOS to IDE mode, r= ather > than AHCI. >> >> Any help would be much appreciated, > > I just committed them to HEAD (226748 along with a cleanup in 226746). = =C2=A0They > should backport to 9. > > -- > John Baldwin > From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:19:05 2011 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 E7047106566B for ; Tue, 8 Nov 2011 19:19:05 +0000 (UTC) (envelope-from skirge84@o2.pl) Received: from tur.go2.pl (tur.go2.pl [193.17.41.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7248A8FC19 for ; Tue, 8 Nov 2011 19:19:05 +0000 (UTC) Received: from moh2-ve2.go2.pl (moh2-ve2.go2.pl [193.17.41.200]) by tur.go2.pl (Postfix) with ESMTP id 52A7623148D for ; Tue, 8 Nov 2011 20:02:20 +0100 (CET) Received: from moh2-ve2.go2.pl (unknown [10.0.0.200]) by moh2-ve2.go2.pl (Postfix) with ESMTP id C7197DA4007 for ; Tue, 8 Nov 2011 20:02:15 +0100 (CET) Received: from unknown (unknown [10.0.0.142]) by moh2-ve2.go2.pl (Postfix) with SMTP for ; Tue, 8 Nov 2011 20:02:14 +0100 (CET) Received: from mail-bw0-f54.google.com [209.85.214.54] by poczta.o2.pl with ESMTP id jCCbtY; Tue, 08 Nov 2011 20:02:14 +0100 Received: by bkbzs8 with SMTP id zs8so990983bkb.13 for ; Tue, 08 Nov 2011 11:02:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.174.106 with SMTP id br10mr10339535obc.40.1320778933149; Tue, 08 Nov 2011 11:02:13 -0800 (PST) Received: by 10.182.111.4 with HTTP; Tue, 8 Nov 2011 11:02:13 -0800 (PST) Date: Tue, 8 Nov 2011 20:02:13 +0100 Message-ID: From: Sebastian Chmielewski To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org X-O2-Trust: 2, 66 X-O2-SPF: neutral X-Mailman-Approved-At: Tue, 08 Nov 2011 19:31:25 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ZFS: invalid zap_type=134218628 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, 08 Nov 2011 19:19:06 -0000 I've got following error after upgrading my 9.0-RC1 to RC2 using source and got this error at loader prompt: ZFS: invalid zap_type=134218628 when I tried zfsboottest from 9.0-STABLE it failed ./zfsboottest /boot/kernel/kernel /dev/ada0p4 returns pool status correctly but ends with the same message zfsboottest from 10.0-CURRENT returns pool status, zfsboottest.sh zroot printed OK message at the end (very useful zfsboottest.sh wasn't yet merged from current to stable). I've installed gptzfsboot, zfsloader, loader from -CURRENT and it boots fine. I'm running ZFS on GPT partitions, zfs version 28 with dedup on. File system can be successfully mount using FreeBSD memstick. I think that patches for boot should be merged to 9.0-RELEASE otherwise users may have the same problems I had. best regards, From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:39:46 2011 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 2712A106566B; Tue, 8 Nov 2011 19:39:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F01F28FC13; Tue, 8 Nov 2011 19:39:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A1FCB46B09; Tue, 8 Nov 2011 14:39:45 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 406DE8A02E; Tue, 8 Nov 2011 14:39:45 -0500 (EST) From: John Baldwin To: Pavel Timofeev Date: Tue, 8 Nov 2011 14:31:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201110251555.23066.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111081431.45910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 08 Nov 2011 14:39:45 -0500 (EST) Cc: Andriy Gapon , freebsd-current@freebsd.org, Dennis Koegel , Gunnar Schaefer Subject: Re: Fresh installed Freebsd 9 don't boot from hd 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, 08 Nov 2011 19:39:46 -0000 On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote: > FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK > 2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64 > RC2 is coming. Nothing changed. Sorry, haven't been able to merge them to 9 yet. > 2011/10/25 John Baldwin : > > On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote: > >> On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote: > >> > >> > On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote: > >> >> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch > >> > > >> > GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type": > >> > > >> > v86.ds = VTOPSEG(params); > >> > v86.esi = VTOPOFF(params); > >> > > >> > Changed this to ¶ms. Also changed sector_size to uint16_t as noted > >> > by Andriy. Boots perfectly! (Tested with gcc and clang) > >> > >> I'd like to test these patches on my Supermicro machine as well. > > Unfortunately, I don't know how to go about it, but I'm hopeful to be able to > > figure it out with some basic instructions. I'm currently running a fresh RC1 > > install, and I'm able to boot the system if I set the BIOS to IDE mode, rather > > than AHCI. > >> > >> Any help would be much appreciated, > > > > I just committed them to HEAD (226748 along with a cleanup in 226746). They > > should backport to 9. > > > > -- > > John Baldwin > > > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:50:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 914CE1065670 for ; Tue, 8 Nov 2011 19:50:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 50D971535CE; Tue, 8 Nov 2011 19:50:24 +0000 (UTC) Message-ID: <4EB987FF.1040008@FreeBSD.org> Date: Tue, 08 Nov 2011 11:50:23 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Scott Long References: <4EB9142D.3090705@zedat.fu-berlin.de> <4EB92ADA.6080309@daemonic.se> <30719078.XD2KNDdpQA@funbeast> <4EB9422B.1080909@mail.zedat.fu-berlin.de> <00E1440E-FFEB-4701-849F-86BBDEEABD31@samsco.org> In-Reply-To: <00E1440E-FFEB-4701-849F-86BBDEEABD31@samsco.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Chuck Burns , "O. Hartmann" , freebsd-current@freebsd.org Subject: Re: /sys/amd64/conf/DEFAULTS 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, 08 Nov 2011 19:50:26 -0000 On 11/08/2011 09:33, Scott Long wrote: > > On Nov 8, 2011, at 7:52 AM, O. Hartmann wrote: > >> Am 11/08/11 14:31, schrieb Chuck Burns: >>> On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: >>>> From my understanding of things, the DEFAULTS kernel configuration file >>>> is automatically included into the build by config(8). There is no need >>>> to include it into the generic using the "include" statement. It was >>>> first added 6 years ago, on October 27 2005. >>>> Regards! >>> >>> Not sure if you already know this, or not but another thing to keep in mind, >>> if a module is not mentioned, or is commented out, then it will still be >>> built, just not included into the monolithic kernel. >>> >>> If you were already aware of this, then my apologies. >>> >>> Chuck >> >> >> Hello. >> >> well, I'm aware of that, but it doesn't matter. As long as I do not use >> a broken or commented out module, it is all right. >> >> I was a little bit surprised having options already set I never set in >> the usual config file named after the host's name or GENERIC. >> >> And for FBSD 10.0/amd64, it has been started to use a VFS-option for >> loading thread safe filesystems. >> > > I've never liked that DEFAULTS is magically invisible. I know that the intention was to keep users from shooting their feet off by accidentally excluding it from their configs, but I think it creates more confusion that it solves. +1 on both counts -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:34:39 2011 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 DA43C106564A; Tue, 8 Nov 2011 20:34:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 132858FC0C; Tue, 8 Nov 2011 20:34:38 +0000 (UTC) Received: by wyg36 with SMTP id 36so1273357wyg.13 for ; Tue, 08 Nov 2011 12:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=HvSl1D0NI2lUJf2byqu2fH21DOFUHBQfIZrsUOT9XzQ=; b=psjCxzC2833QaoRIPohJGxPU4NCkNYx74Xnh8X9athSkAMFpqvXaPOHPrHZdxiAGmb 86rvgjASBH5Ja0HtCxMK9sUPCvt44xBSQ1XUVD74itEOWB+7EjcVAKkzD5A4GG1XLWxF 196Qei3QlIUjqXxaZ1aWwKiCGtBj1+UgSyiYY= MIME-Version: 1.0 Received: by 10.216.176.14 with SMTP id a14mr4802990wem.14.1320784477765; Tue, 08 Nov 2011 12:34:37 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Tue, 8 Nov 2011 12:34:37 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 21:34:37 +0100 X-Google-Sender-Auth: 3iU0Kwz1tlINAdfcbNaXL5AftV4 Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 08 Nov 2011 20:34:39 -0000 2011/11/8 Arnaud Lacombe : > Hi, > > On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe wrote= : >> On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao wrote: >>> 2011/11/7 Arnaud Lacombe : >>>> Hi, >>>> >>>> On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov = wrote: >>>>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>>>> >>>>> Below is the KBI patch after vm_page_bits_t merge is done. >>>>> Again, I did not spent time converting all in-tree consumers >>>>> from the (potentially) loadable modules to the new KPI until it >>>>> is agreed upon. >>>>> >>>>> diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c >>>>> index 305c189..7264cd1 100644 >>>>> --- a/sys/nfsclient/nfs_bio.c >>>>> +++ b/sys/nfsclient/nfs_bio.c >>>>> @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * can only occur at the file EOF. >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0VM_OBJECT_LOCK(object); >>>>> - =C2=A0 =C2=A0 =C2=A0 if (pages[ap->a_reqpage]->valid !=3D 0) { >>>>> + =C2=A0 =C2=A0 =C2=A0 if (vm_page_read_valid(pages[ap->a_reqpage]) != =3D 0) { >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; = i < npages; ++i) { >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0if (i !=3D ap->a_reqpage) { >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vm_page_lock(pages[i]); >>>>> @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0/* >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 * Read operation filled an entire page >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 */ >>>>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 m->valid =3D VM_PAGE_BITS_ALL; >>>>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 KASSERT(m->dirty =3D=3D 0, >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 vm_page_write_valid(m, VM_PAGE_BITS_ALL); >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 KASSERT(vm_page_read_dirty(m) =3D=3D 0, >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0("nfs_getpages: page %p is dirty", m)); >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else if (siz= e > toff) { >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0/* >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 * Read operation filled a partial page. >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 */ >>>>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 m->valid =3D 0; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 vm_page_write_valid(m, 0); >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0vm_page_set_valid(m, 0, size - toff); >>>>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 KASSERT(m->dirty =3D=3D 0, >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 KASSERT(vm_page_read_dirty(m) =3D=3D 0, >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0("nfs_getpages: page %p is dirty", m)); >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else { >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0/* >>>>> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >>>>> index 389aea5..2f41e70 100644 >>>>> --- a/sys/vm/vm_page.c >>>>> +++ b/sys/vm/vm_page.c >>>>> @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vm_page_dirty(= m); >>>>> =C2=A0} >>>>> >>>>> +void >>>>> +vm_page_lock_func(vm_page_t m, const char *file, int line) >>>>> +{ >>>>> + >>>>> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >>>>> + =C2=A0 =C2=A0 =C2=A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, l= ine); >>>>> +#else >>>>> + =C2=A0 =C2=A0 =C2=A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); >>>>> +#endif >>>>> +} >>>>> + >>>> Why do you re-implement the wheel ? all the point of these assessors >>>> is to hide implementation detail. IMO, you should restrict yourself to >>>> the documented API from mutex(9), only. >>>> >>>> Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but >>>> wait LOCK_FILE is either just __FILE__, or NULL, depending on >>>> LOCK_DEBUG, but you wouldn't have those function without >>>> INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely >>>> fracked-up... If you don't want this code in INVARIANTS, but in >>>> LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. >>>> >>>> Btw, let me also question the use of non-inline functions. >>> >>> My impression is that you don't really understand the patch, thus your >>> disrespectful words used here are really unjustified. >>> >> Well, unfortunately, I wasn't around to comment 10 years ago when this g= ot in. >> >>> I think that kib@ intention is just to get "the most official way" to >>> pass down file and line to locking functions from the consumers. >>> His patch is "technically right", but I would prefer something >>> different (see below). >>> >> Yes, and that's not an excuse to use the _internal_ implementation >> details of mutex(9), and not the exposed API. This is especially true >> when applied to someone so eager to follow "standards". >> >>> LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata >>> section. Without INVARIANTS/WITNESS/etc. they will just be NULL and >>> not pointing to a lot of datas that won't be used in the opposite >>> case. >>> >> You comment just as if __FILE__ and __LINE__ were mandatory in a debug >> interface. This is _not_ true. __FILE__ and __LINE__ are just hideous >> for debugging of anything but early alpha code. LOCK_FILE and >> LOCK_LINE are a bad answer to a bad interface. Even if you just pass >> NULL and 0 as argument, you've got the bloat of passing unused >> argument. You might as well just pass a single argument that would do >> the exact same job and be _always_ available, eg. the IP of the >> caller, or the first return address. KDB magic still let you translate >> to something humanly understandable. If the toolchain does not support >> the feature on all supported platform, well, fix the toolchain. >> > To avoid future complaints about the fact that I would be only "talk" > without "action", I did implement what I suggested above. As it is > quite a large patch-set, I will not post it directly here, however, it > is available on github: I really think that this is way too dependent by the good health of your tool, thus that is highly fragile. However, you may have more luck by just the core of your kernel changes here, for comment and leave alone all the (ptr -> LOCK_FILE/LOCK_LINE conversion). Said that, I think this logic is too fragile and likely won't be as effective as __FILE__/__LINE__ in many cases. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:40:03 2011 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 7BFA9106564A; Tue, 8 Nov 2011 20:40:03 +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 46EA18FC18; Tue, 8 Nov 2011 20:40:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA8Ke2p5098816; Tue, 8 Nov 2011 15:40:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA8Ke23Z098815; Tue, 8 Nov 2011 20:40:02 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 8 Nov 2011 20:40:02 GMT Message-Id: <201111082040.pA8Ke23Z098815@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: Tue, 08 Nov 2011 20:40:03 -0000 TB --- 2011-11-08 19:39:19 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-08 19:39:19 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-08 19:39:19 - cleaning the object tree TB --- 2011-11-08 19:39:34 - cvsupping the source tree TB --- 2011-11-08 19:39:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-08 19:40:20 - building world TB --- 2011-11-08 19:40:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 19:40:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 19:40:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 19:40:20 - SRCCONF=/dev/null TB --- 2011-11-08 19:40:20 - TARGET=sparc64 TB --- 2011-11-08 19:40:20 - TARGET_ARCH=sparc64 TB --- 2011-11-08 19:40:20 - TZ=UTC TB --- 2011-11-08 19:40:20 - __MAKE_CONF=/dev/null TB --- 2011-11-08 19:40:20 - cd /src TB --- 2011-11-08 19:40:20 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 8 19:40:20 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Nov 8 20:37:28 UTC 2011 TB --- 2011-11-08 20:37:28 - generating LINT kernel config TB --- 2011-11-08 20:37:28 - cd /src/sys/sparc64/conf TB --- 2011-11-08 20:37:28 - /usr/bin/make -B LINT TB --- 2011-11-08 20:37:29 - cd /src/sys/sparc64/conf TB --- 2011-11-08 20:37:29 - /usr/sbin/config -m GENERIC TB --- 2011-11-08 20:37:29 - building GENERIC kernel TB --- 2011-11-08 20:37:29 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 20:37:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 20:37:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 20:37:29 - SRCCONF=/dev/null TB --- 2011-11-08 20:37:29 - TARGET=sparc64 TB --- 2011-11-08 20:37:29 - TARGET_ARCH=sparc64 TB --- 2011-11-08 20:37:29 - TZ=UTC TB --- 2011-11-08 20:37:29 - __MAKE_CONF=/dev/null TB --- 2011-11-08 20:37:29 - cd /src TB --- 2011-11-08 20:37:29 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Nov 8 20:37:29 UTC 2011 >>> 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 -g -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_pci.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1653: error: 'ATH_AGGR_MIN_QDEPTH' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1653: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1653: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1654: error: 'ATH_AGGR_SCHED_LOW' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1655: error: 'ATH_AGGR_SCHED_HIGH' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-08 20:40:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-08 20:40:01 - ERROR: failed to build GENERIC kernel TB --- 2011-11-08 20:40:01 - 2883.29 user 681.07 system 3642.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:47:20 2011 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 4B70C1065771 for ; Tue, 8 Nov 2011 20:47:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 93CB98FC1A for ; Tue, 8 Nov 2011 20:47:19 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA28181; Tue, 08 Nov 2011 22:47:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RNsZg-0008Lm-Os; Tue, 08 Nov 2011 22:47:16 +0200 Message-ID: <4EB99553.5010005@FreeBSD.org> Date: Tue, 08 Nov 2011 22:47:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jeff Roberson References: <4E720CB6.3070103@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: couple of sched_ule issues 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, 08 Nov 2011 20:47:20 -0000 on 03/11/2011 22:17 Jeff Roberson said the following: > On Thu, 15 Sep 2011, Andriy Gapon wrote: > >> >> This is more of a "just for the record" email. >> I think I've already stated the following observations, but I suspect that they >> drowned in the noise of a thread in which I mentioned them. >> >> 1. Incorrect topology is built for single-package SMP systems. >> That topology has two levels ("shared nothing" and "shared package") with exactly >> the same CPU sets. That doesn't work well with the rebalancing algorithm which >> assumes that each level is a proper/strict subset of its parent. >> >> 2. CPU load comparison algorithms are biased towards lower logical CPU IDs. >> With all other things being equal the algorithms will always pick a CPU with a >> lower ID. This creates certain load asymmetry and predictable patterns in load >> distribution. > > If all other things truly are equal why does selecting a lower cpu number matter? Honestly, I am not sure. This bias could definitely produce an "inequality" from the point of view of how many threads each CPU gets. But I can not say if there could be any "inequality" in how much CPU time each thread gets. But I don't rule out that that might be possible... Please also see this post of mine: http://thread.gmane.org/gmane.os.freebsd.current/133763/focus=134192 >> Another observation. >> It seems that ULE makes a decision about thread-to-CPU affinity at the time >> when a >> thread gets switched out. This looks logical from the implementation point of >> view. But it doesn't seem logical from a general point of view - when the thread >> will be becoming running again its affinity profile may become completely >> different. I think that it would depend on how much a thread actually spends not >> running. > > The decision is made at sched_add() time. sched_pickcpu() does the work and > selects the run-queue we will be added to. We consider the CPU that the thread > was last running on but the decision is made at the time that a run queue must > be selected. Ah, yes. But, OTOH, it doesn't look like sched_add would be called for a CPU-bound thread (no voluntary sleeps) ? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:56:04 2011 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 1181E106566B; Tue, 8 Nov 2011 20:56:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 257318FC12; Tue, 8 Nov 2011 20:56:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA28280; Tue, 08 Nov 2011 22:56:00 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RNsi8-0008M6-Jf; Tue, 08 Nov 2011 22:56:00 +0200 Message-ID: <4EB9975F.4090601@FreeBSD.org> Date: Tue, 08 Nov 2011 22:55:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@FreeBSD.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 08 Nov 2011 20:56:04 -0000 [cc list trimmed] on 08/11/2011 22:34 Attilio Rao said the following: > 2011/11/8 Arnaud Lacombe : >> To avoid future complaints about the fact that I would be only "talk" >> without "action", I did implement what I suggested above. As it is >> quite a large patch-set, I will not post it directly here, however, it >> is available on github: > > I really think that this is way too dependent by the good health of > your tool, thus that is highly fragile. > > However, you may have more luck by just the core of your kernel > changes here, for comment and leave alone all the (ptr -> > LOCK_FILE/LOCK_LINE conversion). > > Said that, I think this logic is too fragile and likely won't be as > effective as __FILE__/__LINE__ in many cases. I agree. If we were able to somehow automatically, magically, easily and correctly determine an instruction pointer of a caller, then it would make sense to ditch explicit passing of __FILE__/__LINE__ arguments in favor of doing instruction pointer decoding. But if we are just replacing explicit passing of (well-known) macros __FILE__/__LINE__ with explicit passing of THIS_IP, then I don't see a point. Apologies if I missed the rationale for this change. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:59:01 2011 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 49176106566C for ; Tue, 8 Nov 2011 20:59:01 +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 039218FC08 for ; Tue, 8 Nov 2011 20:59:00 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 1061928428; Tue, 8 Nov 2011 21:59:00 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id DE1F628424; Tue, 8 Nov 2011 21:58:58 +0100 (CET) Message-ID: <4EB99812.3010107@quip.cz> Date: Tue, 08 Nov 2011 21:58:58 +0100 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: Martin Matuska References: <4E316E19.9040309@FreeBSD.org> <4E318D75.608@FreeBSD.org> <4E31A3CD.60500@FreeBSD.org> <4E31AEC6.8080106@FreeBSD.org> <4E331DC1.5000108@FreeBSD.org> <4E348673.6080406@FreeBSD.org> <4EB94F6D.3020100@FreeBSD.org> In-Reply-To: <4EB94F6D.3020100@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Jamie Gritton Subject: Re: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features) 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, 08 Nov 2011 20:59:01 -0000 Martin Matuska wrote: > I have improved the jail etc script significantly (in addition to ZFS > support and other improvements). > > - you can now set a jail_name="" parameter to set the name for your jail > - the jails are still searched by "name", so you cannot manage the jail > with the script if "name" in /etc/rc.conf changes while running. > - the "status" subcommand now also shows the number of running > processes, this way you can identify an empty jail > - there are also two new subcommands - "create" and "remove", intended > for persistent jail operation > - if a jail is set to persistent, you can do the following sequence: > create start stop remove. > - non-persistent jails may also be created (won't be started) but will > be removed on a "stop" > > http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch > http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch Just a note - there were many attempts to add jail_myjail_name="myjail" variable to rc.conf but it was always denied with same answer: There is no reason for it, it can be done by jail_myjail_flags=" -n myjail" See this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/150599 and freebsd-jail@ archive. Maybe it will change in jail v2 land or jail config by Jamie... Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 22:53:36 2011 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 D2744106564A for ; Tue, 8 Nov 2011 22:53:36 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4488FC13 for ; Tue, 8 Nov 2011 22:53:36 +0000 (UTC) Received: by wwp14 with SMTP id 14so1497002wwp.31 for ; Tue, 08 Nov 2011 14:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OI6Sjgn3stK2mV6QCQ3lKfWIrbIPIScMk/vAhzFefPk=; b=DeAqWJgE9ea8RQxLG0AfJVSAo9jHvgiRFzjlWTEaAMMeGVXKBzxj+fa36Zl9JH4ieW ubG28keORsuNp92p4eWelt9hGuFaDDf7PCppSpEa6xowwYuhDhxU1CMcMhr8TjcSdvWg eeZdCjZVF7aS89QWZfiIGku9ItI1zcPIzECH8= MIME-Version: 1.0 Received: by 10.216.82.145 with SMTP id o17mr1226092wee.78.1320791336420; Tue, 08 Nov 2011 14:28:56 -0800 (PST) Received: by 10.216.37.19 with HTTP; Tue, 8 Nov 2011 14:28:56 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 16:28:56 -0600 Message-ID: From: Kurt Touet To: Dan The Man Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: samba+zfs 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, 08 Nov 2011 22:53:37 -0000 On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man wrote: > > > Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: > asterisk:~# uname -a > FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 > 19:46:53 CDT 2011 droot@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKER= NEL > =A0amd64 > asterisk:~# > > > > Dan. > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: Dan@SunSaturn.com > > On Tue, 8 Nov 2011, Dan The Man wrote: > >> >> Ok here is some specs: this been running fine on 8.2 stable and i was su= re >> it was running fine on RC1 as well. I did some testing against samba 34 = 35 >> and 36 in the ports collection all with the same slow write problems. >> >> I did further testing mounting drive in question with NFS and it did not >> suffer the same problem, so it seems just samba related here, where samb= a >> would actually outperform my NFS mount before, now its taking 10x as lon= g >> to write anything. >> >> This is really most simplistic setup I have, all I want to do is map a >> network drive at the house read/write so my laptop, desktop etc all have >> access to it. I have played with all the smb.conf options, and can't see= m >> to find where the issue is, further research suggests others are >> experiencing same problems with beta3 from following forum post: >> >> http://forums.freebsd.org/showthread.php?t=3D27300 >> >> Hardware this is running on: I beleive a 4 year old amd chip and board, >> with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD= as >> UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap >> hitachi drives for my storage space,which is mirrored nightly with rsync >> with another duplicate machine(cause I know someone is going to say why = not >> use raid5-raidz) >> >> Network specs: machine currently has dedicated IPV4 and gif0 tunneled IP= V6 >> addresses to he.net. >> >> I've played with nearly every option in smb.conf disabling, enabling etc >> and can't seem to find the issue: here are my current config file settin= gs >> on machine that could apply to samba: >> >> asterisk:~# cat /boot/loader.conf >> autoboot_delay=3D"5" >> accf_data_load=3D"YES" >> aio_load=3D"YES" >> zfs_load=3D"YES" >> kern.maxbcache=3D64M >> kern.ipc.maxpipekva=3D4M >> >> vfs.zfs.prefetch_disable=3D1 >> vm.kmem_size=3D"1844M" >> vfs.zfs.arc_min=3D"1024M" >> vfs.zfs.arc_max=3D"1536M" >> vfs.zfs.vdev.min_pending=3D2 >> vfs.zfs.vdev.max_pending=3D8 >> vfs.zfs.txg.timeout=3D5 >> vfs.zfs.zil_disable=3D"1" >> ahci_load=3D"YES" >> asterisk:~# >> >> asterisk:~# cat /usr/local/etc/smb.conf >> # Global parameters >> [global] >> =A0 =A0 =A0 workgroup =3D HOME >> =A0 =A0 =A0 netbios name =3D ASTERISK >> =A0 =A0 =A0 server string =3D "Primary backups" >> =A0 =A0 =A0 interfaces =3D sk0 >> =A0 =A0 =A0 #smb ports =3D 139 >> =A0 =A0 =A0 #security =3D USER >> =A0 =A0 =A0 security =3D SHARE >> =A0 =A0 =A0 encrypt passwords =3D Yes >> =A0 =A0 =A0 #socket options =3D TCP_NODELAY SO_RCVBUF=3D65536 SO_SNDBUF= =3D65536 >> =A0 =A0 =A0 domain master =3D no >> =A0 =A0 =A0 wins support =3D yes >> =A0 =A0 =A0 guest account =3D root >> =A0 =A0 =A0 socket options=3DSO_RCVBUF=3D131072 SO_SNDBUF=3D131072 TCP_N= ODELAY >> =A0 =A0 =A0 use sendfile =3D no >> =A0 =A0 =A0 level2 oplocks =3D True >> =A0 =A0 =A0 read raw =3D no >> =A0 =A0 =A0 write cache size =3D 262144 >> =A0 =A0 =A0 min receivefile size =3D 16384 >> =A0 =A0 =A0 aio read size =3D 16384 >> =A0 =A0 =A0 aio write size =3D 16384 >> =A0 =A0 =A0 aio write behind =3D yes >> =A0 =A0 =A0 dns proxy =3D no >> =A0 =A0 =A0 max log size =3D 50 >> =A0 =A0 =A0 #log file =3D /dev/null >> =A0 =A0 =A0 log file =3D /var/log/samba.log >> =A0 =A0 =A0 debug level =3D 1 >> =A0 =A0 =A0 syslog =3D 0 >> >> [data] >> =A0 =A0 =A0 comment =3D "Primary backups" >> =A0 =A0 =A0 path =3D /data/public >> =A0 =A0 =A0 read only =3D No >> =A0 =A0 =A0 guest ok =3D Yes >> =A0 =A0 =A0 valid users =3D root >> asterisk:~# asterisk:~# cat /etc/sysctl.conf >> # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith >> Exp $ >> # >> # =A0This file is read when going to multi-user and its contents piped t= hru >> # =A0``sysctl'' to adjust kernel values. =A0``man 5 sysctl.conf'' for de= tails. >> # >> >> # Uncomment this to prevent users from seeing information about processe= s >> that >> # are being run under another UID. >> #security.bsd.see_other_uids=3D0 >> >> #raise file descriptors on the system >> kern.maxfiles=3D204916 >> kern.maxfilesperproc=3D204916 >> >> #raise sockets we can accept >> kern.ipc.somaxconn=3D32768 >> >> #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html >> kern.ipc.maxsockbuf=3D16777216 >> net.inet.tcp.rfc1323=3D1 >> net.inet.tcp.sendbuf_max=3D16777216 >> net.inet.tcp.recvbuf_max=3D16777216 >> net.inet.tcp.sendspace=3D65536 >> net.inet.tcp.recvspace=3D131072 >> >> #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations >> net.inet.icmp.icmplim=3D500 >> kern.ipc.nmbjumbop=3D192000 >> kern.ipc.nmbclusters=3D229376 >> kern.ipc.maxsockets=3D204800 >> net.inet.tcp.maxtcptw=3D163840 >> #also add following to /boot/loader.conf >> #vm.kmem_size=3D1844M >> #kern.maxbcache=3D64M >> #kern.ipc.maxpipekva=3D4M >> >> #default setting of net.inet.ip.portrange.first is to low, causing us >> problems with bind >> net.inet.ip.portrange.last=3D65535 >> net.inet.ip.portrange.first=3D1024 >> >> #DOS protection >> net.inet.tcp.msl=3D7500 >> net.inet.tcp.blackhole=3D2 >> net.inet.udp.blackhole=3D1 >> net.inet.icmp.icmplim=3D50 >> net.inet.ip.accept_sourceroute=3D0 >> net.inet.ip.sourceroute=3D0 >> >> #some stuff for samba >> kern.ipc.nmbclusters=3D32768 >> kern.maxvnodes=3D800000 >> net.inet.tcp.delayed_ack=3D0 >> net.inet.tcp.inflight.enable=3D0 >> net.inet.tcp.path_mtu_discovery=3D0 >> net.inet.tcp.recvbuf_auto=3D1 >> net.inet.tcp.recvbuf_inc=3D524288 >> net.inet.tcp.sendbuf_auto=3D1 >> net.inet.tcp.sendbuf_inc=3D524288 >> net.inet.udp.maxdgram=3D57344 >> net.inet.udp.recvspace=3D65535 >> net.local.stream.recvspace=3D65535 >> net.local.stream.sendspace=3D65535 >> net.inet.tcp.mssdflt=3D1460 >> >> #IPSEC >> net.inet.ip.forwarding=3D1 >> net.inet6.ip6.forwarding=3D1 >> kern.module_path=3D/boot/kernel;/boot/modules;/usr/local/modules >> >> >> #NFS--not concerned with data integrity when playing mostly already stor= ed >> movies >> vfs.nfsrv.async=3D1 >> >> #JAIL >> #i like to use ping etc inside jail! >> security.jail.allow_raw_sockets=3D1 >> asterisk:~# >> >> >> Here are logs of me trying to mux a DTS mkv file from samba.log on debug >> level 10, I get the following over and over again: >> >> [2011/11/08 03:24:00.067974, 10] ../lib/util/util.c:415(dump_data) >> [2011/11/08 03:24:00.067981, =A03] smbd/process.c:1466(switch_message) >> =A0switch message SMBwriteX (pid 64308) conn 0x805008450 >> [2011/11/08 03:24:00.067990, =A04] smbd/uid.c:345(change_to_user) >> =A0Skipping user change - already user >> [2011/11/08 03:24:00.068001, 10] >> locking/locking.c:120(strict_lock_default) >> =A0is_locked: optimisation - exclusive oplock on file >> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >> [2011/11/08 03:24:00.068010, 10] >> locking/locking.c:162(strict_lock_default) >> =A0strict_lock_default: flavour =3D WINDOWS_LOCK brl start=3D83431665 le= n=3D65536 >> unlocked for fnum 49966 file >> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >> [2011/11/08 03:24:00.068021, 10] lib/recvfile.c:65(default_sys_recvfile) >> =A0default_sys_recvfile: from =3D 33, to =3D 39, offset=3D83431665, coun= t =3D 65536 >> [2011/11/08 03:24:00.068995, 10] smbd/fileio.c:143(real_write_file) >> =A0real_write_file (torrent_downloads_finished/Point.Break.1991.720p >> (1).mkv): pos =3D 83431665, size =3D 65536, returned 65536 >> [2011/11/08 03:24:00.069013, =A03] smbd/reply.c:4639(reply_write_and_X) >> =A0writeX fnum=3D49966 num=3D65536 wrote=3D65536 >> [2011/11/08 03:24:00.069038, 10] >> lib/util_sock.c:516(read_smb_length_return_keepalive) >> =A0got smb length of 65600 >> [2011/11/08 03:24:00.069052, 10] smbd/reply.c:4459(is_valid_writeX_buffe= r) >> =A0is_valid_writeX_buffer: true len =3D 65600, doff =3D 64, numtowrite = =3D 65536 >> [2011/11/08 03:24:00.069062, =A06] smbd/process.c:1659(process_smb) >> =A0got message type 0x0 of len 0x3f >> [2011/11/08 03:24:00.069072, =A03] smbd/process.c:1661(process_smb) >> =A0Transaction 15398 of length 67 (65536 toread) >> [2011/11/08 03:24:00.069081, =A05] lib/util.c:332(show_msg) >> [2011/11/08 03:24:00.069087, =A05] lib/util.c:342(show_msg) >> =A0size=3D63 >> =A0smb_com=3D0x2f >> =A0smb_rcls=3D0 >> =A0smb_reh=3D0 >> =A0smb_err=3D0 >> =A0smb_flg=3D24 >> =A0smb_flg2=3D51207 >> =A0smb_tid=3D1 >> =A0smb_pid=3D65279 >> =A0smb_uid=3D0 >> =A0smb_mid=3D36032 >> =A0smt_wct=3D14 >> =A0smb_vwv[ 0]=3D =A0255 (0xFF) >> =A0smb_vwv[ 1]=3D57054 (0xDEDE) >> =A0smb_vwv[ 2]=3D49966 (0xC32E) >> =A0smb_vwv[ 3]=3D 4337 (0x10F1) >> =A0smb_vwv[ 4]=3D 1274 (0x4FA) >> =A0smb_vwv[ 5]=3D65535 (0xFFFF) >> =A0smb_vwv[ 6]=3D65535 (0xFFFF) >> =A0smb_vwv[ 7]=3D =A0 =A00 (0x0) >> =A0smb_vwv[ 8]=3D =A0 =A00 (0x0) >> =A0smb_vwv[ 9]=3D =A0 =A01 (0x1) >> =A0smb_vwv[10]=3D =A0 =A00 (0x0) >> =A0smb_vwv[11]=3D =A0 64 (0x40) >> =A0smb_vwv[12]=3D =A0 =A00 (0x0) >> =A0smb_vwv[13]=3D =A0 =A00 (0x0) >> =A0smb_bcc=3D0 >> [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) >> [2011/11/08 03:24:00.069170, =A03] smbd/process.c:1466(switch_message) >> =A0switch message SMBwriteX (pid 64308) conn 0x805008450 >> [2011/11/08 03:24:00.069179, =A04] smbd/uid.c:345(change_to_user) >> =A0Skipping user change - already user >> [2011/11/08 03:24:00.069188, 10] >> locking/locking.c:120(strict_lock_default) >> =A0is_locked: optimisation - exclusive oplock on file >> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >> [2011/11/08 03:24:00.069197, 10] >> locking/locking.c:162(strict_lock_default) >> =A0strict_lock_default: flavour =3D WINDOWS_LOCK brl start=3D83497201 le= n=3D65536 >> unlocked for fnum 49966 file >> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >> [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfile) >> =A0default_sys_recvfile: from =3D 33, to =3D 39, offset=3D83497201, coun= t =3D 65536 >> [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) >> =A0real_write_file (torrent_downloads_finished/Point.Break.1991.720p >> (1).mkv): pos =3D 83497201, size =3D 65536, returned 65536 >> [2011/11/08 03:24:00.070004, =A03] smbd/reply.c:4639(reply_write_and_X) >> =A0writeX fnum=3D49966 num=3D65536 wrote=3D65536 >> [2011/11/08 03:24:00.070030, 10] >> lib/util_sock.c:516(read_smb_length_return_keepalive) >> =A0got smb length of 65600 >> [2011/11/08 03:24:00.070044, 10] smbd/reply.c:4459(is_valid_writeX_buffe= r) >> =A0is_valid_writeX_buffer: true len =3D 65600, doff =3D 64, numtowrite = =3D 65536 >> [2011/11/08 03:24:00.070053, =A06] smbd/process.c:1659(process_smb) >> =A0got message type 0x0 of len 0x3f >> [2011/11/08 03:24:00.070063, =A03] smbd/process.c:1661(process_smb) >> =A0Transaction 15399 of length 67 (65536 toread) >> [2011/11/08 03:24:00.070072, =A05] lib/util.c:332(show_msg) >> [2011/11/08 03:24:00.070077, =A05] lib/util.c:342(show_msg) >> =A0size=3D63 >> =A0smb_com=3D0x2f >> =A0smb_rcls=3D0 >> =A0smb_reh=3D0 >> =A0smb_err=3D0 >> =A0smb_flg=3D24 >> =A0smb_flg2=3D51207 >> =A0smb_tid=3D1 >> =A0smb_pid=3D65279 >> =A0smb_uid=3D0 >> =A0smb_mid=3D36102 >> =A0smt_wct=3D14 >> =A0smb_vwv[ 0]=3D =A0255 (0xFF) >> =A0smb_vwv[ 1]=3D57054 (0xDEDE) >> =A0smb_vwv[ 2]=3D49966 (0xC32E) >> =A0smb_vwv[ 3]=3D 4337 (0x10F1) >> =A0smb_vwv[ 4]=3D 1275 (0x4FB) >> =A0smb_vwv[ 5]=3D65535 (0xFFFF) >> =A0smb_vwv[ 6]=3D65535 (0xFFFF) >> =A0smb_vwv[ 7]=3D =A0 =A00 (0x0) >> =A0smb_vwv[ 8]=3D =A0 =A00 (0x0) >> =A0smb_vwv[ 9]=3D =A0 =A01 (0x1) >> =A0smb_vwv[10]=3D =A0 =A00 (0x0) >> =A0smb_vwv[11]=3D =A0 64 (0x40) >> =A0smb_vwv[12]=3D =A0 =A00 (0x0) >> =A0smb_vwv[13]=3D =A0 =A00 (0x0) >> =A0smb_bcc=3D0 >> >> >> Hopefully maybe someone can shine some light on this.... >> >> >> Dan. >> >> >> -- >> Dan The Man >> CTO/ Senior System Administrator >> Websites, Domains and Everything else >> http://www.SunSaturn.com >> Email: Dan@SunSaturn.com >> >> On Fri, 28 Oct 2011, Garrett Cooper wrote: >> >>> On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote: >>>> >>>> >>>> Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs >>>> its taking over an hour to just mux in things like DTS english, where = it >>>> was >>>> 15 minutes on beta3. >>> >>> Hi Dan, >>> - Can you do more deterministic / scientific benchmarks? >>> - Did you upgrade Samba? >>> - What is your system's operating hardware profile? >>> Thanks! >>> -Garrett >>> I had noticed a similar problem with doing large writes from my windows workstation to my freebsd ZFS array. Previously I had been able to write at around 30MB/s (limited by a slow SATA controller), and those speeds had dropped to 3-5MB/s with long pauses between writes to the array (monitoring with zpool iostat). However, I just updated to stable/9 r227357 and the issue seems to have gone away; I'm back up to 30MB/s writes. Hope you find the same sort of thing, -kurt From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:03:45 2011 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 6955C106566B for ; Tue, 8 Nov 2011 23:03:45 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 12F5E8FC17 for ; Tue, 8 Nov 2011 23:03:45 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 4A636119C6F; Tue, 8 Nov 2011 17:03:43 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320793423; bh=GTXuYp59HdLpgOjUctY+8Hevd7s8nK/uPNBmgNJZpRM=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=QO3V1bK7juwbq0hJy7CS2QdeIZnacFUpFghWqXQP/wIgXsEihf16fKmOczUyXA+kn ixrJBy/HHTsMiRzrjdV4r89gtDn6uiCzHCAzQv+u9DYobFq+rfyQRAT3bqRFsBO3BL pS7xnbKOLDwBN5DGPvreShVoXWfWeJg273oJm04w= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 452B3119C68 for ; Tue, 8 Nov 2011 17:03:43 -0600 (CST) Date: Tue, 8 Nov 2011 17:03:43 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2338054437-991891071-1320793423=:10168" Subject: /etc/group chkgrp invalid character @ 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, 08 Nov 2011 23:03:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2338054437-991891071-1320793423=:10168 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT With libnss-mysql we are able to login using email addresses etc. In the daily cron "Daily run output" email always get the following: Verifying group file syntax: chkgrp: /etc/group: line 3: '@' invalid character Could we modify system to support email addresses as usernames. From my testing it works fine, even with "Daily run output" complaining I can still su to user i added in wheel group. We'd need to fix ckkgrp source, adduser source, and making move to: #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h I beleive OS's like macOSX etc when I read over their source is already setting this to 256. I beleive param.h is only place need to define this, in 8.2 and previous UT_NAMESIZE needed to be set in /usr/src/include/utmp.h as 255 and /usr/src/sys/sys/param.h needed MAXLOGNAME set to UT_NAMESIZE+1, but seems we did away with utmp.h in freebsd 9.0 only needing to set param.h now. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com On Tue, 8 Nov 2011, Kurt Touet wrote: > On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man wrote: >> >> >> Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: >> asterisk:~# uname -a >> FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 >> 19:46:53 CDT 2011 droot@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL >>  amd64 >> asterisk:~# >> >> >> >> Dan. >> >> >> -- >> Dan The Man >> CTO/ Senior System Administrator >> Websites, Domains and Everything else >> http://www.SunSaturn.com >> Email: Dan@SunSaturn.com >> >> On Tue, 8 Nov 2011, Dan The Man wrote: >> >>> >>> Ok here is some specs: this been running fine on 8.2 stable and i was sure >>> it was running fine on RC1 as well. I did some testing against samba 34 35 >>> and 36 in the ports collection all with the same slow write problems. >>> >>> I did further testing mounting drive in question with NFS and it did not >>> suffer the same problem, so it seems just samba related here, where samba >>> would actually outperform my NFS mount before, now its taking 10x as long >>> to write anything. >>> >>> This is really most simplistic setup I have, all I want to do is map a >>> network drive at the house read/write so my laptop, desktop etc all have >>> access to it. I have played with all the smb.conf options, and can't seem >>> to find where the issue is, further research suggests others are >>> experiencing same problems with beta3 from following forum post: >>> >>> http://forums.freebsd.org/showthread.php?t=27300 >>> >>> Hardware this is running on: I beleive a 4 year old amd chip and board, >>> with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as >>> UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap >>> hitachi drives for my storage space,which is mirrored nightly with rsync >>> with another duplicate machine(cause I know someone is going to say why not >>> use raid5-raidz) >>> >>> Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 >>> addresses to he.net. >>> >>> I've played with nearly every option in smb.conf disabling, enabling etc >>> and can't seem to find the issue: here are my current config file settings >>> on machine that could apply to samba: >>> >>> asterisk:~# cat /boot/loader.conf >>> autoboot_delay="5" >>> accf_data_load="YES" >>> aio_load="YES" >>> zfs_load="YES" >>> kern.maxbcache=64M >>> kern.ipc.maxpipekva=4M >>> >>> vfs.zfs.prefetch_disable=1 >>> vm.kmem_size="1844M" >>> vfs.zfs.arc_min="1024M" >>> vfs.zfs.arc_max="1536M" >>> vfs.zfs.vdev.min_pending=2 >>> vfs.zfs.vdev.max_pending=8 >>> vfs.zfs.txg.timeout=5 >>> vfs.zfs.zil_disable="1" >>> ahci_load="YES" >>> asterisk:~# >>> >>> asterisk:~# cat /usr/local/etc/smb.conf >>> # Global parameters >>> [global] >>>       workgroup = HOME >>>       netbios name = ASTERISK >>>       server string = "Primary backups" >>>       interfaces = sk0 >>>       #smb ports = 139 >>>       #security = USER >>>       security = SHARE >>>       encrypt passwords = Yes >>>       #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 >>>       domain master = no >>>       wins support = yes >>>       guest account = root >>>       socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY >>>       use sendfile = no >>>       level2 oplocks = True >>>       read raw = no >>>       write cache size = 262144 >>>       min receivefile size = 16384 >>>       aio read size = 16384 >>>       aio write size = 16384 >>>       aio write behind = yes >>>       dns proxy = no >>>       max log size = 50 >>>       #log file = /dev/null >>>       log file = /var/log/samba.log >>>       debug level = 1 >>>       syslog = 0 >>> >>> [data] >>>       comment = "Primary backups" >>>       path = /data/public >>>       read only = No >>>       guest ok = Yes >>>       valid users = root >>> asterisk:~# asterisk:~# cat /etc/sysctl.conf >>> # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith >>> Exp $ >>> # >>> #  This file is read when going to multi-user and its contents piped thru >>> #  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details. >>> # >>> >>> # Uncomment this to prevent users from seeing information about processes >>> that >>> # are being run under another UID. >>> #security.bsd.see_other_uids=0 >>> >>> #raise file descriptors on the system >>> kern.maxfiles=204916 >>> kern.maxfilesperproc=204916 >>> >>> #raise sockets we can accept >>> kern.ipc.somaxconn=32768 >>> >>> #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html >>> kern.ipc.maxsockbuf=16777216 >>> net.inet.tcp.rfc1323=1 >>> net.inet.tcp.sendbuf_max=16777216 >>> net.inet.tcp.recvbuf_max=16777216 >>> net.inet.tcp.sendspace=65536 >>> net.inet.tcp.recvspace=131072 >>> >>> #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations >>> net.inet.icmp.icmplim=500 >>> kern.ipc.nmbjumbop=192000 >>> kern.ipc.nmbclusters=229376 >>> kern.ipc.maxsockets=204800 >>> net.inet.tcp.maxtcptw=163840 >>> #also add following to /boot/loader.conf >>> #vm.kmem_size=1844M >>> #kern.maxbcache=64M >>> #kern.ipc.maxpipekva=4M >>> >>> #default setting of net.inet.ip.portrange.first is to low, causing us >>> problems with bind >>> net.inet.ip.portrange.last=65535 >>> net.inet.ip.portrange.first=1024 >>> >>> #DOS protection >>> net.inet.tcp.msl=7500 >>> net.inet.tcp.blackhole=2 >>> net.inet.udp.blackhole=1 >>> net.inet.icmp.icmplim=50 >>> net.inet.ip.accept_sourceroute=0 >>> net.inet.ip.sourceroute=0 >>> >>> #some stuff for samba >>> kern.ipc.nmbclusters=32768 >>> kern.maxvnodes=800000 >>> net.inet.tcp.delayed_ack=0 >>> net.inet.tcp.inflight.enable=0 >>> net.inet.tcp.path_mtu_discovery=0 >>> net.inet.tcp.recvbuf_auto=1 >>> net.inet.tcp.recvbuf_inc=524288 >>> net.inet.tcp.sendbuf_auto=1 >>> net.inet.tcp.sendbuf_inc=524288 >>> net.inet.udp.maxdgram=57344 >>> net.inet.udp.recvspace=65535 >>> net.local.stream.recvspace=65535 >>> net.local.stream.sendspace=65535 >>> net.inet.tcp.mssdflt=1460 >>> >>> #IPSEC >>> net.inet.ip.forwarding=1 >>> net.inet6.ip6.forwarding=1 >>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules >>> >>> >>> #NFS--not concerned with data integrity when playing mostly already stored >>> movies >>> vfs.nfsrv.async=1 >>> >>> #JAIL >>> #i like to use ping etc inside jail! >>> security.jail.allow_raw_sockets=1 >>> asterisk:~# >>> >>> >>> Here are logs of me trying to mux a DTS mkv file from samba.log on debug >>> level 10, I get the following over and over again: >>> >>> [2011/11/08 03:24:00.067974, 10] ../lib/util/util.c:415(dump_data) >>> [2011/11/08 03:24:00.067981,  3] smbd/process.c:1466(switch_message) >>>  switch message SMBwriteX (pid 64308) conn 0x805008450 >>> [2011/11/08 03:24:00.067990,  4] smbd/uid.c:345(change_to_user) >>>  Skipping user change - already user >>> [2011/11/08 03:24:00.068001, 10] >>> locking/locking.c:120(strict_lock_default) >>>  is_locked: optimisation - exclusive oplock on file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.068010, 10] >>> locking/locking.c:162(strict_lock_default) >>>  strict_lock_default: flavour = WINDOWS_LOCK brl start=83431665 len=65536 >>> unlocked for fnum 49966 file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.068021, 10] lib/recvfile.c:65(default_sys_recvfile) >>>  default_sys_recvfile: from = 33, to = 39, offset=83431665, count = 65536 >>> [2011/11/08 03:24:00.068995, 10] smbd/fileio.c:143(real_write_file) >>>  real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>> (1).mkv): pos = 83431665, size = 65536, returned 65536 >>> [2011/11/08 03:24:00.069013,  3] smbd/reply.c:4639(reply_write_and_X) >>>  writeX fnum=49966 num=65536 wrote=65536 >>> [2011/11/08 03:24:00.069038, 10] >>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>  got smb length of 65600 >>> [2011/11/08 03:24:00.069052, 10] smbd/reply.c:4459(is_valid_writeX_buffer) >>>  is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 >>> [2011/11/08 03:24:00.069062,  6] smbd/process.c:1659(process_smb) >>>  got message type 0x0 of len 0x3f >>> [2011/11/08 03:24:00.069072,  3] smbd/process.c:1661(process_smb) >>>  Transaction 15398 of length 67 (65536 toread) >>> [2011/11/08 03:24:00.069081,  5] lib/util.c:332(show_msg) >>> [2011/11/08 03:24:00.069087,  5] lib/util.c:342(show_msg) >>>  size=63 >>>  smb_com=0x2f >>>  smb_rcls=0 >>>  smb_reh=0 >>>  smb_err=0 >>>  smb_flg=24 >>>  smb_flg2=51207 >>>  smb_tid=1 >>>  smb_pid=65279 >>>  smb_uid=0 >>>  smb_mid=36032 >>>  smt_wct=14 >>>  smb_vwv[ 0]=  255 (0xFF) >>>  smb_vwv[ 1]=57054 (0xDEDE) >>>  smb_vwv[ 2]=49966 (0xC32E) >>>  smb_vwv[ 3]= 4337 (0x10F1) >>>  smb_vwv[ 4]= 1274 (0x4FA) >>>  smb_vwv[ 5]=65535 (0xFFFF) >>>  smb_vwv[ 6]=65535 (0xFFFF) >>>  smb_vwv[ 7]=    0 (0x0) >>>  smb_vwv[ 8]=    0 (0x0) >>>  smb_vwv[ 9]=    1 (0x1) >>>  smb_vwv[10]=    0 (0x0) >>>  smb_vwv[11]=   64 (0x40) >>>  smb_vwv[12]=    0 (0x0) >>>  smb_vwv[13]=    0 (0x0) >>>  smb_bcc=0 >>> [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) >>> [2011/11/08 03:24:00.069170,  3] smbd/process.c:1466(switch_message) >>>  switch message SMBwriteX (pid 64308) conn 0x805008450 >>> [2011/11/08 03:24:00.069179,  4] smbd/uid.c:345(change_to_user) >>>  Skipping user change - already user >>> [2011/11/08 03:24:00.069188, 10] >>> locking/locking.c:120(strict_lock_default) >>>  is_locked: optimisation - exclusive oplock on file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.069197, 10] >>> locking/locking.c:162(strict_lock_default) >>>  strict_lock_default: flavour = WINDOWS_LOCK brl start=83497201 len=65536 >>> unlocked for fnum 49966 file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfile) >>>  default_sys_recvfile: from = 33, to = 39, offset=83497201, count = 65536 >>> [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) >>>  real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>> (1).mkv): pos = 83497201, size = 65536, returned 65536 >>> [2011/11/08 03:24:00.070004,  3] smbd/reply.c:4639(reply_write_and_X) >>>  writeX fnum=49966 num=65536 wrote=65536 >>> [2011/11/08 03:24:00.070030, 10] >>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>  got smb length of 65600 >>> [2011/11/08 03:24:00.070044, 10] smbd/reply.c:4459(is_valid_writeX_buffer) >>>  is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 >>> [2011/11/08 03:24:00.070053,  6] smbd/process.c:1659(process_smb) >>>  got message type 0x0 of len 0x3f >>> [2011/11/08 03:24:00.070063,  3] smbd/process.c:1661(process_smb) >>>  Transaction 15399 of length 67 (65536 toread) >>> [2011/11/08 03:24:00.070072,  5] lib/util.c:332(show_msg) >>> [2011/11/08 03:24:00.070077,  5] lib/util.c:342(show_msg) >>>  size=63 >>>  smb_com=0x2f >>>  smb_rcls=0 >>>  smb_reh=0 >>>  smb_err=0 >>>  smb_flg=24 >>>  smb_flg2=51207 >>>  smb_tid=1 >>>  smb_pid=65279 >>>  smb_uid=0 >>>  smb_mid=36102 >>>  smt_wct=14 >>>  smb_vwv[ 0]=  255 (0xFF) >>>  smb_vwv[ 1]=57054 (0xDEDE) >>>  smb_vwv[ 2]=49966 (0xC32E) >>>  smb_vwv[ 3]= 4337 (0x10F1) >>>  smb_vwv[ 4]= 1275 (0x4FB) >>>  smb_vwv[ 5]=65535 (0xFFFF) >>>  smb_vwv[ 6]=65535 (0xFFFF) >>>  smb_vwv[ 7]=    0 (0x0) >>>  smb_vwv[ 8]=    0 (0x0) >>>  smb_vwv[ 9]=    1 (0x1) >>>  smb_vwv[10]=    0 (0x0) >>>  smb_vwv[11]=   64 (0x40) >>>  smb_vwv[12]=    0 (0x0) >>>  smb_vwv[13]=    0 (0x0) >>>  smb_bcc=0 >>> >>> >>> Hopefully maybe someone can shine some light on this.... >>> >>> >>> Dan. >>> >>> >>> -- >>> Dan The Man >>> CTO/ Senior System Administrator >>> Websites, Domains and Everything else >>> http://www.SunSaturn.com >>> Email: Dan@SunSaturn.com >>> >>> On Fri, 28 Oct 2011, Garrett Cooper wrote: >>> >>>> On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote: >>>>> >>>>> >>>>> Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs >>>>> its taking over an hour to just mux in things like DTS english, where it >>>>> was >>>>> 15 minutes on beta3. >>>> >>>> Hi Dan, >>>> - Can you do more deterministic / scientific benchmarks? >>>> - Did you upgrade Samba? >>>> - What is your system's operating hardware profile? >>>> Thanks! >>>> -Garrett >>>> > > I had noticed a similar problem with doing large writes from my > windows workstation to my freebsd ZFS array. Previously I had been > able to write at around 30MB/s (limited by a slow SATA controller), > and those speeds had dropped to 3-5MB/s with long pauses between > writes to the array (monitoring with zpool iostat). However, I just > updated to stable/9 r227357 and the issue seems to have gone away; I'm > back up to 30MB/s writes. > > Hope you find the same sort of thing, > -kurt > --2338054437-991891071-1320793423=:10168-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:06:40 2011 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 91C051065674; Tue, 8 Nov 2011 23:06:40 +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 53CAA8FC12; Tue, 8 Nov 2011 23:06:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA8N6ddq001277; Tue, 8 Nov 2011 18:06:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA8N6dr4001260; Tue, 8 Nov 2011 23:06:39 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 8 Nov 2011 23:06:39 GMT Message-Id: <201111082306.pA8N6dr4001260@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/i386 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, 08 Nov 2011 23:06:40 -0000 TB --- 2011-11-08 20:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-08 20:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-08 20:50:00 - cleaning the object tree TB --- 2011-11-08 20:50:51 - cvsupping the source tree TB --- 2011-11-08 20:50:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-08 20:56:15 - building world TB --- 2011-11-08 20:56:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 20:56:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 20:56:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 20:56:15 - SRCCONF=/dev/null TB --- 2011-11-08 20:56:15 - TARGET=i386 TB --- 2011-11-08 20:56:15 - TARGET_ARCH=i386 TB --- 2011-11-08 20:56:15 - TZ=UTC TB --- 2011-11-08 20:56:15 - __MAKE_CONF=/dev/null TB --- 2011-11-08 20:56:15 - cd /src TB --- 2011-11-08 20:56:15 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 8 20:56:16 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Nov 8 23:04:37 UTC 2011 TB --- 2011-11-08 23:04:37 - generating LINT kernel config TB --- 2011-11-08 23:04:37 - cd /src/sys/i386/conf TB --- 2011-11-08 23:04:37 - /usr/bin/make -B LINT TB --- 2011-11-08 23:04:37 - cd /src/sys/i386/conf TB --- 2011-11-08 23:04:37 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-08 23:04:37 - building LINT-NOINET kernel TB --- 2011-11-08 23:04:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 23:04:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 23:04:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 23:04:37 - SRCCONF=/dev/null TB --- 2011-11-08 23:04:37 - TARGET=i386 TB --- 2011-11-08 23:04:37 - TARGET_ARCH=i386 TB --- 2011-11-08 23:04:37 - TZ=UTC TB --- 2011-11-08 23:04:37 - __MAKE_CONF=/dev/null TB --- 2011-11-08 23:04:37 - cd /src TB --- 2011-11-08 23:04:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Nov 8 23:04:37 UTC 2011 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpi_support/acpi_wmi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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 -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-fl! oat -ffreestanding -fstack-protector /src/sys/dev/ti/if_ti.c:134:2: error: #error "options TI_JUMBO_HDRSPLIT requires TI_SF_BUF_JUMBO" mkdep: compile failed *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-08 23:06:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-08 23:06:38 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-08 23:06:38 - 6274.74 user 1082.46 system 8198.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:31:33 2011 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 53D9E1065672; Tue, 8 Nov 2011 23:31:33 +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 176DB8FC0A; Tue, 8 Nov 2011 23:31:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA8NVWxn098193; Tue, 8 Nov 2011 18:31:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA8NVWFH098151; Tue, 8 Nov 2011 23:31:32 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 8 Nov 2011 23:31:32 GMT Message-Id: <201111082331.pA8NVWFH098151@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 amd64/amd64 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, 08 Nov 2011 23:31:33 -0000 TB --- 2011-11-08 20:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-08 20:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-08 20:50:00 - cleaning the object tree TB --- 2011-11-08 20:50:50 - cvsupping the source tree TB --- 2011-11-08 20:50:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-08 20:51:02 - building world TB --- 2011-11-08 20:51:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 20:51:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 20:51:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 20:51:02 - SRCCONF=/dev/null TB --- 2011-11-08 20:51:02 - TARGET=amd64 TB --- 2011-11-08 20:51:02 - TARGET_ARCH=amd64 TB --- 2011-11-08 20:51:02 - TZ=UTC TB --- 2011-11-08 20:51:02 - __MAKE_CONF=/dev/null TB --- 2011-11-08 20:51:02 - cd /src TB --- 2011-11-08 20:51:02 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 8 20:51:03 UTC 2011 >>> 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 Tue Nov 8 23:29:48 UTC 2011 TB --- 2011-11-08 23:29:48 - generating LINT kernel config TB --- 2011-11-08 23:29:48 - cd /src/sys/amd64/conf TB --- 2011-11-08 23:29:48 - /usr/bin/make -B LINT TB --- 2011-11-08 23:29:48 - cd /src/sys/amd64/conf TB --- 2011-11-08 23:29:48 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-08 23:29:48 - building LINT-NOINET kernel TB --- 2011-11-08 23:29:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 23:29:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 23:29:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 23:29:48 - SRCCONF=/dev/null TB --- 2011-11-08 23:29:48 - TARGET=amd64 TB --- 2011-11-08 23:29:48 - TARGET_ARCH=amd64 TB --- 2011-11-08 23:29:48 - TZ=UTC TB --- 2011-11-08 23:29:48 - __MAKE_CONF=/dev/null TB --- 2011-11-08 23:29:48 - cd /src TB --- 2011-11-08 23:29:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Nov 8 23:29:49 UTC 2011 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpi_support/acpi_wmi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -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 -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zon! e -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /src/sys/dev/ti/if_ti.c:134:2: error: #error "options TI_JUMBO_HDRSPLIT requires TI_SF_BUF_JUMBO" mkdep: compile failed *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-08 23:31:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-08 23:31:31 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-08 23:31:31 - 7632.41 user 1465.23 system 9691.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:36:41 2011 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 5643E1065677; Tue, 8 Nov 2011 23:36:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C019B8FC13; Tue, 8 Nov 2011 23:36:40 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so1386138vcb.13 for ; Tue, 08 Nov 2011 15:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=RMsMliM6DY5IOy62EWI0L4EpCrSNnnzqgP/5zFEODzA=; b=DSt3+5BP4a48/lC4+qL8o5qmWhT/otdSVp3YwILpeglpKW45t1BmVTtrh+eaLIiyMq pr3vfw4OuaHLUiyG8lKc2GzOr8i7H4TMlVUJkd3ZdfwV7iKPpRCFUrxYsf7T1z+hlhqz TToMSSJ8bBRhPHIVY2fMBid5PuIQKkMSIb9iM= MIME-Version: 1.0 Received: by 10.52.177.3 with SMTP id cm3mr34659472vdc.89.1320795399970; Tue, 08 Nov 2011 15:36:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Tue, 8 Nov 2011 15:36:39 -0800 (PST) Date: Tue, 8 Nov 2011 15:36:39 -0800 X-Google-Sender-Auth: Y2O0f1ETVyi8jh9GZrRWPjktwLQ Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-wireless@freebsd.org, freebsd-mobile@freebsd.org Subject: ath 11n tx work is now in head 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, 08 Nov 2011 23:36:41 -0000 Hi, I've merged in the bulk of my 11n TX work in a series of commits, culminating in a (still) overly large patch which added software TX aggregation and TX queue support. It's absolutely possible this has completely broken the ath driver. I'm going to spend the next few days throwing it against the hardware I have with me just to see if I broke anything during the merge. If you feel brave, throw on ATH_ENABLE_11N in your kernel config file and give it a go. If you're using legacy (non-11n) NICs, or you're not using 11N at home, please enable it too. It affects the non-11n TX path as well and I'd like to make absolutely sure this is still (mostly) working. Finally, if you -are- going to be testing this, I won't accept any error reports unless you've been running it with the -current debugging flags. That is, lock/witness debugging, asserts, and the memory allocator debugging. There's just too much that could be going wrong and I'd like to make sure that I have all of the relevant information from testers. Thanks again! Adrian From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:42:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B02761065670 for ; Tue, 8 Nov 2011 23:42:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 613D314E345; Tue, 8 Nov 2011 23:42:20 +0000 (UTC) Message-ID: <4EB9BE5C.8070700@FreeBSD.org> Date: Tue, 08 Nov 2011 15:42:20 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dan The Man References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: /etc/group chkgrp invalid character @ 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, 08 Nov 2011 23:42:20 -0000 If you want to start a new thread please don't reply to an old one and change the subject line, please create a whole new message instead. That way those of us who read our mail threaded won't miss your new topic because it is hidden under an old one. -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:45:01 2011 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 6DBE510656D8; Tue, 8 Nov 2011 23:45:01 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6458FC21; Tue, 8 Nov 2011 23:45:01 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id B8DCE119C6F; Tue, 8 Nov 2011 17:45:00 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320795900; bh=cX2ocAzXTJg2oIGf7TlufYs6lDid/42X1jhQk9w6DIQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=ds5/ymhnzr65JB2Mqrz0SW7sP9Owhz2JxCAUBmdiRidEazRaSt7V2vkMW7V0Q7WMb 7/5mEWmVE5pMagKt+TYwI01NCu6jxs8/NkfEkumgY2vnVOg9jdL0scZAZz4qjPsJ+5 TX+/tfTW5myJEKPYo4a9///XP5bQbBerszBxN1YU= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id B8192119C62; Tue, 8 Nov 2011 17:45:00 -0600 (CST) Date: Tue, 8 Nov 2011 17:45:00 -0600 (CST) From: Dan The Man To: Doug Barton In-Reply-To: <4EB9BE5C.8070700@FreeBSD.org> Message-ID: References: <4EB9BE5C.8070700@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: /etc/group chkgrp invalid character @ 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, 08 Nov 2011 23:45:01 -0000 Understood, will resubmit, I didn't think of the email headers. Thank-you, Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com On Tue, 8 Nov 2011, Doug Barton wrote: > If you want to start a new thread please don't reply to an old one and > change the subject line, please create a whole new message instead. That > way those of us who read our mail threaded won't miss your new topic > because it is hidden under an old one. > > > -- > > "We could put the whole Internet into a book." > "Too practical." > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:47:28 2011 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 A0E11106564A for ; Tue, 8 Nov 2011 23:47:28 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D56A8FC18 for ; Tue, 8 Nov 2011 23:47:28 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 1E8C8119C6F; Tue, 8 Nov 2011 17:47:28 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320796048; bh=2vsQqvZqExmG6AXoUtoIIxG3IiJSeyTxonrt8Vwk5vw=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=ePbZ7RILQXtNznRtLVJbWGf9702NQ1KCx1uMEXWeU9OakzDeM0dXlYnstGO9r9bx6 1KBJEwDOJvVzvSK5ExLfboHrXjw08MlYsJKDKTQSAvTR70nLGFHM32KraaWXgGH/8y fe1ESAUwSc/+UIrPV+IJTo1UhuyeI2dx4WtRS3jk= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 19F98119C62 for ; Tue, 8 Nov 2011 17:47:28 -0600 (CST) Date: Tue, 8 Nov 2011 17:47:28 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: MAXLOGNAME + /etc/group + chkgrp invalid character @ 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, 08 Nov 2011 23:47:28 -0000 With libnss-mysql we are able to login using email addresses etc. In the daily cron "Daily run output" email always get the following: Verifying group file syntax: chkgrp: /etc/group: line 3: '@' invalid character Could we modify system to support email addresses as usernames. From my testing it works fine, even with "Daily run output" complaining I can still su to user i added in wheel group. We'd need to fix ckkgrp source, adduser source, and making move to: #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h I beleive OS's like macOSX etc when I read over their source is already setting this to 256. I beleive param.h is only place need to define this, in 8.2 and previous UT_NAMESIZE needed to be set in /usr/src/include/utmp.h as 255 and /usr/src/sys/sys/param.h needed MAXLOGNAME set to UT_NAMESIZE+1, but seems we did away with utmp.h in freebsd 9.0 only needing to set param.h now. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 00:08:26 2011 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 BAE65106564A for ; Wed, 9 Nov 2011 00:08:26 +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 882968FC12 for ; Wed, 9 Nov 2011 00:08:26 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA9082tY022182 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Nov 2011 16:08:05 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EB9C469.9070208@freebsd.org> Date: Tue, 08 Nov 2011 16:08:09 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "K. Macy" , Alan Cox , Andriy Gapon , Attilio Rao , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 00:08:26 -0000 On 11/8/11 10:49 AM, Arnaud Lacombe wrote: > Hi, > To avoid future complaints about the fact that I would be only "talk" > without "action", I did implement what I suggested above. As it is > quite a large patch-set, I will not post it directly here, however, it > is available on github: > > https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug > > It convert a bunch of debug interface to use the caller instruction > pointer, as well as a proof-of-concept teaching printf(9) to convert > IP to symbol_name+offset. > > It translates in a direct saving of about +250kB on i386's GENERIC, > just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, > translates to a save of +80kB. > > Please note that this is still WIP code. A couple of comments. Firstly, the idea of a printf method to print the IP as symbol+offset is an interesting idea that should be followed up in its own right. However, (comment 2) I would much rather file+line in this case. I don't want to have the tools to decode the offset into a location in sources. We have both systems in operation art work and I far prefer the latter. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 00:08:48 2011 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 5B9B61065674 for ; Wed, 9 Nov 2011 00:08:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 432A88FC0C for ; Wed, 9 Nov 2011 00:08:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LUD00MD39QMFC70@asmtp026.mac.com> for freebsd-current@freebsd.org; Tue, 08 Nov 2011 16:08:47 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-11-08_05:2011-11-08, 2011-11-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1111080272 From: Chuck Swiger In-reply-to: Date: Tue, 08 Nov 2011 16:08:46 -0800 Message-id: References: To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: MAXLOGNAME + /etc/group + chkgrp invalid character @ 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, 09 Nov 2011 00:08:48 -0000 On Nov 8, 2011, at 3:47 PM, Dan The Man wrote: > In the daily cron "Daily run output" email always get the following: > > Verifying group file syntax: > chkgrp: /etc/group: line 3: '@' invalid character chkgrp expects group names to consist of characters in isalnum(). > Could we modify system to support email addresses as usernames. Sure, that's why FreeBSD comes with source code. You can modify anything you like. :-) However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports. You're not going to break anything allowing "@" into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are. A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users. > From my testing it works fine, even with "Daily run output" complaining I can still su to user i added in wheel group. > We'd need to fix ckkgrp source, > adduser source, and making move to: > #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h You can do that also, but I think you'll break compatibility with NIS/YP. You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 00:32:52 2011 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 AED94106566B for ; Wed, 9 Nov 2011 00:32:52 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 875288FC18 for ; Wed, 9 Nov 2011 00:32:52 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 6DD03119C6D; Tue, 8 Nov 2011 18:32:51 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320798771; bh=rT+1jWoF/lFfh0lEAaxdRfG+dnkvB5qMm/XUtDBNsfA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=PU/FolQB0sj1d0H33gXRauFC4q2xu0VuPKBtUq+SiHwnpRiHd99ZNTepKO7AAODu7 zSqTEOIoIglpH+yRlgrm7rN2cFy+5rJFW5NgJym5KwnCGCzBoGVU5LofGodvPJZT6/ 1Is1mVqrZL5zq7sHm/RgwdS7t6/7wrKvB3QYSq/g= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 686B6119C68; Tue, 8 Nov 2011 18:32:51 -0600 (CST) Date: Tue, 8 Nov 2011 18:32:51 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: MAXLOGNAME + /etc/group + chkgrp invalid character @ 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, 09 Nov 2011 00:32:52 -0000 On Tue, 8 Nov 2011, Chuck Swiger wrote: > On Nov 8, 2011, at 3:47 PM, Dan The Man wrote: >> In the daily cron "Daily run output" email always get the following: >> >> Verifying group file syntax: >> chkgrp: /etc/group: line 3: '@' invalid character > > chkgrp expects group names to consist of characters in isalnum(). K so thats a simple fix where it does that check. > >> Could we modify system to support email addresses as usernames. > > Sure, that's why FreeBSD comes with source code. > You can modify anything you like. :-) > > However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports. You're not going to break anything allowing "@" into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are. > > A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users. Wish you would elaborate abit more here, what I have found is email addresses tend to make the best usernames, people can remember them :) They are unique, and you solve 2 problems right away: a) they can actually remember their username b) they aren't having to pick through a million different taken usernames they have to pick on their own, which is frusterating way people often do signups. > >> From my testing it works fine, even with "Daily run output" complaining I can still su to user i added in wheel group. >> We'd need to fix ckkgrp source, >> adduser source, and making move to: >> #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h > > You can do that also, but I think you'll break compatibility with NIS/YP. > Well with nss-mysql its as simple as modifying the /etc/nsswitch.conf on any machine to just point to same db server, works just fine. > You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so. > I've talked to many sys admins as well, that are all modifying the code to the kernel for a decade now on every new make buildworld, would be nice to see it mainstream. Only issue doing this I have seen so far, is having to nuke the wtmp/utx* files from /var/log on new installs to get them into new format, but that would be solved mainstream as well. I just find the benefits far outweight the cons, sure when we were all back in our computer science classes in 80s/90s it made sense. We all had accounts on the system for those 3-4 years, and generic usernames made sense, but now moving to webhosting environments and providing sftp/ssh type access to people on a larger scale, I think the email address as usernames make alot more sense now. I still teach unix at the university time to time and we still use the old putty/securecrt to sshd daemon way of learning from the command line, in that environment I find its about people forgetting passwords, take it up a notch to webhosting environment, and i find people forget their usernames to, and why I think it would be a good move... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com > Regards, > -- > -Chuck > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 00:48:30 2011 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 E6F7D1065670 for ; Wed, 9 Nov 2011 00:48:29 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id CC86B8FC1E for ; Wed, 9 Nov 2011 00:48:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp029.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LUD00BM0BKPO070@asmtp029.mac.com> for freebsd-current@freebsd.org; Tue, 08 Nov 2011 16:48:25 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-11-08_05:2011-11-08, 2011-11-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1111080283 From: Chuck Swiger In-reply-to: Date: Tue, 08 Nov 2011 16:48:24 -0800 Message-id: <66E2B668-F308-482D-BC52-7D5634CB14F1@mac.com> References: To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: MAXLOGNAME + /etc/group + chkgrp invalid character @ 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, 09 Nov 2011 00:48:30 -0000 Hi-- On Nov 8, 2011, at 4:32 PM, Dan The Man wrote: > On Tue, 8 Nov 2011, Chuck Swiger wrote: >> On Nov 8, 2011, at 3:47 PM, Dan The Man wrote: >>> In the daily cron "Daily run output" email always get the following: >>> >>> Verifying group file syntax: >>> chkgrp: /etc/group: line 3: '@' invalid character >> >> chkgrp expects group names to consist of characters in isalnum(). > > K so thats a simple fix where it does that check. usr.sbin/chkgrp/chkgrp.c, line ~117: for (cp = f[0] ; *cp ; cp++) { if (!isalnum(*cp) && *cp != '.' && *cp != '_' && *cp != '-' && (cp > f[0] || *cp != '+')) { warnx("%s: line %d: '%c' invalid character", gfn, n, *cp); e++; } } Add a "&& *cp != '@'" clause to the if statement. >>> Could we modify system to support email addresses as usernames. >> >> Sure, that's why FreeBSD comes with source code. >> You can modify anything you like. :-) >> >> However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports. You're not going to break anything allowing "@" into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are. >> >> A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users. > > Wish you would elaborate abit more here, what I have found is email addresses tend to make the best usernames, people can remember them :) > They are unique, and you solve 2 problems right away: > a) they can actually remember their username > b) they aren't having to pick through a million different taken usernames > they have to pick on their own, which is frusterating way people often do signups. If you've got a database of millions of users, you're definitely functioning in a different realm than what /etc/passwd and /etc/group were designed for. :-) Anyway, the idea is that you should be able to define multiple hierarchy levels for your identity database, which NIS+, NetInfo, Kerberos, and LDAP (kinda-sorta) can support. This lets you define an identity either at the root level, which is visible everywhere, or in subdomains from root, which means the identity is valid only within that subdomain but not in other subdomains-- and "johndoe" in one subdomain can be entirely different than "johndoe" in some other domain. (If you want "johndoe" the same everywhere, you'd define it at root instead.) That's just a bare-bones explanation, but a more complete one would likely approach book-length. :-) >> You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so. > > I've talked to many sys admins as well, that are all modifying the code to the kernel for a decade now on every new make buildworld, would be nice to see it mainstream. Sure, you can find examples or counterexamples if you look for 'em... Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:03:25 2011 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 3E4B4106566B; Wed, 9 Nov 2011 01:03:25 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4C58FC0A; Wed, 9 Nov 2011 01:03:23 +0000 (UTC) Received: by wyg36 with SMTP id 36so1540731wyg.13 for ; Tue, 08 Nov 2011 17:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ArcCqKsZvSxr/oVxnoHwhAZyhINMncdXVEBPWhnLhSQ=; b=CKwq7bFdIps8n38e8D0U9Qj1yjW+4gEF9JdEbTkT/57KWZLEJ18jN1Iqn6zW9iLZKa NMAz66k/bMV4bLqkCByWwe7iRM7xhtdaAwKGNQVACrEWO6A7G3p1BdtL1qKxoj7OBDcj 12zRyd613eQ8U3gzHXK+OjjtflklveUgd2No8= MIME-Version: 1.0 Received: by 10.180.89.5 with SMTP id bk5mr149710wib.60.1320800602964; Tue, 08 Nov 2011 17:03:22 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 17:03:22 -0800 (PST) In-Reply-To: <4EB9C469.9070208@freebsd.org> References: <4EB9C469.9070208@freebsd.org> Date: Tue, 8 Nov 2011 20:03:22 -0500 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , Attilio Rao , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 01:03:25 -0000 Hi, On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer wrote: > On 11/8/11 10:49 AM, Arnaud Lacombe wrote: >> >> Hi, >> To avoid future complaints about the fact that I would be only "talk" >> without "action", I did implement what I suggested above. As it is >> quite a large patch-set, I will not post it directly here, however, it >> is available on github: >> >> https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug >> >> It convert a bunch of debug interface to use the caller instruction >> pointer, as well as a proof-of-concept teaching printf(9) to convert >> IP to symbol_name+offset. >> >> It translates in a direct saving of about +250kB on i386's GENERIC, >> just in kernel text size. Even the worst case, ie LOCK_DEBUG =3D=3D 0, >> translates to a save of +80kB. >> >> Please note that this is still WIP code. > > A couple of comments. > Firstly, the idea of a printf method to print the IP as symbol+offset is = an > interesting idea > that should be followed up in its own right. > > However, (comment 2) =A0I would much rather file+line in this case. > I don't want to have the tools to decode the offset into a location in > sources. > this already exists and is called "debug symbols" - Arnaud > We have both systems in operation art work and I far prefer the latter. > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:09:51 2011 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 E13E71065674; Wed, 9 Nov 2011 01:09:51 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 188438FC0A; Wed, 9 Nov 2011 01:09:50 +0000 (UTC) Received: by wyg36 with SMTP id 36so1545641wyg.13 for ; Tue, 08 Nov 2011 17:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y805aaeyJH6ng0OJ+OqaLwirMzODHxaYByQOSdEQTUY=; b=W5J5eHg4kzkBVRB5MNkv7N88uceUycZQKhAzekTZA8zje35IH3/72OwrylI1GQjD9m 9OA2ZkMoxi9RlVqkDj5nA0JSuVIT1LgGUhzFwfIOgcWq3EMyFR+DZoGYIBhpRRl1yYpK mOFmdYJCCm3AETit4y2l1TvMIHdbrh0POB/JI= MIME-Version: 1.0 Received: by 10.180.101.97 with SMTP id ff1mr213593wib.42.1320800990008; Tue, 08 Nov 2011 17:09:50 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 17:09:49 -0800 (PST) In-Reply-To: <4EB9975F.4090601@FreeBSD.org> References: <4EB9975F.4090601@FreeBSD.org> Date: Tue, 8 Nov 2011 20:09:49 -0500 Message-ID: From: Arnaud Lacombe To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 01:09:52 -0000 Hi, On Tue, Nov 8, 2011 at 3:55 PM, Andriy Gapon wrote: > > [cc list trimmed] > > on 08/11/2011 22:34 Attilio Rao said the following: >> 2011/11/8 Arnaud Lacombe : >>> To avoid future complaints about the fact that I would be only "talk" >>> without "action", I did implement what I suggested above. As it is >>> quite a large patch-set, I will not post it directly here, however, it >>> is available on github: >> >> I really think that this is way too dependent by the good health of >> your tool, thus that is highly fragile. >> >> However, you may have more luck by just the core of your kernel >> changes here, for comment and leave alone all the (ptr -> >> LOCK_FILE/LOCK_LINE conversion). >> >> Said that, I think this logic is too fragile and likely won't be as >> effective as __FILE__/__LINE__ in many cases. > > I agree. > If we were able to somehow automatically, magically, easily and correctly > determine an instruction pointer of a caller, then it would make sense to ditch > explicit passing of __FILE__/__LINE__ arguments in favor of doing instruction > pointer decoding. > again, no need for magic, this already exists, as the form of gcc[0]'s __builtin_return_address(0). > But if we are just replacing explicit passing of (well-known) macros > __FILE__/__LINE__ with explicit passing of THIS_IP, then I don't see a point. > make sense too, but you need to be sure stuff between the caller and callee is fully inlined. > Apologies if I missed the rationale for this change. > mostly getting rid of all the __FILE__ and __LINE__ bloat. - Arnaud [0]: check about LLVM support is left to the reader. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:22:11 2011 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 7DBB3106566C; Wed, 9 Nov 2011 01:22:11 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8162A8FC17; Wed, 9 Nov 2011 01:22:10 +0000 (UTC) Received: by wwp14 with SMTP id 14so1619910wwp.31 for ; Tue, 08 Nov 2011 17:22:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ld2qxC2XlA9DfhdLFBzXx+Wo7TRsPgZeMyaOUDooDJk=; b=sQojBZwhshk3cuYWmoTOfA51XO2dKBU5AbKzWliw/K8v9mHc7LBwIjlNqP5fG7FQWb zPUSdCU6LkpuWFAKT22PP1xe01LhfGsDAsIrCPG5KrYBXZV/6jx3tlycwS4aGh/tjfO9 EwMrFPGf7vB9s7l4BLigPhPuqc9hyXu881748= MIME-Version: 1.0 Received: by 10.180.3.71 with SMTP id a7mr358104wia.0.1320801729267; Tue, 08 Nov 2011 17:22:09 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 17:22:09 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 20:22:09 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 01:22:11 -0000 Hi, On Tue, Nov 8, 2011 at 3:34 PM, Attilio Rao wrote: > 2011/11/8 Arnaud Lacombe : >> Hi, >> >> On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe wrot= e: >>> On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao wrote= : >>>> 2011/11/7 Arnaud Lacombe : >>>>> Hi, >>>>> >>>>> On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov wrote: >>>>>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>>>>> >>>>>> Below is the KBI patch after vm_page_bits_t merge is done. >>>>>> Again, I did not spent time converting all in-tree consumers >>>>>> from the (potentially) loadable modules to the new KPI until it >>>>>> is agreed upon. >>>>>> >>>>>> diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c >>>>>> index 305c189..7264cd1 100644 >>>>>> --- a/sys/nfsclient/nfs_bio.c >>>>>> +++ b/sys/nfsclient/nfs_bio.c >>>>>> @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) >>>>>> =A0 =A0 =A0 =A0 * can only occur at the file EOF. >>>>>> =A0 =A0 =A0 =A0 */ >>>>>> =A0 =A0 =A0 =A0VM_OBJECT_LOCK(object); >>>>>> - =A0 =A0 =A0 if (pages[ap->a_reqpage]->valid !=3D 0) { >>>>>> + =A0 =A0 =A0 if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D 0) { >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < npages; ++i) { >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (i !=3D ap->a_reqp= age) { >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_pa= ge_lock(pages[i]); >>>>>> @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation fil= led an entire page >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D VM_PAGE_B= ITS_ALL; >>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D= =3D 0, >>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m,= VM_PAGE_BITS_ALL); >>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_d= irty(m) =3D=3D 0, >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpage= s: page %p is dirty", m)); >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (size > toff) { >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation fil= led a partial page. >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D 0; >>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m,= 0); >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_set_valid(m, = 0, size - toff); >>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D= =3D 0, >>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_d= irty(m) =3D=3D 0, >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpage= s: page %p is dirty", m)); >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >>>>>> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >>>>>> index 389aea5..2f41e70 100644 >>>>>> --- a/sys/vm/vm_page.c >>>>>> +++ b/sys/vm/vm_page.c >>>>>> @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_dirty(m); >>>>>> =A0} >>>>>> >>>>>> +void >>>>>> +vm_page_lock_func(vm_page_t m, const char *file, int line) >>>>>> +{ >>>>>> + >>>>>> +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >>>>>> + =A0 =A0 =A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); >>>>>> +#else >>>>>> + =A0 =A0 =A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); >>>>>> +#endif >>>>>> +} >>>>>> + >>>>> Why do you re-implement the wheel ? all the point of these assessors >>>>> is to hide implementation detail. IMO, you should restrict yourself t= o >>>>> the documented API from mutex(9), only. >>>>> >>>>> Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but >>>>> wait LOCK_FILE is either just __FILE__, or NULL, depending on >>>>> LOCK_DEBUG, but you wouldn't have those function without >>>>> INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely >>>>> fracked-up... If you don't want this code in INVARIANTS, but in >>>>> LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. >>>>> >>>>> Btw, let me also question the use of non-inline functions. >>>> >>>> My impression is that you don't really understand the patch, thus your >>>> disrespectful words used here are really unjustified. >>>> >>> Well, unfortunately, I wasn't around to comment 10 years ago when this = got in. >>> >>>> I think that kib@ intention is just to get "the most official way" to >>>> pass down file and line to locking functions from the consumers. >>>> His patch is "technically right", but I would prefer something >>>> different (see below). >>>> >>> Yes, and that's not an excuse to use the _internal_ implementation >>> details of mutex(9), and not the exposed API. This is especially true >>> when applied to someone so eager to follow "standards". >>> >>>> LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata >>>> section. Without INVARIANTS/WITNESS/etc. they will just be NULL and >>>> not pointing to a lot of datas that won't be used in the opposite >>>> case. >>>> >>> You comment just as if __FILE__ and __LINE__ were mandatory in a debug >>> interface. This is _not_ true. __FILE__ and __LINE__ are just hideous >>> for debugging of anything but early alpha code. LOCK_FILE and >>> LOCK_LINE are a bad answer to a bad interface. Even if you just pass >>> NULL and 0 as argument, you've got the bloat of passing unused >>> argument. You might as well just pass a single argument that would do >>> the exact same job and be _always_ available, eg. the IP of the >>> caller, or the first return address. KDB magic still let you translate >>> to something humanly understandable. If the toolchain does not support >>> the feature on all supported platform, well, fix the toolchain. >>> >> To avoid future complaints about the fact that I would be only "talk" >> without "action", I did implement what I suggested above. As it is >> quite a large patch-set, I will not post it directly here, however, it >> is available on github: > > I really think that this is way too dependent by the good health of > your tool, thus that is highly fragile. > then fix the tools to be more robust. > However, you may have more luck by just the core of your kernel > changes here, for comment and leave alone all the (ptr -> > LOCK_FILE/LOCK_LINE conversion). > > Said that, I think this logic is too fragile and likely won't be as > effective as __FILE__/__LINE__ in many cases. > Let point out a contradiction; if __FILE__/__LINE__ are so robust, and if tools to inspect kernel are so broken and fragile, why don't you make ddb/kdb reports those locations, by default, instead of symbol+offset when it displays a backtrace ? - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:28:26 2011 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 2FCC9106564A for ; Wed, 9 Nov 2011 01:28:26 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 00CC68FC16 for ; Wed, 9 Nov 2011 01:28:26 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 8A2D0119C75; Tue, 8 Nov 2011 19:28:25 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320802105; bh=aCb1995WxaniUtSbW+bIVZ3CN7OFk1VxDz/wEOCZidQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=R6fPk/iA/ZpwG6NChG6wuwZtJ+Tinx7BamIzM4Ja+8Ni4bitErGzuZvdEAblKuQZJ 5jPXd8wXknZoZiC2vr9HAMzDJbDFpDdTGPDbgORq1RBLweOgKKT7H5f59BQC7klw4J XRi1jW7kG0uR3x9WZ3CpY4dooTIWew8Cv34Jd7gw= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 843F1119C6F; Tue, 8 Nov 2011 19:28:25 -0600 (CST) Date: Tue, 8 Nov 2011 19:28:25 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: <66E2B668-F308-482D-BC52-7D5634CB14F1@mac.com> Message-ID: References: <66E2B668-F308-482D-BC52-7D5634CB14F1@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: MAXLOGNAME + /etc/group + chkgrp invalid character @ 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, 09 Nov 2011 01:28:26 -0000 On Tue, 8 Nov 2011, Chuck Swiger wrote: > Hi-- > > On Nov 8, 2011, at 4:32 PM, Dan The Man wrote: >> On Tue, 8 Nov 2011, Chuck Swiger wrote: >>> On Nov 8, 2011, at 3:47 PM, Dan The Man wrote: >>>> In the daily cron "Daily run output" email always get the following: >>>> >>>> Verifying group file syntax: >>>> chkgrp: /etc/group: line 3: '@' invalid character >>> >>> chkgrp expects group names to consist of characters in isalnum(). >> >> K so thats a simple fix where it does that check. > > usr.sbin/chkgrp/chkgrp.c, line ~117: > > for (cp = f[0] ; *cp ; cp++) { > if (!isalnum(*cp) && *cp != '.' && *cp != '_' && *cp != '-' && > (cp > f[0] || *cp != '+')) { > warnx("%s: line %d: '%c' invalid character", gfn, n, *cp); > e++; > } > } > > Add a "&& *cp != '@'" clause to the if statement. It doesn't bother me enough to have to modify the if statement on every new buildworld(which I seem to be doing alot of lately), honestly that one email login in the group file is only email login that will ever touch an /etc file, rest is in database. I wouldn't personally add any email type logins to a base system directly. > >>>> Could we modify system to support email addresses as usernames. >>> >>> Sure, that's why FreeBSD comes with source code. >>> You can modify anything you like. :-) >>> >>> However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports. You're not going to break anything allowing "@" into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are. >>> >>> A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users. >> >> Wish you would elaborate abit more here, what I have found is email addresses tend to make the best usernames, people can remember them :) >> They are unique, and you solve 2 problems right away: >> a) they can actually remember their username >> b) they aren't having to pick through a million different taken usernames >> they have to pick on their own, which is frusterating way people often do signups. > > If you've got a database of millions of users, you're definitely functioning in a different realm than what /etc/passwd and /etc/group were designed for. :-) > Well thats the idea right, unlimited growth but a central place to store everything for scalability purposes. Of course if you actually tried to login 1 million people to same machine, I am sure you would kill the I/O instantly :) Basically approach I've been taking is central database that stores all users, any machine can be configured to not allow logins from anyone in database by just removing them from /etc/nsswitch.conf. You can control which of those million users can login to a certain machine by simply modifying the select statement to the database in the nss-database config file...all in all these changes take 2 seconds to change and makes things quite easy. > Anyway, the idea is that you should be able to define multiple hierarchy levels for your identity database, which NIS+, NetInfo, Kerberos, and LDAP (kinda-sorta) can support. This lets you define an identity either at the root level, which is visible everywhere, or in subdomains from root, which means the identity is valid only within that subdomain but not in other subdomains-- and "johndoe" in one subdomain can be entirely different than "johndoe" in some other domain. (If you want "johndoe" the same everywhere, you'd define it at root instead.) > > That's just a bare-bones explanation, but a more complete one would likely approach book-length. :-) I'm sure it would make an interesting read, I try not to concern myself to much with mechanisms that would likely to take to long to respond if there were millions of users, working directly with mysql/postgres/oracle from getgo i think is safe. Think its almost like an analogy to where you started off building your network code using something simple like select() then you kicked yourself in the ass after for not having used epoll() on linux or kqueue() on freebsd in an eventloop as your application got to many connections. I do like your idea in a small office type setting though, definately wouldn't mind trying something like that here at home so I had a central way for all these development machines I got lieing around to have some central login place. Found this an interesting read last night: http://www.mrp3.com/windows-to-unix-samba.html might be abit dated... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com > >>> You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so. >> >> I've talked to many sys admins as well, that are all modifying the code to the kernel for a decade now on every new make buildworld, would be nice to see it mainstream. > > Sure, you can find examples or counterexamples if you look for 'em... > > Regards, > -- > -Chuck > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:43:42 2011 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 2769C106566C; Wed, 9 Nov 2011 01:43:42 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 61A388FC18; Wed, 9 Nov 2011 01:43:40 +0000 (UTC) Received: by wyg36 with SMTP id 36so1569383wyg.13 for ; Tue, 08 Nov 2011 17:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gDz+80GCvP7wIuybc4ThonUxUNebvymi/GA7U2VnEMI=; b=Xw6t9/IQz8wmhHQneD20i09Xt4ps5slnelWqzBulJOc36JJr4jt7HTndouhcH2027f L7tMM2EniVwYrMVsJceJXM+RDSMu80v0ejYLkV/s8FJ4uYDhEwlhKuKBK8cqxt7ebbIz uNClK1+IwsMDGxU2fNXbI6cro5Lvw/c9Rq/J4= MIME-Version: 1.0 Received: by 10.180.106.104 with SMTP id gt8mr395775wib.6.1320803020041; Tue, 08 Nov 2011 17:43:40 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 17:43:40 -0800 (PST) In-Reply-To: References: <4EB9975F.4090601@FreeBSD.org> Date: Tue, 8 Nov 2011 20:43:40 -0500 Message-ID: From: Arnaud Lacombe To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 01:43:42 -0000 Hi, On Tue, Nov 8, 2011 at 8:09 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Nov 8, 2011 at 3:55 PM, Andriy Gapon wrote: >> >> [cc list trimmed] >> >> on 08/11/2011 22:34 Attilio Rao said the following: >>> 2011/11/8 Arnaud Lacombe : >>>> To avoid future complaints about the fact that I would be only "talk" >>>> without "action", I did implement what I suggested above. As it is >>>> quite a large patch-set, I will not post it directly here, however, it >>>> is available on github: >>> >>> I really think that this is way too dependent by the good health of >>> your tool, thus that is highly fragile. >>> >>> However, you may have more luck by just the core of your kernel >>> changes here, for comment and leave alone all the (ptr -> >>> LOCK_FILE/LOCK_LINE conversion). >>> >>> Said that, I think this logic is too fragile and likely won't be as >>> effective as __FILE__/__LINE__ in many cases. >> >> I agree. >> If we were able to somehow automatically, magically, easily and correctly >> determine an instruction pointer of a caller, then it would make sense to ditch >> explicit passing of __FILE__/__LINE__ arguments in favor of doing instruction >> pointer decoding. >> > again, no need for magic, this already exists, as the form of gcc[0]'s > __builtin_return_address(0). > actually, this should be __builtin_return_address(1). - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:51:42 2011 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 E9D11106566C for ; Wed, 9 Nov 2011 01:51:42 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82CBA8FC0A for ; Wed, 9 Nov 2011 01:51:42 +0000 (UTC) Received: by wyg36 with SMTP id 36so1574945wyg.13 for ; Tue, 08 Nov 2011 17:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YwfV5Lwjr5KrVHXLvRzkQSAGjs67Hhxniq+n1OjuiPY=; b=QyYhfDv820bqnkmYdc52iAGqDn+njlywN4USe81lmw0hUBgKYrW8JRHBYP80iF07gw FuZTGnDWaw6WjBfnzmr4AmZX9/7w5y4uJuzr76x1bMRhmDTQwCnyEVIXrOO84NsklLjx TM20tOJuPjPfKX2RcYjwJwFJaslHo7Cvze1VY= MIME-Version: 1.0 Received: by 10.180.7.97 with SMTP id i1mr368604wia.23.1320803501282; Tue, 08 Nov 2011 17:51:41 -0800 (PST) Received: by 10.180.8.34 with HTTP; Tue, 8 Nov 2011 17:51:41 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 20:51:41 -0500 Message-ID: From: Ryan Stone To: Paul Ambrose Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: Re: config(8) does not add post-processing for source file with compile-with command in sys/conf/files 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, 09 Nov 2011 01:51:43 -0000 On Tue, Oct 18, 2011 at 10:21 PM, Paul Ambrose wrote: > when I digged the a PR(bin/160275), I found in_proto.c and > if_ethersubr.c ( see sys/conf/files ) does not get > ${NORMAL_CTFCONVERT} post-processing in Makefile > (/usr/obj/usr/src/sys/MYKERNEL/Makefile) generated by config(8), so > the objs does not contain ctf section Here's a second attempt at this one. I think that this version is much cleaner than the other options in this thread. If it survives a make universe I intend to commit this: Index: usr.sbin/config/mkmakefile.c =================================================================== --- usr.sbin/config/mkmakefile.c (revision 227341) +++ usr.sbin/config/mkmakefile.c (working copy) @@ -762,16 +762,21 @@ break; } snprintf(cmd, sizeof(cmd), - "${%s_%c%s}\n\t@${NORMAL_CTFCONVERT}", ftype, + "${%s_%c%s}\n", ftype, toupper(och), ftp->f_flags & NOWERROR ? "_NOWERROR" : ""); compilewith = cmd; } *cp = och; if (strlen(ftp->f_objprefix)) - fprintf(f, "\t%s $S/%s\n\n", compilewith, np); + fprintf(f, "\t%s $S/%s\n", compilewith, np); else - fprintf(f, "\t%s\n\n", compilewith); + fprintf(f, "\t%s\n", compilewith); + + if (!(ftp->f_flags & NO_OBJ)) + fprintf(f, "\t@${NORMAL_CTFCONVERT}\n\n"); + else + fprintf(f, "\n"); } } From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:52:39 2011 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 235F51065673; Wed, 9 Nov 2011 01:52:39 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9B58FC0C; Wed, 9 Nov 2011 01:52:35 +0000 (UTC) Received: by wwp14 with SMTP id 14so1642225wwp.31 for ; Tue, 08 Nov 2011 17:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3s+4hi+bg1FtoA2JPsNe5UTbWVWoVv9ISf6+R5Dj+kk=; b=Gfb6Yjw1vbmXharkbArzbP6DlBZ3k8ONAhEYqgPlov3HPTe6sDxCc1hmRgxIJt/RqL dE2yzTR4jspBUZ2sXeI9qs9f6BKBHqdwaqMsS+/5YW1n2GTDCF9H1gSPgEhkJmE6vuOW +VAzV1jdjpwM/WG6KjLaQruAKAiffZ/2B9H3Q= MIME-Version: 1.0 Received: by 10.180.102.4 with SMTP id fk4mr396965wib.15.1320803554204; Tue, 08 Nov 2011 17:52:34 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 17:52:34 -0800 (PST) In-Reply-To: <4EB9C469.9070208@freebsd.org> References: <4EB9C469.9070208@freebsd.org> Date: Tue, 8 Nov 2011 20:52:34 -0500 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 01:52:39 -0000 Hi, On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer wrote: > On 11/8/11 10:49 AM, Arnaud Lacombe wrote: >> >> Hi, >> To avoid future complaints about the fact that I would be only "talk" >> without "action", I did implement what I suggested above. As it is >> quite a large patch-set, I will not post it directly here, however, it >> is available on github: >> >> https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug >> >> It convert a bunch of debug interface to use the caller instruction >> pointer, as well as a proof-of-concept teaching printf(9) to convert >> IP to symbol_name+offset. >> >> It translates in a direct saving of about +250kB on i386's GENERIC, >> just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, >> translates to a save of +80kB. >> >> Please note that this is still WIP code. > > A couple of comments. > Firstly, the idea of a printf method to print the IP as symbol+offset is an > interesting idea > that should be followed up in its own right. > FWIW, I have no credit in this idea. It has been in Linux for ages and ages. That said, IP address are barely used in FreeBSD, there is no legacy. As such, the API should not use `unsigned long' but `void *'[0]; this is the natural type returned by `__builtin_return_address()' and the `&&' operator. This would allow to introduce a modifier to `%p' to do the translation. - Arnaud ps: netgraph is on my target list, as well as the list code, to some extend :) [0]: as I really hate `caddr_t' From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 02:16:30 2011 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 C4558106566B for ; Wed, 9 Nov 2011 02:16:30 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7731F8FC13 for ; Wed, 9 Nov 2011 02:16:30 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 04DF2119C75; Tue, 8 Nov 2011 20:16:29 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1320804990; bh=6p0bAEmSF7kIH28vnBsGahfztzzyk0H1kw9aKeiLdFg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=HDYdlY/H3lqW68olvWaBmHPAcIaD5jo+E85hNKX5BEWEY71vzcb2nq3GB0cj42T44 obONlErvjBg97gpEfXghHjC5Hw0D/Ox1qn1tMwOhDYda2/50mDYGCmBW22zDyOtfJw XWwV5tzutjE6nUqm28tNz5huWxrUsN3b1EJYcfiQ= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id EFD80119C6B; Tue, 8 Nov 2011 20:16:29 -0600 (CST) Date: Tue, 8 Nov 2011 20:16:29 -0600 (CST) From: Dan The Man To: Kurt Touet In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2338054437-237842630-1320804989=:93923" Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: samba+zfs 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, 09 Nov 2011 02:16:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2338054437-237842630-1320804989=:93923 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 8 Nov 2011, Kurt Touet wrote: > On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man wrote: >> >> >> Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: >> asterisk:~# uname -a >> FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 >> 19:46:53 CDT 2011 droot@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL >>  amd64 >> asterisk:~# >> >> >> >> Dan. >> >> >> -- >> Dan The Man >> CTO/ Senior System Administrator >> Websites, Domains and Everything else >> http://www.SunSaturn.com >> Email: Dan@SunSaturn.com >> >> On Tue, 8 Nov 2011, Dan The Man wrote: >> >>> >>> Ok here is some specs: this been running fine on 8.2 stable and i was sure >>> it was running fine on RC1 as well. I did some testing against samba 34 35 >>> and 36 in the ports collection all with the same slow write problems. >>> >>> I did further testing mounting drive in question with NFS and it did not >>> suffer the same problem, so it seems just samba related here, where samba >>> would actually outperform my NFS mount before, now its taking 10x as long >>> to write anything. >>> >>> This is really most simplistic setup I have, all I want to do is map a >>> network drive at the house read/write so my laptop, desktop etc all have >>> access to it. I have played with all the smb.conf options, and can't seem >>> to find where the issue is, further research suggests others are >>> experiencing same problems with beta3 from following forum post: >>> >>> http://forums.freebsd.org/showthread.php?t=27300 >>> >>> Hardware this is running on: I beleive a 4 year old amd chip and board, >>> with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as >>> UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap >>> hitachi drives for my storage space,which is mirrored nightly with rsync >>> with another duplicate machine(cause I know someone is going to say why not >>> use raid5-raidz) >>> >>> Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 >>> addresses to he.net. >>> >>> I've played with nearly every option in smb.conf disabling, enabling etc >>> and can't seem to find the issue: here are my current config file settings >>> on machine that could apply to samba: >>> >>> asterisk:~# cat /boot/loader.conf >>> autoboot_delay="5" >>> accf_data_load="YES" >>> aio_load="YES" >>> zfs_load="YES" >>> kern.maxbcache=64M >>> kern.ipc.maxpipekva=4M >>> >>> vfs.zfs.prefetch_disable=1 >>> vm.kmem_size="1844M" >>> vfs.zfs.arc_min="1024M" >>> vfs.zfs.arc_max="1536M" >>> vfs.zfs.vdev.min_pending=2 >>> vfs.zfs.vdev.max_pending=8 >>> vfs.zfs.txg.timeout=5 >>> vfs.zfs.zil_disable="1" >>> ahci_load="YES" >>> asterisk:~# >>> >>> asterisk:~# cat /usr/local/etc/smb.conf >>> # Global parameters >>> [global] >>>       workgroup = HOME >>>       netbios name = ASTERISK >>>       server string = "Primary backups" >>>       interfaces = sk0 >>>       #smb ports = 139 >>>       #security = USER >>>       security = SHARE >>>       encrypt passwords = Yes >>>       #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 >>>       domain master = no >>>       wins support = yes >>>       guest account = root >>>       socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY >>>       use sendfile = no >>>       level2 oplocks = True >>>       read raw = no >>>       write cache size = 262144 >>>       min receivefile size = 16384 >>>       aio read size = 16384 >>>       aio write size = 16384 >>>       aio write behind = yes >>>       dns proxy = no >>>       max log size = 50 >>>       #log file = /dev/null >>>       log file = /var/log/samba.log >>>       debug level = 1 >>>       syslog = 0 >>> >>> [data] >>>       comment = "Primary backups" >>>       path = /data/public >>>       read only = No >>>       guest ok = Yes >>>       valid users = root >>> asterisk:~# asterisk:~# cat /etc/sysctl.conf >>> # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith >>> Exp $ >>> # >>> #  This file is read when going to multi-user and its contents piped thru >>> #  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details. >>> # >>> >>> # Uncomment this to prevent users from seeing information about processes >>> that >>> # are being run under another UID. >>> #security.bsd.see_other_uids=0 >>> >>> #raise file descriptors on the system >>> kern.maxfiles=204916 >>> kern.maxfilesperproc=204916 >>> >>> #raise sockets we can accept >>> kern.ipc.somaxconn=32768 >>> >>> #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html >>> kern.ipc.maxsockbuf=16777216 >>> net.inet.tcp.rfc1323=1 >>> net.inet.tcp.sendbuf_max=16777216 >>> net.inet.tcp.recvbuf_max=16777216 >>> net.inet.tcp.sendspace=65536 >>> net.inet.tcp.recvspace=131072 >>> >>> #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations >>> net.inet.icmp.icmplim=500 >>> kern.ipc.nmbjumbop=192000 >>> kern.ipc.nmbclusters=229376 >>> kern.ipc.maxsockets=204800 >>> net.inet.tcp.maxtcptw=163840 >>> #also add following to /boot/loader.conf >>> #vm.kmem_size=1844M >>> #kern.maxbcache=64M >>> #kern.ipc.maxpipekva=4M >>> >>> #default setting of net.inet.ip.portrange.first is to low, causing us >>> problems with bind >>> net.inet.ip.portrange.last=65535 >>> net.inet.ip.portrange.first=1024 >>> >>> #DOS protection >>> net.inet.tcp.msl=7500 >>> net.inet.tcp.blackhole=2 >>> net.inet.udp.blackhole=1 >>> net.inet.icmp.icmplim=50 >>> net.inet.ip.accept_sourceroute=0 >>> net.inet.ip.sourceroute=0 >>> >>> #some stuff for samba >>> kern.ipc.nmbclusters=32768 >>> kern.maxvnodes=800000 >>> net.inet.tcp.delayed_ack=0 >>> net.inet.tcp.inflight.enable=0 >>> net.inet.tcp.path_mtu_discovery=0 >>> net.inet.tcp.recvbuf_auto=1 >>> net.inet.tcp.recvbuf_inc=524288 >>> net.inet.tcp.sendbuf_auto=1 >>> net.inet.tcp.sendbuf_inc=524288 >>> net.inet.udp.maxdgram=57344 >>> net.inet.udp.recvspace=65535 >>> net.local.stream.recvspace=65535 >>> net.local.stream.sendspace=65535 >>> net.inet.tcp.mssdflt=1460 >>> >>> #IPSEC >>> net.inet.ip.forwarding=1 >>> net.inet6.ip6.forwarding=1 >>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules >>> >>> >>> #NFS--not concerned with data integrity when playing mostly already stored >>> movies >>> vfs.nfsrv.async=1 >>> >>> #JAIL >>> #i like to use ping etc inside jail! >>> security.jail.allow_raw_sockets=1 >>> asterisk:~# >>> >>> >>> Here are logs of me trying to mux a DTS mkv file from samba.log on debug >>> level 10, I get the following over and over again: >>> >>> [2011/11/08 03:24:00.067974, 10] ../lib/util/util.c:415(dump_data) >>> [2011/11/08 03:24:00.067981,  3] smbd/process.c:1466(switch_message) >>>  switch message SMBwriteX (pid 64308) conn 0x805008450 >>> [2011/11/08 03:24:00.067990,  4] smbd/uid.c:345(change_to_user) >>>  Skipping user change - already user >>> [2011/11/08 03:24:00.068001, 10] >>> locking/locking.c:120(strict_lock_default) >>>  is_locked: optimisation - exclusive oplock on file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.068010, 10] >>> locking/locking.c:162(strict_lock_default) >>>  strict_lock_default: flavour = WINDOWS_LOCK brl start=83431665 len=65536 >>> unlocked for fnum 49966 file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.068021, 10] lib/recvfile.c:65(default_sys_recvfile) >>>  default_sys_recvfile: from = 33, to = 39, offset=83431665, count = 65536 >>> [2011/11/08 03:24:00.068995, 10] smbd/fileio.c:143(real_write_file) >>>  real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>> (1).mkv): pos = 83431665, size = 65536, returned 65536 >>> [2011/11/08 03:24:00.069013,  3] smbd/reply.c:4639(reply_write_and_X) >>>  writeX fnum=49966 num=65536 wrote=65536 >>> [2011/11/08 03:24:00.069038, 10] >>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>  got smb length of 65600 >>> [2011/11/08 03:24:00.069052, 10] smbd/reply.c:4459(is_valid_writeX_buffer) >>>  is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 >>> [2011/11/08 03:24:00.069062,  6] smbd/process.c:1659(process_smb) >>>  got message type 0x0 of len 0x3f >>> [2011/11/08 03:24:00.069072,  3] smbd/process.c:1661(process_smb) >>>  Transaction 15398 of length 67 (65536 toread) >>> [2011/11/08 03:24:00.069081,  5] lib/util.c:332(show_msg) >>> [2011/11/08 03:24:00.069087,  5] lib/util.c:342(show_msg) >>>  size=63 >>>  smb_com=0x2f >>>  smb_rcls=0 >>>  smb_reh=0 >>>  smb_err=0 >>>  smb_flg=24 >>>  smb_flg2=51207 >>>  smb_tid=1 >>>  smb_pid=65279 >>>  smb_uid=0 >>>  smb_mid=36032 >>>  smt_wct=14 >>>  smb_vwv[ 0]=  255 (0xFF) >>>  smb_vwv[ 1]=57054 (0xDEDE) >>>  smb_vwv[ 2]=49966 (0xC32E) >>>  smb_vwv[ 3]= 4337 (0x10F1) >>>  smb_vwv[ 4]= 1274 (0x4FA) >>>  smb_vwv[ 5]=65535 (0xFFFF) >>>  smb_vwv[ 6]=65535 (0xFFFF) >>>  smb_vwv[ 7]=    0 (0x0) >>>  smb_vwv[ 8]=    0 (0x0) >>>  smb_vwv[ 9]=    1 (0x1) >>>  smb_vwv[10]=    0 (0x0) >>>  smb_vwv[11]=   64 (0x40) >>>  smb_vwv[12]=    0 (0x0) >>>  smb_vwv[13]=    0 (0x0) >>>  smb_bcc=0 >>> [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) >>> [2011/11/08 03:24:00.069170,  3] smbd/process.c:1466(switch_message) >>>  switch message SMBwriteX (pid 64308) conn 0x805008450 >>> [2011/11/08 03:24:00.069179,  4] smbd/uid.c:345(change_to_user) >>>  Skipping user change - already user >>> [2011/11/08 03:24:00.069188, 10] >>> locking/locking.c:120(strict_lock_default) >>>  is_locked: optimisation - exclusive oplock on file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.069197, 10] >>> locking/locking.c:162(strict_lock_default) >>>  strict_lock_default: flavour = WINDOWS_LOCK brl start=83497201 len=65536 >>> unlocked for fnum 49966 file >>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>> [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfile) >>>  default_sys_recvfile: from = 33, to = 39, offset=83497201, count = 65536 >>> [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) >>>  real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>> (1).mkv): pos = 83497201, size = 65536, returned 65536 >>> [2011/11/08 03:24:00.070004,  3] smbd/reply.c:4639(reply_write_and_X) >>>  writeX fnum=49966 num=65536 wrote=65536 >>> [2011/11/08 03:24:00.070030, 10] >>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>  got smb length of 65600 >>> [2011/11/08 03:24:00.070044, 10] smbd/reply.c:4459(is_valid_writeX_buffer) >>>  is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 >>> [2011/11/08 03:24:00.070053,  6] smbd/process.c:1659(process_smb) >>>  got message type 0x0 of len 0x3f >>> [2011/11/08 03:24:00.070063,  3] smbd/process.c:1661(process_smb) >>>  Transaction 15399 of length 67 (65536 toread) >>> [2011/11/08 03:24:00.070072,  5] lib/util.c:332(show_msg) >>> [2011/11/08 03:24:00.070077,  5] lib/util.c:342(show_msg) >>>  size=63 >>>  smb_com=0x2f >>>  smb_rcls=0 >>>  smb_reh=0 >>>  smb_err=0 >>>  smb_flg=24 >>>  smb_flg2=51207 >>>  smb_tid=1 >>>  smb_pid=65279 >>>  smb_uid=0 >>>  smb_mid=36102 >>>  smt_wct=14 >>>  smb_vwv[ 0]=  255 (0xFF) >>>  smb_vwv[ 1]=57054 (0xDEDE) >>>  smb_vwv[ 2]=49966 (0xC32E) >>>  smb_vwv[ 3]= 4337 (0x10F1) >>>  smb_vwv[ 4]= 1275 (0x4FB) >>>  smb_vwv[ 5]=65535 (0xFFFF) >>>  smb_vwv[ 6]=65535 (0xFFFF) >>>  smb_vwv[ 7]=    0 (0x0) >>>  smb_vwv[ 8]=    0 (0x0) >>>  smb_vwv[ 9]=    1 (0x1) >>>  smb_vwv[10]=    0 (0x0) >>>  smb_vwv[11]=   64 (0x40) >>>  smb_vwv[12]=    0 (0x0) >>>  smb_vwv[13]=    0 (0x0) >>>  smb_bcc=0 >>> >>> >>> Hopefully maybe someone can shine some light on this.... >>> >>> >>> Dan. >>> >>> >>> -- >>> Dan The Man >>> CTO/ Senior System Administrator >>> Websites, Domains and Everything else >>> http://www.SunSaturn.com >>> Email: Dan@SunSaturn.com >>> >>> On Fri, 28 Oct 2011, Garrett Cooper wrote: >>> >>>> On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote: >>>>> >>>>> >>>>> Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs >>>>> its taking over an hour to just mux in things like DTS english, where it >>>>> was >>>>> 15 minutes on beta3. >>>> >>>> Hi Dan, >>>> - Can you do more deterministic / scientific benchmarks? >>>> - Did you upgrade Samba? >>>> - What is your system's operating hardware profile? >>>> Thanks! >>>> -Garrett >>>> > > I had noticed a similar problem with doing large writes from my > windows workstation to my freebsd ZFS array. Previously I had been > able to write at around 30MB/s (limited by a slow SATA controller), > and those speeds had dropped to 3-5MB/s with long pauses between > writes to the array (monitoring with zpool iostat). However, I just > updated to stable/9 r227357 and the issue seems to have gone away; I'm > back up to 30MB/s writes. > > Hope you find the same sort of thing, > -kurt > Yep your right, on RC2 my samba ZFS write speeds are back. Thanks for heads up Kurt. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com --2338054437-237842630-1320804989=:93923-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 02:22:42 2011 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 83D13106564A; Wed, 9 Nov 2011 02:22:42 +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 59E818FC14; Wed, 9 Nov 2011 02:22:39 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA92MVVZ022642 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Nov 2011 18:22:32 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EB9E3E2.9060502@freebsd.org> Date: Tue, 08 Nov 2011 18:22:26 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "K. Macy" , Alan Cox , Andriy Gapon , Attilio Rao , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 02:22:42 -0000 On 11/8/11 5:22 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Nov 8, 2011 at 3:34 PM, Attilio Rao wrote: >> 2011/11/8 Arnaud Lacombe: >>> Hi, >>> >>> On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe wrote: >>>> On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao wrote: >>>>> 2011/11/7 Arnaud Lacombe: >>>>>> Hi, >>>>>> >>>>>> On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov wrote: >>>>>>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>>>>>> >>>>>>> Below is the KBI patch after vm_page_bits_t merge is done. >>>>>>> Again, I did not spent time converting all in-tree consumers >>>>>>> from the (potentially) loadable modules to the new KPI until it >>>>>>> is agreed upon. >>>>>>> >>>>>>> diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c >>>>>>> index 305c189..7264cd1 100644 >>>>>>> --- a/sys/nfsclient/nfs_bio.c >>>>>>> +++ b/sys/nfsclient/nfs_bio.c >>>>>>> @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) >>>>>>> * can only occur at the file EOF. >>>>>>> */ >>>>>>> VM_OBJECT_LOCK(object); >>>>>>> - if (pages[ap->a_reqpage]->valid != 0) { >>>>>>> + if (vm_page_read_valid(pages[ap->a_reqpage]) != 0) { >>>>>>> for (i = 0; i< npages; ++i) { >>>>>>> if (i != ap->a_reqpage) { >>>>>>> vm_page_lock(pages[i]); >>>>>>> @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) >>>>>>> /* >>>>>>> * Read operation filled an entire page >>>>>>> */ >>>>>>> - m->valid = VM_PAGE_BITS_ALL; >>>>>>> - KASSERT(m->dirty == 0, >>>>>>> + vm_page_write_valid(m, VM_PAGE_BITS_ALL); >>>>>>> + KASSERT(vm_page_read_dirty(m) == 0, >>>>>>> ("nfs_getpages: page %p is dirty", m)); >>>>>>> } else if (size> toff) { >>>>>>> /* >>>>>>> * Read operation filled a partial page. >>>>>>> */ >>>>>>> - m->valid = 0; >>>>>>> + vm_page_write_valid(m, 0); >>>>>>> vm_page_set_valid(m, 0, size - toff); >>>>>>> - KASSERT(m->dirty == 0, >>>>>>> + KASSERT(vm_page_read_dirty(m) == 0, >>>>>>> ("nfs_getpages: page %p is dirty", m)); >>>>>>> } else { >>>>>>> /* >>>>>>> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >>>>>>> index 389aea5..2f41e70 100644 >>>>>>> --- a/sys/vm/vm_page.c >>>>>>> +++ b/sys/vm/vm_page.c >>>>>>> @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) >>>>>>> vm_page_dirty(m); >>>>>>> } >>>>>>> >>>>>>> +void >>>>>>> +vm_page_lock_func(vm_page_t m, const char *file, int line) >>>>>>> +{ >>>>>>> + >>>>>>> +#if LOCK_DEBUG> 0 || defined(MUTEX_NOINLINE) >>>>>>> + _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); >>>>>>> +#else >>>>>>> + __mtx_lock(vm_page_lockptr(m), 0, file, line); >>>>>>> +#endif >>>>>>> +} >>>>>>> + >>>>>> Why do you re-implement the wheel ? all the point of these assessors >>>>>> is to hide implementation detail. IMO, you should restrict yourself to >>>>>> the documented API from mutex(9), only. >>>>>> >>>>>> Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but >>>>>> wait LOCK_FILE is either just __FILE__, or NULL, depending on >>>>>> LOCK_DEBUG, but you wouldn't have those function without >>>>>> INVARIANTS.... This whole LOCK_FILE/LOCK_LINE seem completely >>>>>> fracked-up... If you don't want this code in INVARIANTS, but in >>>>>> LOCK_DEBUG, only make it live only in the LOCK_DEBUG case. >>>>>> >>>>>> Btw, let me also question the use of non-inline functions. >>>>> My impression is that you don't really understand the patch, thus your >>>>> disrespectful words used here are really unjustified. >>>>> >>>> Well, unfortunately, I wasn't around to comment 10 years ago when this got in. >>>> >>>>> I think that kib@ intention is just to get "the most official way" to >>>>> pass down file and line to locking functions from the consumers. >>>>> His patch is "technically right", but I would prefer something >>>>> different (see below). >>>>> >>>> Yes, and that's not an excuse to use the _internal_ implementation >>>> details of mutex(9), and not the exposed API. This is especially true >>>> when applied to someone so eager to follow "standards". >>>> >>>>> LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata >>>>> section. Without INVARIANTS/WITNESS/etc. they will just be NULL and >>>>> not pointing to a lot of datas that won't be used in the opposite >>>>> case. >>>>> >>>> You comment just as if __FILE__ and __LINE__ were mandatory in a debug >>>> interface. This is _not_ true. __FILE__ and __LINE__ are just hideous >>>> for debugging of anything but early alpha code. LOCK_FILE and >>>> LOCK_LINE are a bad answer to a bad interface. Even if you just pass >>>> NULL and 0 as argument, you've got the bloat of passing unused >>>> argument. You might as well just pass a single argument that would do >>>> the exact same job and be _always_ available, eg. the IP of the >>>> caller, or the first return address. KDB magic still let you translate >>>> to something humanly understandable. If the toolchain does not support >>>> the feature on all supported platform, well, fix the toolchain. >>>> >>> To avoid future complaints about the fact that I would be only "talk" >>> without "action", I did implement what I suggested above. As it is >>> quite a large patch-set, I will not post it directly here, however, it >>> is available on github: >> I really think that this is way too dependent by the good health of >> your tool, thus that is highly fragile. >> > then fix the tools to be more robust. > >> However, you may have more luck by just the core of your kernel >> changes here, for comment and leave alone all the (ptr -> >> LOCK_FILE/LOCK_LINE conversion). >> >> Said that, I think this logic is too fragile and likely won't be as >> effective as __FILE__/__LINE__ in many cases. >> > Let point out a contradiction; if __FILE__/__LINE__ are so robust, and > if tools to inspect kernel are so broken and fragile, why don't you > make ddb/kdb reports those locations, by default, instead of > symbol+offset when it displays a backtrace ? gdb does, and ddb doesn't have the information available. > - Arnaud > _______________________________________________ > 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 Nov 9 02:35:49 2011 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 485E3106564A for ; Wed, 9 Nov 2011 02:35:49 +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 166EB8FC16 for ; Wed, 9 Nov 2011 02:35:48 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA92Zlxc022676 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Nov 2011 18:35:48 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EB9E6FE.3060102@freebsd.org> Date: Tue, 08 Nov 2011 18:35:42 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: <4EB9C469.9070208@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 02:35:49 -0000 On 11/8/11 5:52 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer wrote: >> On 11/8/11 10:49 AM, Arnaud Lacombe wrote: >>> Hi, >>> To avoid future complaints about the fact that I would be only "talk" >>> without "action", I did implement what I suggested above. As it is >>> quite a large patch-set, I will not post it directly here, however, it >>> is available on github: >>> >>> https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug >>> >>> It convert a bunch of debug interface to use the caller instruction >>> pointer, as well as a proof-of-concept teaching printf(9) to convert >>> IP to symbol_name+offset. >>> >>> It translates in a direct saving of about +250kB on i386's GENERIC, >>> just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, >>> translates to a save of +80kB. >>> >>> Please note that this is still WIP code. >> A couple of comments. >> Firstly, the idea of a printf method to print the IP as symbol+offset is an >> interesting idea >> that should be followed up in its own right. >> > FWIW, I have no credit in this idea. It has been in Linux for ages and ages. yeah as I said at work I use linux and BSD... the linux stuff that just prints out IP really annoys me. the list stuff and netgraph debug (which should be off in any production system) just require you to be able to see the console. and have sources nearby. if you need the IP use gdb. it's just what you are used to. You are obviously from the dark side ^H^H^H^H^H^H linux. so you are used to doing it that way.. but don't expect us to change just because that's what Linux does. When we have a problem at work on teh Linux driver, my first step is always to try duplicate it on FreeBSD because: 1/ half the time freebsd will just immediatly assert on something and present you with the bug.. done. 2/ I can run gdb through firewire on it on ANY standard unmodified kernel and find it, where on Linux I need to get a whole universe of stupid patches all aligned and MAYBE I might be able to see what is going on. if it's on redhat I need to do this, on ubuntu that, on suse something else ,and on different revisions of the kernel it all changes anyhow.. > That said, IP address are barely used in FreeBSD, there is no legacy. > As such, the API should not use `unsigned long' but `void *'[0]; this > is the natural type returned by `__builtin_return_address()' and the > `&&' operator. This would allow to introduce a modifier to `%p' to do > the translation. possibly intptr_t is what should be used. but I'd expect Bruce to drop in here and let us us know. > - Arnaud > > ps: netgraph is on my target list, as well as the list code, to some extend :) well let me know what you want to do because while it can do with love it is also used by a lot of people. if you nean to remove file/line.. don't. > [0]: as I really hate `caddr_t' it's probably older than you are.. times change. void* wasn't used much back then. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 03:27:06 2011 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 64CC81065673; Wed, 9 Nov 2011 03:27:06 +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 211A58FC08; Wed, 9 Nov 2011 03:27:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA93R5u0025966; Tue, 8 Nov 2011 22:27:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA93R55h025950; Wed, 9 Nov 2011 03:27:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Nov 2011 03:27:05 GMT Message-Id: <201111090327.pA93R55h025950@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 arm/arm 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, 09 Nov 2011 03:27:06 -0000 TB --- 2011-11-09 01:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 01:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-09 01:40:01 - cleaning the object tree TB --- 2011-11-09 01:40:28 - cvsupping the source tree TB --- 2011-11-09 01:40:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-09 01:45:51 - building world TB --- 2011-11-09 01:45:51 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 01:45:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 01:45:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 01:45:51 - SRCCONF=/dev/null TB --- 2011-11-09 01:45:51 - TARGET=arm TB --- 2011-11-09 01:45:51 - TARGET_ARCH=arm TB --- 2011-11-09 01:45:51 - TZ=UTC TB --- 2011-11-09 01:45:51 - __MAKE_CONF=/dev/null TB --- 2011-11-09 01:45:51 - cd /src TB --- 2011-11-09 01:45:51 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 01:45:52 UTC 2011 >>> 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 Nov 9 02:42:09 UTC 2011 TB --- 2011-11-09 02:42:09 - cd /src/sys/arm/conf TB --- 2011-11-09 02:42:09 - /usr/sbin/config -m AVILA TB --- 2011-11-09 02:42:09 - building AVILA kernel TB --- 2011-11-09 02:42:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:42:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:42:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:42:09 - SRCCONF=/dev/null TB --- 2011-11-09 02:42:09 - TARGET=arm TB --- 2011-11-09 02:42:09 - TARGET_ARCH=arm TB --- 2011-11-09 02:42:09 - TZ=UTC TB --- 2011-11-09 02:42:09 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:42:09 - cd /src TB --- 2011-11-09 02:42:09 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed Nov 9 02:42:09 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Wed Nov 9 02:45:25 UTC 2011 TB --- 2011-11-09 02:45:25 - cd /src/sys/arm/conf TB --- 2011-11-09 02:45:25 - /usr/sbin/config -m BWCT TB --- 2011-11-09 02:45:25 - building BWCT kernel TB --- 2011-11-09 02:45:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:45:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:45:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:45:25 - SRCCONF=/dev/null TB --- 2011-11-09 02:45:25 - TARGET=arm TB --- 2011-11-09 02:45:25 - TARGET_ARCH=arm TB --- 2011-11-09 02:45:25 - TZ=UTC TB --- 2011-11-09 02:45:25 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:45:25 - cd /src TB --- 2011-11-09 02:45:25 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Wed Nov 9 02:45:25 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Wed Nov 9 02:47:37 UTC 2011 TB --- 2011-11-09 02:47:37 - cd /src/sys/arm/conf TB --- 2011-11-09 02:47:37 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-09 02:47:37 - building CAMBRIA kernel TB --- 2011-11-09 02:47:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:47:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:47:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:47:37 - SRCCONF=/dev/null TB --- 2011-11-09 02:47:37 - TARGET=arm TB --- 2011-11-09 02:47:37 - TARGET_ARCH=arm TB --- 2011-11-09 02:47:37 - TZ=UTC TB --- 2011-11-09 02:47:37 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:47:37 - cd /src TB --- 2011-11-09 02:47:37 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Wed Nov 9 02:47:37 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Wed Nov 9 02:50:49 UTC 2011 TB --- 2011-11-09 02:50:49 - cd /src/sys/arm/conf TB --- 2011-11-09 02:50:49 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-09 02:50:49 - building CNS11XXNAS kernel TB --- 2011-11-09 02:50:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:50:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:50:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:50:49 - SRCCONF=/dev/null TB --- 2011-11-09 02:50:49 - TARGET=arm TB --- 2011-11-09 02:50:49 - TARGET_ARCH=arm TB --- 2011-11-09 02:50:49 - TZ=UTC TB --- 2011-11-09 02:50:49 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:50:49 - cd /src TB --- 2011-11-09 02:50:49 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Wed Nov 9 02:50:49 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Wed Nov 9 02:53:33 UTC 2011 TB --- 2011-11-09 02:53:33 - cd /src/sys/arm/conf TB --- 2011-11-09 02:53:33 - /usr/sbin/config -m CRB TB --- 2011-11-09 02:53:34 - building CRB kernel TB --- 2011-11-09 02:53:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:53:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:53:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:53:34 - SRCCONF=/dev/null TB --- 2011-11-09 02:53:34 - TARGET=arm TB --- 2011-11-09 02:53:34 - TARGET_ARCH=arm TB --- 2011-11-09 02:53:34 - TZ=UTC TB --- 2011-11-09 02:53:34 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:53:34 - cd /src TB --- 2011-11-09 02:53:34 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Wed Nov 9 02:53:34 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Wed Nov 9 02:56:55 UTC 2011 TB --- 2011-11-09 02:56:55 - cd /src/sys/arm/conf TB --- 2011-11-09 02:56:55 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-09 02:56:55 - building DB-78XXX kernel TB --- 2011-11-09 02:56:55 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:56:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:56:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:56:55 - SRCCONF=/dev/null TB --- 2011-11-09 02:56:55 - TARGET=arm TB --- 2011-11-09 02:56:55 - TARGET_ARCH=arm TB --- 2011-11-09 02:56:55 - TZ=UTC TB --- 2011-11-09 02:56:55 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:56:55 - cd /src TB --- 2011-11-09 02:56:55 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Wed Nov 9 02:56:55 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Wed Nov 9 02:59:34 UTC 2011 TB --- 2011-11-09 02:59:34 - cd /src/sys/arm/conf TB --- 2011-11-09 02:59:34 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-09 02:59:34 - building DB-88F5XXX kernel TB --- 2011-11-09 02:59:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:59:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:59:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:59:34 - SRCCONF=/dev/null TB --- 2011-11-09 02:59:34 - TARGET=arm TB --- 2011-11-09 02:59:34 - TARGET_ARCH=arm TB --- 2011-11-09 02:59:34 - TZ=UTC TB --- 2011-11-09 02:59:34 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:59:34 - cd /src TB --- 2011-11-09 02:59:34 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Wed Nov 9 02:59:34 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Wed Nov 9 03:02:41 UTC 2011 TB --- 2011-11-09 03:02:41 - cd /src/sys/arm/conf TB --- 2011-11-09 03:02:41 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-09 03:02:41 - building DB-88F6XXX kernel TB --- 2011-11-09 03:02:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:02:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:02:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:02:41 - SRCCONF=/dev/null TB --- 2011-11-09 03:02:41 - TARGET=arm TB --- 2011-11-09 03:02:41 - TARGET_ARCH=arm TB --- 2011-11-09 03:02:41 - TZ=UTC TB --- 2011-11-09 03:02:41 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:02:41 - cd /src TB --- 2011-11-09 03:02:41 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Wed Nov 9 03:02:41 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Wed Nov 9 03:05:17 UTC 2011 TB --- 2011-11-09 03:05:17 - cd /src/sys/arm/conf TB --- 2011-11-09 03:05:17 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-09 03:05:17 - building DOCKSTAR kernel TB --- 2011-11-09 03:05:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:05:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:05:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:05:17 - SRCCONF=/dev/null TB --- 2011-11-09 03:05:17 - TARGET=arm TB --- 2011-11-09 03:05:17 - TARGET_ARCH=arm TB --- 2011-11-09 03:05:17 - TZ=UTC TB --- 2011-11-09 03:05:17 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:05:17 - cd /src TB --- 2011-11-09 03:05:17 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Wed Nov 9 03:05:17 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Wed Nov 9 03:07:50 UTC 2011 TB --- 2011-11-09 03:07:50 - cd /src/sys/arm/conf TB --- 2011-11-09 03:07:50 - /usr/sbin/config -m EP80219 TB --- 2011-11-09 03:07:50 - building EP80219 kernel TB --- 2011-11-09 03:07:50 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:07:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:07:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:07:50 - SRCCONF=/dev/null TB --- 2011-11-09 03:07:50 - TARGET=arm TB --- 2011-11-09 03:07:50 - TARGET_ARCH=arm TB --- 2011-11-09 03:07:50 - TZ=UTC TB --- 2011-11-09 03:07:50 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:07:50 - cd /src TB --- 2011-11-09 03:07:50 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Wed Nov 9 03:07:50 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Wed Nov 9 03:11:11 UTC 2011 TB --- 2011-11-09 03:11:11 - WARNING: no kernel config for GENERIC TB --- 2011-11-09 03:11:11 - cd /src/sys/arm/conf TB --- 2011-11-09 03:11:11 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-09 03:11:11 - building GUMSTIX kernel TB --- 2011-11-09 03:11:11 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:11:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:11:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:11:11 - SRCCONF=/dev/null TB --- 2011-11-09 03:11:11 - TARGET=arm TB --- 2011-11-09 03:11:11 - TARGET_ARCH=arm TB --- 2011-11-09 03:11:11 - TZ=UTC TB --- 2011-11-09 03:11:11 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:11:11 - cd /src TB --- 2011-11-09 03:11:11 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Wed Nov 9 03:11:11 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Wed Nov 9 03:13:21 UTC 2011 TB --- 2011-11-09 03:13:21 - cd /src/sys/arm/conf TB --- 2011-11-09 03:13:21 - /usr/sbin/config -m HL200 TB --- 2011-11-09 03:13:21 - building HL200 kernel TB --- 2011-11-09 03:13:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:13:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:13:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:13:21 - SRCCONF=/dev/null TB --- 2011-11-09 03:13:21 - TARGET=arm TB --- 2011-11-09 03:13:21 - TARGET_ARCH=arm TB --- 2011-11-09 03:13:21 - TZ=UTC TB --- 2011-11-09 03:13:21 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:13:21 - cd /src TB --- 2011-11-09 03:13:21 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Wed Nov 9 03:13:21 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Wed Nov 9 03:15:56 UTC 2011 TB --- 2011-11-09 03:15:56 - cd /src/sys/arm/conf TB --- 2011-11-09 03:15:56 - /usr/sbin/config -m HL201 TB --- 2011-11-09 03:15:56 - building HL201 kernel TB --- 2011-11-09 03:15:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:15:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:15:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:15:56 - SRCCONF=/dev/null TB --- 2011-11-09 03:15:56 - TARGET=arm TB --- 2011-11-09 03:15:56 - TARGET_ARCH=arm TB --- 2011-11-09 03:15:56 - TZ=UTC TB --- 2011-11-09 03:15:56 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:15:56 - cd /src TB --- 2011-11-09 03:15:56 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Wed Nov 9 03:15:56 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Wed Nov 9 03:18:15 UTC 2011 TB --- 2011-11-09 03:18:15 - cd /src/sys/arm/conf TB --- 2011-11-09 03:18:15 - /usr/sbin/config -m IQ31244 TB --- 2011-11-09 03:18:15 - building IQ31244 kernel TB --- 2011-11-09 03:18:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:18:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:18:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:18:15 - SRCCONF=/dev/null TB --- 2011-11-09 03:18:15 - TARGET=arm TB --- 2011-11-09 03:18:15 - TARGET_ARCH=arm TB --- 2011-11-09 03:18:15 - TZ=UTC TB --- 2011-11-09 03:18:15 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:18:15 - cd /src TB --- 2011-11-09 03:18:15 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Wed Nov 9 03:18:15 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Wed Nov 9 03:21:33 UTC 2011 TB --- 2011-11-09 03:21:33 - cd /src/sys/arm/conf TB --- 2011-11-09 03:21:33 - /usr/sbin/config -m KB920X TB --- 2011-11-09 03:21:33 - building KB920X kernel TB --- 2011-11-09 03:21:33 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:21:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:21:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:21:33 - SRCCONF=/dev/null TB --- 2011-11-09 03:21:33 - TARGET=arm TB --- 2011-11-09 03:21:33 - TARGET_ARCH=arm TB --- 2011-11-09 03:21:33 - TZ=UTC TB --- 2011-11-09 03:21:33 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:21:33 - cd /src TB --- 2011-11-09 03:21:33 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Wed Nov 9 03:21:33 UTC 2011 >>> 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 -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_cal.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_olc.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c: In function 'update_stats': /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c:763: warning: unused variable 'rt' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-09 03:27:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-09 03:27:04 - ERROR: failed to build KB920X kernel TB --- 2011-11-09 03:27:04 - 4544.97 user 1129.29 system 6423.53 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 03:58:20 2011 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 8C3E6106566B; Wed, 9 Nov 2011 03:58:20 +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 561938FC08; Wed, 9 Nov 2011 03:58:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA93wJwu075636; Tue, 8 Nov 2011 22:58:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA93wJs4075627; Wed, 9 Nov 2011 03:58:19 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Nov 2011 03:58:19 GMT Message-Id: <201111090358.pA93wJs4075627@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: Wed, 09 Nov 2011 03:58:20 -0000 TB --- 2011-11-09 01:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 01:40:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-09 01:40:01 - cleaning the object tree TB --- 2011-11-09 01:40:24 - cvsupping the source tree TB --- 2011-11-09 01:40:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-09 01:40:38 - building world TB --- 2011-11-09 01:40:38 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 01:40:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 01:40:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 01:40:38 - SRCCONF=/dev/null TB --- 2011-11-09 01:40:38 - TARGET=pc98 TB --- 2011-11-09 01:40:38 - TARGET_ARCH=i386 TB --- 2011-11-09 01:40:38 - TZ=UTC TB --- 2011-11-09 01:40:38 - __MAKE_CONF=/dev/null TB --- 2011-11-09 01:40:38 - cd /src TB --- 2011-11-09 01:40:38 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 01:40:38 UTC 2011 >>> 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 Nov 9 03:49:54 UTC 2011 TB --- 2011-11-09 03:49:54 - generating LINT kernel config TB --- 2011-11-09 03:49:54 - cd /src/sys/pc98/conf TB --- 2011-11-09 03:49:54 - /usr/bin/make -B LINT TB --- 2011-11-09 03:49:54 - cd /src/sys/pc98/conf TB --- 2011-11-09 03:49:54 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 03:49:54 - building GENERIC kernel TB --- 2011-11-09 03:49:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:49:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:49:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:49:54 - SRCCONF=/dev/null TB --- 2011-11-09 03:49:54 - TARGET=pc98 TB --- 2011-11-09 03:49:54 - TARGET_ARCH=i386 TB --- 2011-11-09 03:49:54 - TZ=UTC TB --- 2011-11-09 03:49:54 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:49:54 - cd /src TB --- 2011-11-09 03:49:54 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 9 03:49:55 UTC 2011 >>> 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 -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_cal.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_olc.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c: In function 'update_stats': /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c:763: warning: unused variable 'rt' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-09 03:58:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-09 03:58:19 - ERROR: failed to build GENERIC kernel TB --- 2011-11-09 03:58:19 - 6637.81 user 1182.52 system 8298.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 05:05:55 2011 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 2EBCC1065672; Wed, 9 Nov 2011 05:05:55 +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 E9BC98FC17; Wed, 9 Nov 2011 05:05:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA955rWd062698; Wed, 9 Nov 2011 00:05:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA955rtP062693; Wed, 9 Nov 2011 05:05:53 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Nov 2011 05:05:53 GMT Message-Id: <201111090505.pA955rtP062693@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, 09 Nov 2011 05:05:55 -0000 TB --- 2011-11-09 03:27:05 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 03:27:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-09 03:27:05 - cleaning the object tree TB --- 2011-11-09 03:27:19 - cvsupping the source tree TB --- 2011-11-09 03:27:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-09 03:27:32 - building world TB --- 2011-11-09 03:27:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:27:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:27:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:27:32 - SRCCONF=/dev/null TB --- 2011-11-09 03:27:32 - TARGET=ia64 TB --- 2011-11-09 03:27:32 - TARGET_ARCH=ia64 TB --- 2011-11-09 03:27:32 - TZ=UTC TB --- 2011-11-09 03:27:32 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:27:32 - cd /src TB --- 2011-11-09 03:27:32 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 03:27:33 UTC 2011 >>> 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 Nov 9 04:55:23 UTC 2011 TB --- 2011-11-09 04:55:23 - generating LINT kernel config TB --- 2011-11-09 04:55:23 - cd /src/sys/ia64/conf TB --- 2011-11-09 04:55:23 - /usr/bin/make -B LINT TB --- 2011-11-09 04:55:23 - cd /src/sys/ia64/conf TB --- 2011-11-09 04:55:23 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 04:55:23 - building GENERIC kernel TB --- 2011-11-09 04:55:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:55:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:55:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:55:23 - SRCCONF=/dev/null TB --- 2011-11-09 04:55:23 - TARGET=ia64 TB --- 2011-11-09 04:55:23 - TARGET_ARCH=ia64 TB --- 2011-11-09 04:55:23 - TZ=UTC TB --- 2011-11-09 04:55:23 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:55:23 - cd /src TB --- 2011-11-09 04:55:23 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 9 04:55:23 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_cal.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_olc.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c: In function 'update_stats': /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c:763: warning: unused variable 'rt' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-09 05:05:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-09 05:05:53 - ERROR: failed to build GENERIC kernel TB --- 2011-11-09 05:05:53 - 4680.35 user 894.99 system 5927.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 05:29:54 2011 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 3EDA6106564A; Wed, 9 Nov 2011 05:29:54 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 949A48FC0A; Wed, 9 Nov 2011 05:29:53 +0000 (UTC) Received: by wyg36 with SMTP id 36so1718192wyg.13 for ; Tue, 08 Nov 2011 21:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Lfjvl0AYeTf5zULG75U3ipxeKkbO1RKsnNIxrtSrnYA=; b=pS5/eNpCeQSWvfF8gnsdW6QRz3rcqaxbx/ZE/Je+71O/ok9fv3B9FsuQJ6BFFBB+qI NOcHc3q5y7bl/v1UAjD9MvsRcSpXUQDdZdjncWDY99goYP00Fnr5r8os2GM8Uv8vqxW+ Vj7t0OPBtfGExW34dllthsVIyh9qQChuIVGqk= MIME-Version: 1.0 Received: by 10.180.101.97 with SMTP id ff1mr913624wib.42.1320816592630; Tue, 08 Nov 2011 21:29:52 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 21:29:52 -0800 (PST) In-Reply-To: <4EB9E6FE.3060102@freebsd.org> References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> Date: Wed, 9 Nov 2011 00:29:52 -0500 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 05:29:54 -0000 Hi, On Tue, Nov 8, 2011 at 9:35 PM, Julian Elischer wrote: > On 11/8/11 5:52 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer >> =A0wrote: >>> >>> On 11/8/11 10:49 AM, Arnaud Lacombe wrote: >>>> >>>> Hi, >>>> To avoid future complaints about the fact that I would be only "talk" >>>> without "action", I did implement what I suggested above. As it is >>>> quite a large patch-set, I will not post it directly here, however, it >>>> is available on github: >>>> >>>> https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug >>>> >>>> It convert a bunch of debug interface to use the caller instruction >>>> pointer, as well as a proof-of-concept teaching printf(9) to convert >>>> IP to symbol_name+offset. >>>> >>>> It translates in a direct saving of about +250kB on i386's GENERIC, >>>> just in kernel text size. Even the worst case, ie LOCK_DEBUG =3D=3D 0, >>>> translates to a save of +80kB. >>>> >>>> Please note that this is still WIP code. >>> >>> A couple of comments. >>> Firstly, the idea of a printf method to print the IP as symbol+offset i= s >>> an >>> interesting idea >>> that should be followed up in its own right. >>> >> FWIW, I have no credit in this idea. It has been in Linux for ages and >> ages. > > yeah as I said =A0at work I use linux and BSD... > the linux stuff that just prints out IP really annoys me. > > the list stuff and netgraph debug (which should be off in any production > system) this is, I guess, where we do not agree. You find it acceptable to run totally different code in production and during debug. I do not. This is completely insane, even more nowadays where heavy parallelism increases the likelihood of races, and subtle change in the code, even optimization, can cause total behavioral change (ie. Heisenbug). For the record, we have been tracking for more than 2 months (first occurrences happened a year ago) an mbuf corruption in the network stack, present in all released code since at least FreeBSD 7[0]. Each time we think it is fixed, we are proven wrong by customers within a few days when the system crashes again. Even the last attempt which was believed to be bullet-proof failed and crashes daily. All that to say that production code should embed enough facilities to allow the system to be fully debugged with a runtime cost as low as possible, and a code-size cost as low as possible[1]. I should be able to connect on a production machine, turn a knob, an see what is going wrong, without the customer noticing. In the worst case, when you have to enable debug-only code, it must not be done by making the non-debug case more expensive, but wrap around. The whole original point of the patches was that LOCK_FILE and LOCK_LINE are a bad answer to a wrong problem. `__FILE__, __LINE__' and the bloat introduced is not the problem, `const char *file, int line' in way too much prototypes is. Now, you make me realize that `const char *file, int line' should just be removed, not replaced by `unsigned long' or anything else. It's likely to be done in another iteration. > just require you to be able to see the console. and have sources nearby. > if you need the IP use gdb. > "console debugging" is yet another abomination which should be hunted down. Just try to do any useful work at high-pps on a serial console... > it's just what you are used to. You are obviously from the dark side > ^H^H^H^H^H^H linux. > My obedience is totally irrelevant to the problem. However, if you want to know, my heart tends to be with BSDs. Unfortunately, it's a sad love-story where your Beloved keeps deceiving you day after day. You want to change small bits at a time, make several iteration of progress to make things brighter, but your Beloved refuses any change because of too much inertia. Sad. > so you are used to doing it that way.. but don't expect us to change just > because that's what Linux does. > again, mentioning Linux is totally irrelevant. Use of Instruction Pointer are implementation details for a not so intrusive solution to the problem I pointed out, and which you are totally missing. Now, please answer this: do you find any of the bloat to the non-debug case (ie. passing a NULL pointer and a 0 integer, when `LOCK_DEBUG =3D=3D 0') worth the extra debugability comfort to be acceptable ? If you do, then your focus is on making things comfortable for developers, at the expense 100's of users, rather than making things comfortable for 100's of users, at the expense of developers. > When we have a problem at work on teh Linux driver, my first step is alwa= ys > to try duplicate it on FreeBSD because: > well, you're lucky FreeBSD supports your device! Lately, we got lately a shiny multi-queue network cards with bypass mechanism... that is not supported in FreeBSD. So currently, we got an expensive paper-weight. > 1/ half the time freebsd will just immediatly assert on something and > present you with the bug.. done. > well, certainly not from a release build; assertion are disabled. > 2/ I can run gdb through firewire on it on ANY standard unmodified kernel > and find it, where on Linux I need to > get a whole universe of stupid patches all aligned and MAYBE I might be a= ble > to see what is going on. > if it's on redhat I need to do this, on ubuntu that, on suse something el= se > ,and on different revisions > of the kernel it all changes anyhow.. > machine (even x86-64 machines) I run FreeBSD on have no firewire, neither do my desktops, this limit the usability of the feature. Moreover, I do not use mass-distros either, except for desktop[3], but small embedded firmware (ala. openwrt), even on "middle-end" system, and stick to vanilla kernel (when not playing with -next). >> That said, IP address are barely used in FreeBSD, there is no legacy. >> As such, the API should not use `unsigned long' but `void *'[0]; this >> is the natural type returned by `__builtin_return_address()' and the >> `&&' operator. This would allow to introduce a modifier to `%p' to do >> the translation. > > possibly intptr_t is what should be used. but I'd expect Bruce to drop in > here and let us us know. > whatever will suit you :) I started by using `uintptr_t', but they cannot be printed in a portable manner and the printf(9) stuff was not ready yet. - Arnaud [0]: I am able to crash any kernel between 7-STABLE to 9.STABLE within minutes, with the right pattern and (mainstream and well supported) hardware. [1]: for example, when I read in `sys/kern/kern_fail.c': * Failpoints allow for injecting fake errors into running code on the fly, * without modifying code or recompiling with flags. Failpoints are always * present, and are very efficient when disabled. and see that "very efficient when disabled" translates into a __predict_false() conditional, well, sorry, but I am very dubious. Entering the branch _is_ still a cost. A most efficient way of doing this would be using gcc's `asm goto' statement, in which case the hot path only ever see a `nop', eventually patched at runtime. [2]: soekris-like boards do not qualify for "embedded" :) [3]: FreeBSD (8-STABLE) is way to limited and un-integrated to be anywhere but useful, not to speak about kernel bug which leave the system so fracked up that you have no other choice but to hard-reboot. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 05:59:56 2011 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 936201065674 for ; Wed, 9 Nov 2011 05:59:56 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 15D438FC1B for ; Wed, 9 Nov 2011 05:59:55 +0000 (UTC) Received: by wyg36 with SMTP id 36so1737298wyg.13 for ; Tue, 08 Nov 2011 21:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DHR7EedZMItYo77BVcuGQemeUFCqOxZAZI+Prse4Zgk=; b=r3iclLjXbLVNCh6HE3DqqsX7kijHOd6gPWQUqWsfl3bhztJKGHrgrjDfLLlSHoozNi SrmNatHJI939dtNNSVNBaAkZAKxjrLxwppYpHidE34voPST1133bs5BLil6dUTqr8ZpS tuS9KsBAmym/vgOI3qf6tCONkOfYhhmholv6o= MIME-Version: 1.0 Received: by 10.216.135.91 with SMTP id t69mr155112wei.63.1320818394810; Tue, 08 Nov 2011 21:59:54 -0800 (PST) Received: by 10.216.37.19 with HTTP; Tue, 8 Nov 2011 21:59:54 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 23:59:54 -0600 Message-ID: From: Kurt Touet To: Dan The Man Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: samba+zfs 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, 09 Nov 2011 05:59:56 -0000 On Tue, Nov 8, 2011 at 8:16 PM, Dan The Man wrote: > > On Tue, 8 Nov 2011, Kurt Touet wrote: > >> On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man wrote: >>> >>> >>> Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: >>> asterisk:~# uname -a >>> FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 >>> 19:46:53 CDT 2011 >>> droot@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL >>> =A0amd64 >>> asterisk:~# >>> >>> >>> >>> Dan. >>> >>> >>> -- >>> Dan The Man >>> CTO/ Senior System Administrator >>> Websites, Domains and Everything else >>> http://www.SunSaturn.com >>> Email: Dan@SunSaturn.com >>> >>> On Tue, 8 Nov 2011, Dan The Man wrote: >>> >>>> >>>> Ok here is some specs: this been running fine on 8.2 stable and i was >>>> sure >>>> it was running fine on RC1 as well. I did some testing against samba 3= 4 >>>> 35 >>>> and 36 in the ports collection all with the same slow write problems. >>>> >>>> I did further testing mounting drive in question with NFS and it did n= ot >>>> suffer the same problem, so it seems just samba related here, where >>>> samba >>>> would actually outperform my NFS mount before, now its taking 10x as >>>> long >>>> to write anything. >>>> >>>> This is really most simplistic setup I have, all I want to do is map a >>>> network drive at the house read/write so my laptop, desktop etc all ha= ve >>>> access to it. I have played with all the smb.conf options, and can't >>>> seem >>>> to find where the issue is, further research suggests others are >>>> experiencing same problems with beta3 from following forum post: >>>> >>>> http://forums.freebsd.org/showthread.php?t=3D27300 >>>> >>>> Hardware this is running on: I beleive a 4 year old amd chip and board= , >>>> with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 S= SD >>>> as >>>> UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap >>>> hitachi drives for my storage space,which is mirrored nightly with rsy= nc >>>> with another duplicate machine(cause I know someone is going to say wh= y >>>> not >>>> use raid5-raidz) >>>> >>>> Network specs: machine currently has dedicated IPV4 and gif0 tunneled >>>> IPV6 >>>> addresses to he.net. >>>> >>>> I've played with nearly every option in smb.conf disabling, enabling e= tc >>>> and can't seem to find the issue: here are my current config file >>>> settings >>>> on machine that could apply to samba: >>>> >>>> asterisk:~# cat /boot/loader.conf >>>> autoboot_delay=3D"5" >>>> accf_data_load=3D"YES" >>>> aio_load=3D"YES" >>>> zfs_load=3D"YES" >>>> kern.maxbcache=3D64M >>>> kern.ipc.maxpipekva=3D4M >>>> >>>> vfs.zfs.prefetch_disable=3D1 >>>> vm.kmem_size=3D"1844M" >>>> vfs.zfs.arc_min=3D"1024M" >>>> vfs.zfs.arc_max=3D"1536M" >>>> vfs.zfs.vdev.min_pending=3D2 >>>> vfs.zfs.vdev.max_pending=3D8 >>>> vfs.zfs.txg.timeout=3D5 >>>> vfs.zfs.zil_disable=3D"1" >>>> ahci_load=3D"YES" >>>> asterisk:~# >>>> >>>> asterisk:~# cat /usr/local/etc/smb.conf >>>> # Global parameters >>>> [global] >>>> =A0 =A0 =A0 workgroup =3D HOME >>>> =A0 =A0 =A0 netbios name =3D ASTERISK >>>> =A0 =A0 =A0 server string =3D "Primary backups" >>>> =A0 =A0 =A0 interfaces =3D sk0 >>>> =A0 =A0 =A0 #smb ports =3D 139 >>>> =A0 =A0 =A0 #security =3D USER >>>> =A0 =A0 =A0 security =3D SHARE >>>> =A0 =A0 =A0 encrypt passwords =3D Yes >>>> =A0 =A0 =A0 #socket options =3D TCP_NODELAY SO_RCVBUF=3D65536 SO_SNDBU= F=3D65536 >>>> =A0 =A0 =A0 domain master =3D no >>>> =A0 =A0 =A0 wins support =3D yes >>>> =A0 =A0 =A0 guest account =3D root >>>> =A0 =A0 =A0 socket options=3DSO_RCVBUF=3D131072 SO_SNDBUF=3D131072 TCP= _NODELAY >>>> =A0 =A0 =A0 use sendfile =3D no >>>> =A0 =A0 =A0 level2 oplocks =3D True >>>> =A0 =A0 =A0 read raw =3D no >>>> =A0 =A0 =A0 write cache size =3D 262144 >>>> =A0 =A0 =A0 min receivefile size =3D 16384 >>>> =A0 =A0 =A0 aio read size =3D 16384 >>>> =A0 =A0 =A0 aio write size =3D 16384 >>>> =A0 =A0 =A0 aio write behind =3D yes >>>> =A0 =A0 =A0 dns proxy =3D no >>>> =A0 =A0 =A0 max log size =3D 50 >>>> =A0 =A0 =A0 #log file =3D /dev/null >>>> =A0 =A0 =A0 log file =3D /var/log/samba.log >>>> =A0 =A0 =A0 debug level =3D 1 >>>> =A0 =A0 =A0 syslog =3D 0 >>>> >>>> [data] >>>> =A0 =A0 =A0 comment =3D "Primary backups" >>>> =A0 =A0 =A0 path =3D /data/public >>>> =A0 =A0 =A0 read only =3D No >>>> =A0 =A0 =A0 guest ok =3D Yes >>>> =A0 =A0 =A0 valid users =3D root >>>> asterisk:~# asterisk:~# cat /etc/sysctl.conf >>>> # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmit= h >>>> Exp $ >>>> # >>>> # =A0This file is read when going to multi-user and its contents piped >>>> thru >>>> # =A0``sysctl'' to adjust kernel values. =A0``man 5 sysctl.conf'' for >>>> details. >>>> # >>>> >>>> # Uncomment this to prevent users from seeing information about >>>> processes >>>> that >>>> # are being run under another UID. >>>> #security.bsd.see_other_uids=3D0 >>>> >>>> #raise file descriptors on the system >>>> kern.maxfiles=3D204916 >>>> kern.maxfilesperproc=3D204916 >>>> >>>> #raise sockets we can accept >>>> kern.ipc.somaxconn=3D32768 >>>> >>>> #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html >>>> kern.ipc.maxsockbuf=3D16777216 >>>> net.inet.tcp.rfc1323=3D1 >>>> net.inet.tcp.sendbuf_max=3D16777216 >>>> net.inet.tcp.recvbuf_max=3D16777216 >>>> net.inet.tcp.sendspace=3D65536 >>>> net.inet.tcp.recvspace=3D131072 >>>> >>>> #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations >>>> net.inet.icmp.icmplim=3D500 >>>> kern.ipc.nmbjumbop=3D192000 >>>> kern.ipc.nmbclusters=3D229376 >>>> kern.ipc.maxsockets=3D204800 >>>> net.inet.tcp.maxtcptw=3D163840 >>>> #also add following to /boot/loader.conf >>>> #vm.kmem_size=3D1844M >>>> #kern.maxbcache=3D64M >>>> #kern.ipc.maxpipekva=3D4M >>>> >>>> #default setting of net.inet.ip.portrange.first is to low, causing us >>>> problems with bind >>>> net.inet.ip.portrange.last=3D65535 >>>> net.inet.ip.portrange.first=3D1024 >>>> >>>> #DOS protection >>>> net.inet.tcp.msl=3D7500 >>>> net.inet.tcp.blackhole=3D2 >>>> net.inet.udp.blackhole=3D1 >>>> net.inet.icmp.icmplim=3D50 >>>> net.inet.ip.accept_sourceroute=3D0 >>>> net.inet.ip.sourceroute=3D0 >>>> >>>> #some stuff for samba >>>> kern.ipc.nmbclusters=3D32768 >>>> kern.maxvnodes=3D800000 >>>> net.inet.tcp.delayed_ack=3D0 >>>> net.inet.tcp.inflight.enable=3D0 >>>> net.inet.tcp.path_mtu_discovery=3D0 >>>> net.inet.tcp.recvbuf_auto=3D1 >>>> net.inet.tcp.recvbuf_inc=3D524288 >>>> net.inet.tcp.sendbuf_auto=3D1 >>>> net.inet.tcp.sendbuf_inc=3D524288 >>>> net.inet.udp.maxdgram=3D57344 >>>> net.inet.udp.recvspace=3D65535 >>>> net.local.stream.recvspace=3D65535 >>>> net.local.stream.sendspace=3D65535 >>>> net.inet.tcp.mssdflt=3D1460 >>>> >>>> #IPSEC >>>> net.inet.ip.forwarding=3D1 >>>> net.inet6.ip6.forwarding=3D1 >>>> kern.module_path=3D/boot/kernel;/boot/modules;/usr/local/modules >>>> >>>> >>>> #NFS--not concerned with data integrity when playing mostly already >>>> stored >>>> movies >>>> vfs.nfsrv.async=3D1 >>>> >>>> #JAIL >>>> #i like to use ping etc inside jail! >>>> security.jail.allow_raw_sockets=3D1 >>>> asterisk:~# >>>> >>>> >>>> Here are logs of me trying to mux a DTS mkv file from samba.log on deb= ug >>>> level 10, I get the following over and over again: >>>> >>>> [2011/11/08 03:24:00.067974, 10] ../lib/util/util.c:415(dump_data) >>>> [2011/11/08 03:24:00.067981, =A03] smbd/process.c:1466(switch_message) >>>> =A0switch message SMBwriteX (pid 64308) conn 0x805008450 >>>> [2011/11/08 03:24:00.067990, =A04] smbd/uid.c:345(change_to_user) >>>> =A0Skipping user change - already user >>>> [2011/11/08 03:24:00.068001, 10] >>>> locking/locking.c:120(strict_lock_default) >>>> =A0is_locked: optimisation - exclusive oplock on file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.068010, 10] >>>> locking/locking.c:162(strict_lock_default) >>>> =A0strict_lock_default: flavour =3D WINDOWS_LOCK brl start=3D83431665 >>>> len=3D65536 >>>> unlocked for fnum 49966 file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.068021, 10] lib/recvfile.c:65(default_sys_recvfil= e) >>>> =A0default_sys_recvfile: from =3D 33, to =3D 39, offset=3D83431665, co= unt =3D >>>> 65536 >>>> [2011/11/08 03:24:00.068995, 10] smbd/fileio.c:143(real_write_file) >>>> =A0real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>>> (1).mkv): pos =3D 83431665, size =3D 65536, returned 65536 >>>> [2011/11/08 03:24:00.069013, =A03] smbd/reply.c:4639(reply_write_and_X= ) >>>> =A0writeX fnum=3D49966 num=3D65536 wrote=3D65536 >>>> [2011/11/08 03:24:00.069038, 10] >>>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>> =A0got smb length of 65600 >>>> [2011/11/08 03:24:00.069052, 10] >>>> smbd/reply.c:4459(is_valid_writeX_buffer) >>>> =A0is_valid_writeX_buffer: true len =3D 65600, doff =3D 64, numtowrite= =3D 65536 >>>> [2011/11/08 03:24:00.069062, =A06] smbd/process.c:1659(process_smb) >>>> =A0got message type 0x0 of len 0x3f >>>> [2011/11/08 03:24:00.069072, =A03] smbd/process.c:1661(process_smb) >>>> =A0Transaction 15398 of length 67 (65536 toread) >>>> [2011/11/08 03:24:00.069081, =A05] lib/util.c:332(show_msg) >>>> [2011/11/08 03:24:00.069087, =A05] lib/util.c:342(show_msg) >>>> =A0size=3D63 >>>> =A0smb_com=3D0x2f >>>> =A0smb_rcls=3D0 >>>> =A0smb_reh=3D0 >>>> =A0smb_err=3D0 >>>> =A0smb_flg=3D24 >>>> =A0smb_flg2=3D51207 >>>> =A0smb_tid=3D1 >>>> =A0smb_pid=3D65279 >>>> =A0smb_uid=3D0 >>>> =A0smb_mid=3D36032 >>>> =A0smt_wct=3D14 >>>> =A0smb_vwv[ 0]=3D =A0255 (0xFF) >>>> =A0smb_vwv[ 1]=3D57054 (0xDEDE) >>>> =A0smb_vwv[ 2]=3D49966 (0xC32E) >>>> =A0smb_vwv[ 3]=3D 4337 (0x10F1) >>>> =A0smb_vwv[ 4]=3D 1274 (0x4FA) >>>> =A0smb_vwv[ 5]=3D65535 (0xFFFF) >>>> =A0smb_vwv[ 6]=3D65535 (0xFFFF) >>>> =A0smb_vwv[ 7]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[ 8]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[ 9]=3D =A0 =A01 (0x1) >>>> =A0smb_vwv[10]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[11]=3D =A0 64 (0x40) >>>> =A0smb_vwv[12]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[13]=3D =A0 =A00 (0x0) >>>> =A0smb_bcc=3D0 >>>> [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) >>>> [2011/11/08 03:24:00.069170, =A03] smbd/process.c:1466(switch_message) >>>> =A0switch message SMBwriteX (pid 64308) conn 0x805008450 >>>> [2011/11/08 03:24:00.069179, =A04] smbd/uid.c:345(change_to_user) >>>> =A0Skipping user change - already user >>>> [2011/11/08 03:24:00.069188, 10] >>>> locking/locking.c:120(strict_lock_default) >>>> =A0is_locked: optimisation - exclusive oplock on file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.069197, 10] >>>> locking/locking.c:162(strict_lock_default) >>>> =A0strict_lock_default: flavour =3D WINDOWS_LOCK brl start=3D83497201 >>>> len=3D65536 >>>> unlocked for fnum 49966 file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfil= e) >>>> =A0default_sys_recvfile: from =3D 33, to =3D 39, offset=3D83497201, co= unt =3D >>>> 65536 >>>> [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) >>>> =A0real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>>> (1).mkv): pos =3D 83497201, size =3D 65536, returned 65536 >>>> [2011/11/08 03:24:00.070004, =A03] smbd/reply.c:4639(reply_write_and_X= ) >>>> =A0writeX fnum=3D49966 num=3D65536 wrote=3D65536 >>>> [2011/11/08 03:24:00.070030, 10] >>>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>> =A0got smb length of 65600 >>>> [2011/11/08 03:24:00.070044, 10] >>>> smbd/reply.c:4459(is_valid_writeX_buffer) >>>> =A0is_valid_writeX_buffer: true len =3D 65600, doff =3D 64, numtowrite= =3D 65536 >>>> [2011/11/08 03:24:00.070053, =A06] smbd/process.c:1659(process_smb) >>>> =A0got message type 0x0 of len 0x3f >>>> [2011/11/08 03:24:00.070063, =A03] smbd/process.c:1661(process_smb) >>>> =A0Transaction 15399 of length 67 (65536 toread) >>>> [2011/11/08 03:24:00.070072, =A05] lib/util.c:332(show_msg) >>>> [2011/11/08 03:24:00.070077, =A05] lib/util.c:342(show_msg) >>>> =A0size=3D63 >>>> =A0smb_com=3D0x2f >>>> =A0smb_rcls=3D0 >>>> =A0smb_reh=3D0 >>>> =A0smb_err=3D0 >>>> =A0smb_flg=3D24 >>>> =A0smb_flg2=3D51207 >>>> =A0smb_tid=3D1 >>>> =A0smb_pid=3D65279 >>>> =A0smb_uid=3D0 >>>> =A0smb_mid=3D36102 >>>> =A0smt_wct=3D14 >>>> =A0smb_vwv[ 0]=3D =A0255 (0xFF) >>>> =A0smb_vwv[ 1]=3D57054 (0xDEDE) >>>> =A0smb_vwv[ 2]=3D49966 (0xC32E) >>>> =A0smb_vwv[ 3]=3D 4337 (0x10F1) >>>> =A0smb_vwv[ 4]=3D 1275 (0x4FB) >>>> =A0smb_vwv[ 5]=3D65535 (0xFFFF) >>>> =A0smb_vwv[ 6]=3D65535 (0xFFFF) >>>> =A0smb_vwv[ 7]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[ 8]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[ 9]=3D =A0 =A01 (0x1) >>>> =A0smb_vwv[10]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[11]=3D =A0 64 (0x40) >>>> =A0smb_vwv[12]=3D =A0 =A00 (0x0) >>>> =A0smb_vwv[13]=3D =A0 =A00 (0x0) >>>> =A0smb_bcc=3D0 >>>> >>>> >>>> Hopefully maybe someone can shine some light on this.... >>>> >>>> >>>> Dan. >>>> >>>> >>>> -- >>>> Dan The Man >>>> CTO/ Senior System Administrator >>>> Websites, Domains and Everything else >>>> http://www.SunSaturn.com >>>> Email: Dan@SunSaturn.com >>>> >>>> On Fri, 28 Oct 2011, Garrett Cooper wrote: >>>> >>>>> On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote: >>>>>> >>>>>> >>>>>> Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs >>>>>> its taking over an hour to just mux in things like DTS english, wher= e >>>>>> it >>>>>> was >>>>>> 15 minutes on beta3. >>>>> >>>>> Hi Dan, >>>>> - Can you do more deterministic / scientific benchmarks? >>>>> - Did you upgrade Samba? >>>>> - What is your system's operating hardware profile? >>>>> Thanks! >>>>> -Garrett >>>>> >> >> I had noticed a similar problem with doing large writes from my >> windows workstation to my freebsd ZFS array. =A0Previously I had been >> able to write at around 30MB/s (limited by a slow SATA controller), >> and those speeds had dropped to 3-5MB/s with long pauses between >> writes to the array (monitoring with zpool iostat). =A0 However, I just >> updated to stable/9 r227357 and the issue seems to have gone away; I'm >> back up to 30MB/s writes. >> >> Hope you find the same sort of thing, >> -kurt >> > > Yep your right, on RC2 my samba ZFS write speeds are back. > Thanks for heads up Kurt. > > > Dan. > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: Dan@SunSaturn.com > I may have spoken too soon. With the speeds back up to normal, I moved a bunch of content that I'd been storing temporarily on my workstation to the server. After a few hours and moving 40gb+ of content (not all at once), I noticed the same write problems cropping up again. I rebooted the server and speeds came back to normal. The oddity that I notice is that the array seems to be delaying writes to a single disc in my raidz1 vdev, and then writing out very slowly to it (1-2MB/s). The drive that it is doing it with has absolutely zero read/write/seek errors in SMART, and works just fine after the box is rebooted (so it shouldn't be a drive issue). The only thing interesting about this drive is that it replaced a failed drive a few weeks ago. Is anyone else seeing problems like this with samba/zfs ? Perhaps it's not exclusive to samba, either? -kurt From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:26:52 2011 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 29EB5106564A for ; Wed, 9 Nov 2011 06:26:52 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9F04E8FC15 for ; Wed, 9 Nov 2011 06:26:50 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id pA96Qgl4095426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 16:56:47 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Wed, 9 Nov 2011 16:56:42 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kurt Touet X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: -4.523 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org, Dan The Man Subject: Re: samba+zfs 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, 09 Nov 2011 06:26:52 -0000 On 09/11/2011, at 16:29, Kurt Touet wrote: > Is anyone else seeing problems like this with samba/zfs ? Perhaps > it's not exclusive to samba, either? Yep, I see this too. I can get 80-100Mbyte/sec reads out of a single disk but ZFS is (now) = very slow - it reads & writes and much more slowly (10-30MB/sec). When the array was fresh it was nice and fast - it is now 68% full and = hasn't been much more full than that (I don't know but am pretty sure it = never reach past 75%). The frustrating thing is trying to find some way of measuring what's = actually going on.. I haven't had much luck :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:28:18 2011 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 D2C4B106564A for ; Wed, 9 Nov 2011 06:28:18 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 52ADC8FC0A for ; Wed, 9 Nov 2011 06:28:18 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id pA96SC9Q095486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 16:58:17 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Wed, 9 Nov 2011 16:58:11 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kurt Touet X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: -4.523 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org, Dan The Man Subject: Re: samba+zfs 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, 09 Nov 2011 06:28:18 -0000 On 09/11/2011, at 16:56, Daniel O'Connor wrote: > On 09/11/2011, at 16:29, Kurt Touet wrote: >> Is anyone else seeing problems like this with samba/zfs ? Perhaps >> it's not exclusive to samba, either? >=20 > Yep, I see this too. >=20 > I can get 80-100Mbyte/sec reads out of a single disk but ZFS is (now) = very slow - it reads & writes and much more slowly (10-30MB/sec). >=20 > When the array was fresh it was nice and fast - it is now 68% full and = hasn't been much more full than that (I don't know but am pretty sure it = never reach past 75%). >=20 > The frustrating thing is trying to find some way of measuring what's = actually going on.. I haven't had much luck : Note that this is not restricted to Samba and while the server is not = completely idle it's not doing very much. dd's of large files (spooled backups going to tape) to /dev/null are as = slow as Samba. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:30:49 2011 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 4C1821065672; Wed, 9 Nov 2011 06:30:49 +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 F3D888FC08; Wed, 9 Nov 2011 06:30:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA96UmqB014323; Wed, 9 Nov 2011 01:30:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA96UmIY014275; Wed, 9 Nov 2011 06:30:48 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Nov 2011 06:30:48 GMT Message-Id: <201111090630.pA96UmIY014275@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/i386 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, 09 Nov 2011 06:30:49 -0000 TB --- 2011-11-09 01:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 01:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-09 01:40:01 - cleaning the object tree TB --- 2011-11-09 01:40:19 - cvsupping the source tree TB --- 2011-11-09 01:40:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-09 01:40:34 - building world TB --- 2011-11-09 01:40:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 01:40:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 01:40:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 01:40:34 - SRCCONF=/dev/null TB --- 2011-11-09 01:40:34 - TARGET=i386 TB --- 2011-11-09 01:40:34 - TARGET_ARCH=i386 TB --- 2011-11-09 01:40:34 - TZ=UTC TB --- 2011-11-09 01:40:34 - __MAKE_CONF=/dev/null TB --- 2011-11-09 01:40:34 - cd /src TB --- 2011-11-09 01:40:34 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 01:40:35 UTC 2011 >>> 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 Nov 9 03:49:56 UTC 2011 TB --- 2011-11-09 03:49:56 - generating LINT kernel config TB --- 2011-11-09 03:49:56 - cd /src/sys/i386/conf TB --- 2011-11-09 03:49:56 - /usr/bin/make -B LINT TB --- 2011-11-09 03:49:57 - cd /src/sys/i386/conf TB --- 2011-11-09 03:49:57 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-09 03:49:57 - building LINT-NOINET kernel TB --- 2011-11-09 03:49:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:49:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:49:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:49:57 - SRCCONF=/dev/null TB --- 2011-11-09 03:49:57 - TARGET=i386 TB --- 2011-11-09 03:49:57 - TARGET_ARCH=i386 TB --- 2011-11-09 03:49:57 - TZ=UTC TB --- 2011-11-09 03:49:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:49:57 - cd /src TB --- 2011-11-09 03:49:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 9 03:49:57 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET completed on Wed Nov 9 04:19:57 UTC 2011 TB --- 2011-11-09 04:19:57 - cd /src/sys/i386/conf TB --- 2011-11-09 04:19:57 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-09 04:19:57 - building LINT-NOINET6 kernel TB --- 2011-11-09 04:19:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:19:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:19:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:19:57 - SRCCONF=/dev/null TB --- 2011-11-09 04:19:57 - TARGET=i386 TB --- 2011-11-09 04:19:57 - TARGET_ARCH=i386 TB --- 2011-11-09 04:19:57 - TZ=UTC TB --- 2011-11-09 04:19:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:19:57 - cd /src TB --- 2011-11-09 04:19:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Nov 9 04:19:57 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET6 completed on Wed Nov 9 04:50:20 UTC 2011 TB --- 2011-11-09 04:50:20 - cd /src/sys/i386/conf TB --- 2011-11-09 04:50:20 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-09 04:50:20 - building LINT-NOIP kernel TB --- 2011-11-09 04:50:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:50:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:50:20 - SRCCONF=/dev/null TB --- 2011-11-09 04:50:20 - TARGET=i386 TB --- 2011-11-09 04:50:20 - TARGET_ARCH=i386 TB --- 2011-11-09 04:50:20 - TZ=UTC TB --- 2011-11-09 04:50:20 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:50:20 - cd /src TB --- 2011-11-09 04:50:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Nov 9 04:50:20 UTC 2011 >>> 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 >>> Kernel build for LINT-NOIP completed on Wed Nov 9 05:17:35 UTC 2011 TB --- 2011-11-09 05:17:35 - cd /src/sys/i386/conf TB --- 2011-11-09 05:17:35 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-09 05:17:35 - building LINT-VIMAGE kernel TB --- 2011-11-09 05:17:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 05:17:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 05:17:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 05:17:35 - SRCCONF=/dev/null TB --- 2011-11-09 05:17:35 - TARGET=i386 TB --- 2011-11-09 05:17:35 - TARGET_ARCH=i386 TB --- 2011-11-09 05:17:35 - TZ=UTC TB --- 2011-11-09 05:17:35 - __MAKE_CONF=/dev/null TB --- 2011-11-09 05:17:35 - cd /src TB --- 2011-11-09 05:17:35 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Wed Nov 9 05:17:35 UTC 2011 >>> 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 >>> Kernel build for LINT-VIMAGE completed on Wed Nov 9 05:48:57 UTC 2011 TB --- 2011-11-09 05:48:57 - cd /src/sys/i386/conf TB --- 2011-11-09 05:48:57 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 05:48:57 - building GENERIC kernel TB --- 2011-11-09 05:48:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 05:48:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 05:48:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 05:48:57 - SRCCONF=/dev/null TB --- 2011-11-09 05:48:57 - TARGET=i386 TB --- 2011-11-09 05:48:57 - TARGET_ARCH=i386 TB --- 2011-11-09 05:48:57 - TZ=UTC TB --- 2011-11-09 05:48:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 05:48:57 - cd /src TB --- 2011-11-09 05:48:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 9 05:48:57 UTC 2011 >>> 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 >>> Kernel build for GENERIC completed on Wed Nov 9 06:13:50 UTC 2011 TB --- 2011-11-09 06:13:50 - cd /src/sys/i386/conf TB --- 2011-11-09 06:13:51 - /usr/sbin/config -m PAE TB --- 2011-11-09 06:13:51 - building PAE kernel TB --- 2011-11-09 06:13:51 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 06:13:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 06:13:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 06:13:51 - SRCCONF=/dev/null TB --- 2011-11-09 06:13:51 - TARGET=i386 TB --- 2011-11-09 06:13:51 - TARGET_ARCH=i386 TB --- 2011-11-09 06:13:51 - TZ=UTC TB --- 2011-11-09 06:13:51 - __MAKE_CONF=/dev/null TB --- 2011-11-09 06:13:51 - cd /src TB --- 2011-11-09 06:13:51 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Wed Nov 9 06:13:51 UTC 2011 >>> 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 >>> Kernel build for PAE completed on Wed Nov 9 06:20:04 UTC 2011 TB --- 2011-11-09 06:20:04 - cd /src/sys/i386/conf TB --- 2011-11-09 06:20:04 - /usr/sbin/config -m XBOX TB --- 2011-11-09 06:20:04 - building XBOX kernel TB --- 2011-11-09 06:20:04 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 06:20:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 06:20:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 06:20:04 - SRCCONF=/dev/null TB --- 2011-11-09 06:20:04 - TARGET=i386 TB --- 2011-11-09 06:20:04 - TARGET_ARCH=i386 TB --- 2011-11-09 06:20:04 - TZ=UTC TB --- 2011-11-09 06:20:04 - __MAKE_CONF=/dev/null TB --- 2011-11-09 06:20:04 - cd /src TB --- 2011-11-09 06:20:04 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Wed Nov 9 06:20:04 UTC 2011 >>> 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 >>> Kernel build for XBOX completed on Wed Nov 9 06:23:24 UTC 2011 TB --- 2011-11-09 06:23:24 - cd /src/sys/i386/conf TB --- 2011-11-09 06:23:24 - /usr/sbin/config -m XEN TB --- 2011-11-09 06:23:24 - building XEN kernel TB --- 2011-11-09 06:23:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 06:23:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 06:23:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 06:23:24 - SRCCONF=/dev/null TB --- 2011-11-09 06:23:24 - TARGET=i386 TB --- 2011-11-09 06:23:24 - TARGET_ARCH=i386 TB --- 2011-11-09 06:23:24 - TZ=UTC TB --- 2011-11-09 06:23:24 - __MAKE_CONF=/dev/null TB --- 2011-11-09 06:23:24 - cd /src TB --- 2011-11-09 06:23:24 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Wed Nov 9 06:23:24 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_cal.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_olc.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c: In function 'update_stats': /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c:763: warning: unused variable 'rt' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-09 06:30:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-09 06:30:47 - ERROR: failed to build XEN kernel TB --- 2011-11-09 06:30:47 - 13934.55 user 2425.65 system 17446.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:55:28 2011 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 3346F1065674; Wed, 9 Nov 2011 06:55: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 E2C448FC1E; Wed, 9 Nov 2011 06:55:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA96tR7u080805; Wed, 9 Nov 2011 01:55:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA96tRDR080804; Wed, 9 Nov 2011 06:55:27 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Nov 2011 06:55:27 GMT Message-Id: <201111090655.pA96tRDR080804@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, 09 Nov 2011 06:55:28 -0000 TB --- 2011-11-09 05:05:54 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 05:05:54 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-09 05:05:54 - cleaning the object tree TB --- 2011-11-09 05:06:10 - cvsupping the source tree TB --- 2011-11-09 05:06:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-09 05:06:22 - building world TB --- 2011-11-09 05:06:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 05:06:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 05:06:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 05:06:22 - SRCCONF=/dev/null TB --- 2011-11-09 05:06:22 - TARGET=powerpc TB --- 2011-11-09 05:06:22 - TARGET_ARCH=powerpc64 TB --- 2011-11-09 05:06:22 - TZ=UTC TB --- 2011-11-09 05:06:22 - __MAKE_CONF=/dev/null TB --- 2011-11-09 05:06:22 - cd /src TB --- 2011-11-09 05:06:22 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 05:06:23 UTC 2011 >>> 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 Wed Nov 9 06:47:56 UTC 2011 TB --- 2011-11-09 06:47:57 - generating LINT kernel config TB --- 2011-11-09 06:47:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:47:57 - /usr/bin/make -B LINT TB --- 2011-11-09 06:47:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:47:57 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 06:47:57 - skipping GENERIC kernel TB --- 2011-11-09 06:47:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:47:57 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-09 06:47:57 - building GENERIC64 kernel TB --- 2011-11-09 06:47:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 06:47:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 06:47:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 06:47:57 - SRCCONF=/dev/null TB --- 2011-11-09 06:47:57 - TARGET=powerpc TB --- 2011-11-09 06:47:57 - TARGET_ARCH=powerpc64 TB --- 2011-11-09 06:47:57 - TZ=UTC TB --- 2011-11-09 06:47:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 06:47:57 - cd /src TB --- 2011-11-09 06:47:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Wed Nov 9 06:47:57 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_cal.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_olc.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c: In function 'update_stats': /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c:763: warning: unused variable 'rt' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-09 06:55:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-09 06:55:26 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-09 06:55:26 - 4884.06 user 1140.07 system 6572.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 07:02:53 2011 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 E43911065673 for ; Wed, 9 Nov 2011 07:02:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9FE8FC13 for ; Wed, 9 Nov 2011 07:02:53 +0000 (UTC) Received: by ggnk3 with SMTP id k3so1990274ggn.13 for ; Tue, 08 Nov 2011 23:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3h5vViHl9K/c1wlcSeIPiOnD1HG81Y9B+P61iLm4T4k=; b=rDHQcHCTwsuCLV5/g6ciTko/1nFsG0CuwsBXQHKm/sU9Z435X8h+OFmfp5BX9Q2fql kAl+r2nBJF4NpVRnqDZ3bFBx14cqjcW+QQE52GPGb1XRaVI6ml2OTDoQMrhbcB1x3VA+ f9F3rhX4Mm5XODJwaRU0woEVAuEsM2TaZXRKw= MIME-Version: 1.0 Received: by 10.182.169.34 with SMTP id ab2mr230832obc.27.1320822172963; Tue, 08 Nov 2011 23:02:52 -0800 (PST) Received: by 10.182.122.33 with HTTP; Tue, 8 Nov 2011 23:02:52 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 23:02:52 -0800 Message-ID: From: Garrett Cooper To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kurt Touet , freebsd-current@freebsd.org, Dan The Man Subject: Re: samba+zfs 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, 09 Nov 2011 07:02:54 -0000 On Tue, Nov 8, 2011 at 10:28 PM, Daniel O'Connor wr= ote: > > On 09/11/2011, at 16:56, Daniel O'Connor wrote: >> On 09/11/2011, at 16:29, Kurt Touet wrote: >>> Is anyone else seeing problems like this with samba/zfs ? =A0 =A0Perhap= s >>> it's not exclusive to samba, either? >> >> Yep, I see this too. >> >> I can get 80-100Mbyte/sec reads out of a single disk but ZFS is (now) ve= ry slow - it reads & writes and much more slowly (10-30MB/sec). >> >> When the array was fresh it was nice and fast - it is now 68% full and h= asn't been much more full than that (I don't know but am pretty sure it nev= er reach past 75%). >> >> The frustrating thing is trying to find some way of measuring what's act= ually going on.. I haven't had much luck : > > > Note that this is not restricted to Samba and while the server is not com= pletely idle it's not doing very much. > > dd's of large files (spooled backups going to tape) to /dev/null are as s= low as Samba. - Dedupe? - Compression? - How much RAM? - What debug options do you have enabled in the kernel? I've been noticing a slowdown in some respects with NFS/SMB, but I suspected it was because I have an re(4) based NIC. ZFS has also wired down a lot of my system memory for the L2ARC... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 07:05:30 2011 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 92AF41065673; Wed, 9 Nov 2011 07:05:30 +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 666F28FC17; Wed, 9 Nov 2011 07:05:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA975TCI042381; Wed, 9 Nov 2011 02:05:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA975T85042376; Wed, 9 Nov 2011 07:05:29 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Nov 2011 07:05:29 GMT Message-Id: <201111090705.pA975T85042376@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: Wed, 09 Nov 2011 07:05:30 -0000 TB --- 2011-11-09 04:57:29 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 04:57:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-09 04:57:29 - cleaning the object tree TB --- 2011-11-09 04:57:45 - cvsupping the source tree TB --- 2011-11-09 04:57:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-09 04:58:15 - building world TB --- 2011-11-09 04:58:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:58:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:58:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:58:15 - SRCCONF=/dev/null TB --- 2011-11-09 04:58:15 - TARGET=powerpc TB --- 2011-11-09 04:58:15 - TARGET_ARCH=powerpc TB --- 2011-11-09 04:58:15 - TZ=UTC TB --- 2011-11-09 04:58:15 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:58:15 - cd /src TB --- 2011-11-09 04:58:15 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 04:58:15 UTC 2011 >>> 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 Nov 9 06:58:56 UTC 2011 TB --- 2011-11-09 06:58:57 - generating LINT kernel config TB --- 2011-11-09 06:58:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:58:57 - /usr/bin/make -B LINT TB --- 2011-11-09 06:58:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:58:57 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 06:58:57 - building GENERIC kernel TB --- 2011-11-09 06:58:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 06:58:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 06:58:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 06:58:57 - SRCCONF=/dev/null TB --- 2011-11-09 06:58:57 - TARGET=powerpc TB --- 2011-11-09 06:58:57 - TARGET_ARCH=powerpc TB --- 2011-11-09 06:58:57 - TZ=UTC TB --- 2011-11-09 06:58:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 06:58:57 - cd /src TB --- 2011-11-09 06:58:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 9 06:58:57 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_cal.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_olc.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c: In function 'update_stats': /src/sys/modules/ath/../../dev/ath/ath_rate/sample/sample.c:763: warning: unused variable 'rt' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-09 07:05:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-09 07:05:29 - ERROR: failed to build GENERIC kernel TB --- 2011-11-09 07:05:29 - 6186.60 user 1059.09 system 7679.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 07:07:45 2011 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 BE582106566B for ; Wed, 9 Nov 2011 07:07:45 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA778FC0C for ; Wed, 9 Nov 2011 07:07:44 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id pA977cJa001457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 17:37:43 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: "Daniel O'Connor" In-Reply-To: Date: Wed, 9 Nov 2011 17:37:38 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> References: To: Garrett Cooper X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: -4.523 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Kurt Touet , freebsd-current@freebsd.org, Dan The Man Subject: Re: samba+zfs 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, 09 Nov 2011 07:07:45 -0000 On 09/11/2011, at 17:32, Garrett Cooper wrote >> dd's of large files (spooled backups going to tape) to /dev/null are = as slow as Samba. >=20 > - Dedupe? Nope. > - Compression? On the mail spool & ports, but not on the tape spool. > - How much RAM? 8GB. > - What debug options do you have enabled in the kernel? It is 8.2-GENERIC so.. no WITNESS (for example) > I've been noticing a slowdown in some respects with NFS/SMB, but I > suspected it was because I have an re(4) based NIC. ZFS has also wired > down a lot of my system memory for the L2ARC=85 re isn't great but I wouldn't expect it to slow down over time.. Unless = bounce buffers got used more and more or something. I have an em0 card in this system - but in any case it is slow locally = (i.e. dd a large file with 64k block size). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 08:47:09 2011 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 3BB87106566C for ; Wed, 9 Nov 2011 08:47:09 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 835F38FC17 for ; Wed, 9 Nov 2011 08:47:08 +0000 (UTC) Received: by wyg36 with SMTP id 36so1877466wyg.13 for ; Wed, 09 Nov 2011 00:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yMAq5txK1SgY7y98MxD4o6loSvfztUd/khEPGzHfygQ=; b=gjZK2OzobvXU3aGyiRQA7F2N9V6Jpd2S+/5S7JV2oMyG65d8jD31AU9Cnvn6HANPYG oYsiFtKdhBgJKy9At0zHOnoj2blBOzzyd1lGrnP3Q2u61hByEG8Vxz4nbR+p/RKXsLwW M21thRXP3nAejSv7K6Za/gFAT7h3plrFPn2d0= MIME-Version: 1.0 Received: by 10.216.136.6 with SMTP id v6mr5121615wei.78.1320828426837; Wed, 09 Nov 2011 00:47:06 -0800 (PST) Received: by 10.216.37.19 with HTTP; Wed, 9 Nov 2011 00:47:06 -0800 (PST) In-Reply-To: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> Date: Wed, 9 Nov 2011 02:47:06 -0600 Message-ID: From: Kurt Touet To: "Daniel O'Connor" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-current@freebsd.org, Dan The Man Subject: Re: samba+zfs 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, 09 Nov 2011 08:47:09 -0000 On Wed, Nov 9, 2011 at 1:07 AM, Daniel O'Connor wro= te: > > On 09/11/2011, at 17:32, Garrett Cooper wrote >>> dd's of large files (spooled backups going to tape) to /dev/null are as= slow as Samba. >> >> =A0 =A0- Dedupe? > > Nope. > >> =A0 =A0- Compression? > > On the mail spool & ports, but not on the tape spool. > >> =A0 =A0- How much RAM? > > 8GB. > >> =A0 =A0- What debug options do you have enabled in the kernel? > > It is 8.2-GENERIC so.. no WITNESS (for example) > >> =A0 =A0I've been noticing a slowdown in some respects with NFS/SMB, but = I >> suspected it was because I have an re(4) based NIC. ZFS has also wired >> down a lot of my system memory for the L2ARC=85 > > > re isn't great but I wouldn't expect it to slow down over time.. Unless b= ounce buffers got used more and more or something. > > I have an em0 card in this system - but in any case it is slow locally (i= .e. dd a large file with 64k block size). > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > =A0-- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > Right now (while experience slow writes via samba+zfs) this is general read speed off a 4 x 1.5TB sata2 raidz1: # dd if=3Dtest.file of=3D/dev/null 13753502+1 records in 13753502+1 records out 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) That's not in the same ball park of slow writes, but it is below what I expect for reads. My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for 7 days The above file read was stored before the 2 x 2tb mirror addition, so it was a solely read off the sata2 mobo ports. Reading off of something more recent (and split amongst both raidz1 and mirror vdevs): # dd if=3Dtest2.file of=3D/dev/null 9154715+1 records in 9154715+1 records out 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) This is, again, seems slower than usual, but not as terrible as the write speeds that I've been seeing via samba. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 12:32:14 2011 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 8CA66106566B for ; Wed, 9 Nov 2011 12:32:14 +0000 (UTC) (envelope-from jrid@cubinlab.ee.unimelb.edu.au) Received: from mail-gw2.its.unimelb.edu.au (mail-gw2.its.unimelb.edu.au [128.250.5.151]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF118FC08 for ; Wed, 9 Nov 2011 12:32:13 +0000 (UTC) Received: from emu.cubinlab.ee.unimelb.edu.au (cubinlab.ee.unimelb.edu.au [128.250.80.33]) by mail-gw2.its.unimelb.edu.au (Postfix) with ESMTPS id 040EC5DE for ; Wed, 9 Nov 2011 23:12:36 +1100 (EST) Received: from jrid.cubinlab.ee.unimelb.edu.au (jrid.cubinlab.ee.unimelb.edu.au [10.0.1.128]) (authenticated bits=0) by emu.cubinlab.ee.unimelb.edu.au (8.14.4/8.14.4) with ESMTP id pA9CCZRl003048 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO) for ; Wed, 9 Nov 2011 23:12:36 +1100 (EST) (envelope-from jrid@cubinlab.ee.unimelb.edu.au) From: Julien Ridoux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2011 23:12:35 +1100 Message-Id: <5C5F698C-FA28-4423-BD7B-CCD456752ACA@cubinlab.ee.unimelb.edu.au> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [RFC] Feed-Forward Clock support 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, 09 Nov 2011 12:32:14 -0000 Hi all, I have written a set of patches to support feed-forward clock = synchronisation algorithms. To cut a long story short, this work = provides support for alternatives to the NTP daemon. The RADclock daemon = we developed is one of these alternatives. This work is supported by the FreeBSD Foundation and a short project = description can be found here: http://www.freebsdfoundation.org/press/2011Aug-newsletter.shtml#Project4 The patches will be committed on the weekend of Nov 19th and suggestions = and comments would be very appreciated. The patches against r227382 can be found at this URL: http://www.cubinlab.ee.unimelb.edu.au/~jrid/ffclock_fbsd_r227382.tar.gz The patches introduce 3 new system calls and it is then necessary to run = 'make sysent' in sys/kern and sys/compat/freebsd32. The feed-forward support can be compiled by adding the FFCLOCK option to = the kernel configuration file. For more information, a fairly high level description of the = feed-forward approach for clock synchronisation is given in this ACM = Queue article. http://queue.acm.org/detail.cfm?id=3D1773943 All relevant technical papers, the latest stable RADclock version and = more can be found here: http://www.synclab.org/radclock/ Please let me know your thoughts, Thanks, Julien From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 14:14:05 2011 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 89BED106564A for ; Wed, 9 Nov 2011 14:14:05 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 262B08FC17 for ; Wed, 9 Nov 2011 14:14:04 +0000 (UTC) Received: by qyc1 with SMTP id 1so5872863qyc.13 for ; Wed, 09 Nov 2011 06:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=30Qc0q5bbwQyIS6LfY6Z48J+VqLf6EUfAkvhFIY0Kb0=; b=f9gB4U0FN7K4hcrnLfgSp2Cnf4JIyrvJbJe2GvYCvlz1PICqiJqqGKwSsFMwLX4K9u luFFVwMW6zaFCji4LG0S7atum7mjCqOgsIBf5pExlI8N3YiWBZQz4qwmRL1poJzxQ3h3 MVL8HgjBPOJDsUL1MoqCVNH33lo97ohIzILJw= MIME-Version: 1.0 Received: by 10.182.74.37 with SMTP id q5mr582365obv.32.1320848043901; Wed, 09 Nov 2011 06:14:03 -0800 (PST) Received: by 10.182.42.104 with HTTP; Wed, 9 Nov 2011 06:14:03 -0800 (PST) In-Reply-To: References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> Date: Wed, 9 Nov 2011 15:14:03 +0100 Message-ID: From: Oliver Pinter To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 14:14:05 -0000 On 11/9/11, Arnaud Lacombe wrote: > Hi, > > On Tue, Nov 8, 2011 at 9:35 PM, Julian Elischer wrote: >> On 11/8/11 5:52 PM, Arnaud Lacombe wrote: >>> >>> Hi, >>> >>> On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer >>> wrote: >>>> >>>> On 11/8/11 10:49 AM, Arnaud Lacombe wrote: >>>>> >>>>> Hi, >>>>> To avoid future complaints about the fact that I would be only "talk" >>>>> without "action", I did implement what I suggested above. As it is >>>>> quite a large patch-set, I will not post it directly here, however, it >>>>> is available on github: >>>>> >>>>> https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug >>>>> >>>>> It convert a bunch of debug interface to use the caller instruction >>>>> pointer, as well as a proof-of-concept teaching printf(9) to convert >>>>> IP to symbol_name+offset. >>>>> >>>>> It translates in a direct saving of about +250kB on i386's GENERIC, >>>>> just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, >>>>> translates to a save of +80kB. >>>>> >>>>> Please note that this is still WIP code. >>>> >>>> A couple of comments. >>>> Firstly, the idea of a printf method to print the IP as symbol+offset is >>>> an >>>> interesting idea >>>> that should be followed up in its own right. >>>> >>> FWIW, I have no credit in this idea. It has been in Linux for ages and >>> ages. >> >> yeah as I said at work I use linux and BSD... >> the linux stuff that just prints out IP really annoys me. >> >> the list stuff and netgraph debug (which should be off in any production >> system) > this is, I guess, where we do not agree. You find it acceptable to run > totally different code in production and during debug. I do not. This > is completely insane, even more nowadays where heavy parallelism > increases the likelihood of races, and subtle change in the code, even > optimization, can cause total behavioral change (ie. Heisenbug). > > For the record, we have been tracking for more than 2 months (first > occurrences happened a year ago) an mbuf corruption in the network > stack, present in all released code since at least FreeBSD 7[0]. Each > time we think it is fixed, we are proven wrong by customers within a > few days when the system crashes again. Even the last attempt which > was believed to be bullet-proof failed and crashes daily. > > All that to say that production code should embed enough facilities to > allow the system to be fully debugged with a runtime cost as low as > possible, and a code-size cost as low as possible[1]. I should be able > to connect on a production machine, turn a knob, an see what is going > wrong, without the customer noticing. > > In the worst case, when you have to enable debug-only code, it must > not be done by making the non-debug case more expensive, but wrap > around. The whole original point of the patches was that LOCK_FILE and > LOCK_LINE are a bad answer to a wrong problem. > > `__FILE__, __LINE__' and the bloat introduced is not the problem, > `const char *file, int line' in way too much prototypes is. > > Now, you make me realize that `const char *file, int line' should just > be removed, not replaced by `unsigned long' or anything else. It's > likely to be done in another iteration. > >> just require you to be able to see the console. and have sources nearby. >> if you need the IP use gdb. >> > "console debugging" is yet another abomination which should be hunted > down. Just try to do any useful work at high-pps on a serial > console... > >> it's just what you are used to. You are obviously from the dark side >> ^H^H^H^H^H^H linux. >> > My obedience is totally irrelevant to the problem. > > However, if you want to know, my heart tends to be with BSDs. > Unfortunately, it's a sad love-story where your Beloved keeps > deceiving you day after day. You want to change small bits at a time, > make several iteration of progress to make things brighter, but your > Beloved refuses any change because of too much inertia. Sad. > >> so you are used to doing it that way.. but don't expect us to change just >> because that's what Linux does. >> > again, mentioning Linux is totally irrelevant. Use of Instruction > Pointer are implementation details for a not so intrusive solution to > the problem I pointed out, and which you are totally missing. > > Now, please answer this: do you find any of the bloat to the non-debug > case (ie. passing a NULL pointer and a 0 integer, when `LOCK_DEBUG == > 0') worth the extra debugability comfort to be acceptable ? > > If you do, then your focus is on making things comfortable for > developers, at the expense 100's of users, rather than making things > comfortable for 100's of users, at the expense of developers. > >> When we have a problem at work on teh Linux driver, my first step is >> always >> to try duplicate it on FreeBSD because: >> > well, you're lucky FreeBSD supports your device! Lately, we got lately > a shiny multi-queue network cards with bypass mechanism... that is not > supported in FreeBSD. So currently, we got an expensive paper-weight. > >> 1/ half the time freebsd will just immediatly assert on something and >> present you with the bug.. done. >> > well, certainly not from a release build; assertion are disabled. > >> 2/ I can run gdb through firewire on it on ANY standard unmodified kernel >> and find it, where on Linux I need to >> get a whole universe of stupid patches all aligned and MAYBE I might be >> able >> to see what is going on. >> if it's on redhat I need to do this, on ubuntu that, on suse something >> else >> ,and on different revisions >> of the kernel it all changes anyhow.. >> > machine (even x86-64 machines) I run FreeBSD on have no firewire, > neither do my desktops, this limit the usability of the feature. > Moreover, I do not use mass-distros either, except for desktop[3], but > small embedded firmware (ala. openwrt), even on "middle-end" system, > and stick to vanilla kernel (when not playing with -next). > >>> That said, IP address are barely used in FreeBSD, there is no legacy. >>> As such, the API should not use `unsigned long' but `void *'[0]; this >>> is the natural type returned by `__builtin_return_address()' and the >>> `&&' operator. This would allow to introduce a modifier to `%p' to do >>> the translation. >> >> possibly intptr_t is what should be used. but I'd expect Bruce to drop in >> here and let us us know. >> > whatever will suit you :) I started by using `uintptr_t', but they > cannot be printed in a portable manner and the printf(9) stuff was not > ready yet. > > - Arnaud > > [0]: I am able to crash any kernel between 7-STABLE to 9.STABLE within > minutes, with the right pattern and (mainstream and well supported) > hardware. Maybe this bug related to sk(4) driver? > > [1]: for example, when I read in `sys/kern/kern_fail.c': > > * Failpoints allow for injecting fake errors into running code on the fly, > * without modifying code or recompiling with flags. Failpoints are always > * present, and are very efficient when disabled. > > and see that "very efficient when disabled" translates into a > __predict_false() conditional, well, sorry, but I am very dubious. > Entering the branch _is_ still a cost. A most efficient way of doing > this would be using gcc's `asm goto' statement, in which case the hot > path only ever see a `nop', eventually patched at runtime. > > [2]: soekris-like boards do not qualify for "embedded" :) > > [3]: FreeBSD (8-STABLE) is way to limited and un-integrated to be > anywhere but useful, not to speak about kernel bug which leave the > system so fracked up that you have no other choice but to hard-reboot. > _______________________________________________ > 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 Nov 9 14:27:38 2011 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 30D7F1065673; Wed, 9 Nov 2011 14:27:38 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id D8E1E8FC19; Wed, 9 Nov 2011 14:27:37 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id D497B7BD8F; Wed, 9 Nov 2011 15:08:39 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id GlMtf37hs2Ol; Wed, 9 Nov 2011 15:08:34 +0100 (CET) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id 4DFD37BD5D; Wed, 9 Nov 2011 15:08:34 +0100 (CET) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id pA9E8Ytf076896; Wed, 9 Nov 2011 15:08:34 +0100 (CET) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 Nov 2011 15:08:34 +0100 From: Daniel Gerzo Organization: The FreeBSD Project Mail-Reply-To: In-Reply-To: <20111108095508.GA81445@freefall.freebsd.org> References: <20111108095508.GA81445@freefall.freebsd.org> Message-ID: <3cc153aa4fc398e3809ea826ebb9e3ad@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.4 Cc: stable@freebsd.org, hackers@freebsd.org Subject: Re: FreeBSD Status Report July-September, 2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@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, 09 Nov 2011 14:27:38 -0000 On Tue, 8 Nov 2011 09:55:09 +0000, Daniel Gerzo wrote: > FreeBSD Quarterly Status Report - Q3/2011 Unfortunately, I managed to use an old status report entry for KDE/FreeBSD, instead of the current one. I am sorry for any inconvenience; the current entry for KDE/FreeBSD is below: KDE/FreeBSD URL: http://FreeBSD.KDE.org URL: http://FreeBSD.KDE.org/area51.php Contact: KDE FreeBSD The KDE/FreeBSD team has continued to improve the experience of KDE software and Qt under FreeBSD. The latest round of improvements include: * Splitting some of the KDE modules into smaller ports * Reduced startup time by ~15 seconds * Allowed auto-login out-of-the-box * Kopete supports GoogleTalk * Kalzium installs with its molecular editor * Zeitgeist support added * Porting Calligra to FreeBSD (work-in-progress) The team has also made many releases and upstreamed many fixes and patches. The latest round of releases include: * Qt: 4.7.4 * PyQt: 4.8.5 (SIP: 4.12.4) * KDE SC: 4.7.2 * Amarok: 2.4.3 * KDevelop: 4.2.3 (KDevPlatform: 1.2.3) The team is always looking for more testers and porters so please contact us at kde-freebsd@KDE.org and visit our home page at http://FreeBSD.KDE.org. Open tasks: 1. Testing KDE PIM 4.7.2 2. Testing phonon-gstreamer and phonon-vlc as the phonon-xine backend was deprecated (and will remain in ports) -- Kind regards Daniel From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 15:27:46 2011 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 1432C1065670 for ; Wed, 9 Nov 2011 15:27:46 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8B53C8FC18 for ; Wed, 9 Nov 2011 15:27:45 +0000 (UTC) Received: by wwg14 with SMTP id 14so336547wwg.31 for ; Wed, 09 Nov 2011 07:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ArpLI749/wOAl8cBgrUtwawlTavGVajAGQcCZcSOj3A=; b=sLpbJGwa+hXNQICunfk12ceVsdtd2uF/I417kaxA/I8Kq5qIRu6mf+w304hQymKaqf 6YgLoSDTufTJ0FpZGZTb1TUmcc+BRY0AePGd3u2pnhi2MKE3JE8CJkZdsd5fPsMGvInz TI8ZM5QpzY7hDctCIS8X+/kYdiU90MlhJxboM= MIME-Version: 1.0 Received: by 10.180.3.227 with SMTP id f3mr3417948wif.5.1320852464333; Wed, 09 Nov 2011 07:27:44 -0800 (PST) Received: by 10.180.8.34 with HTTP; Wed, 9 Nov 2011 07:27:44 -0800 (PST) Date: Wed, 9 Nov 2011 10:27:44 -0500 Message-ID: From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] Allow syslogd to accept multiple configuration files 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, 09 Nov 2011 15:27:46 -0000 I've written the following patch to allow syslogd to accept multiple configuration files by passing multiple -f options. One use case for this is to specify a common configuration file that applies across multiple machines along with a second config file specific to the local machine. The patch can also be found at http://people.freebsd.org/~rstone/patches/syslogd-multiconf.diff (Oh, and before somebody asks, the reason that I converted struct filed to use a TAILQ was that at one point I found myself typing struct filed ***, then hit myself and refactored the code instead). Index: syslogd.c =================================================================== --- syslogd.c (revision 227341) +++ syslogd.c (working copy) @@ -114,7 +114,6 @@ #define SYSLOG_NAMES #include -const char *ConfFile = _PATH_LOGCONF; const char *PidFile = _PATH_LOGPID; const char ctty[] = _PATH_CONSOLE; @@ -141,6 +140,13 @@ STAILQ_HEAD(, funix) funixes = { &funix_default, &(funix_secure.next.stqe_next) }; +struct conf_file { + const char *name; + TAILQ_ENTRY(conf_file) next; +}; + +TAILQ_HEAD(, conf_file) conf_list = TAILQ_HEAD_INITIALIZER(conf_list); + /* * Flags to logmsg(). */ @@ -159,7 +165,7 @@ */ struct filed { - struct filed *f_next; /* next in linked list */ + TAILQ_ENTRY(filed) f_next; /* next in linked list */ short f_type; /* entry type, see below */ short f_file; /* file descriptor */ time_t f_time; /* time this was last written */ @@ -266,7 +272,7 @@ "FORW", "USERS", "WALL", "PIPE" }; -static struct filed *Files; /* Log files that we write to */ +static TAILQ_HEAD(, filed) Files = TAILQ_HEAD_INITIALIZER(Files); static struct filed consfile; /* Console */ static int Debug; /* debug flag */ @@ -351,6 +357,7 @@ struct timeval tv, *tvp; struct sigaction sact; struct funix *fx, *fx1; + struct conf_file *conf; sigset_t mask; pid_t ppid = 1, spid; socklen_t len; @@ -393,7 +400,11 @@ Debug++; break; case 'f': /* configuration file */ - ConfFile = optarg; + conf = malloc(sizeof(*conf)); + if (conf == NULL) + errx(1, "Could not alloc memory, exiting"); + conf->name = optarg; + TAILQ_INSERT_TAIL(&conf_list, conf, next); break; case 'k': /* keep remote kern fac */ KeepKernFac = 1; @@ -497,6 +508,14 @@ setlinebuf(stdout); } + if (TAILQ_EMPTY(&conf_list)) { + conf = malloc(sizeof(*conf)); + if (conf == NULL) + errx(1, "Could not alloc memory, exiting"); + conf->name = _PATH_LOGCONF; + TAILQ_INSERT_TAIL(&conf_list, conf, next); + } + if (NumAllowed) endservent(); @@ -989,7 +1008,7 @@ (void)sigsetmask(omask); return; } - for (f = Files; f; f = f->f_next) { + TAILQ_FOREACH(f, &Files, f_next) { /* skip messages that are incorrect priority */ if (!(((f->f_pcmp[fac] & PRI_EQ) && (f->f_pmask[fac] == prilev)) ||((f->f_pcmp[fac] & PRI_LT) && (f->f_pmask[fac] < prilev)) @@ -1066,7 +1085,7 @@ { struct filed *f; - for (f = Files; f; f = f->f_next) { + TAILQ_FOREACH(f, &Files, f_next) { if ((f->f_type == F_FILE) && (f->f_flags & FFLAG_NEEDSYNC)) { f->f_flags &= ~FFLAG_NEEDSYNC; @@ -1403,7 +1422,7 @@ goto oncemore; /* Now, look in list of active processes. */ - for (f = Files; f; f = f->f_next) + TAILQ_FOREACH(f, &Files, f_next) if (f->f_type == F_PIPE && f->f_un.f_pipe.f_pid == pid) { (void)close(f->f_file); @@ -1505,7 +1524,7 @@ was_initialized = Initialized; Initialized = 0; /* Don't log SIGCHLDs. */ - for (f = Files; f != NULL; f = f->f_next) { + TAILQ_FOREACH(f, &Files, f_next) { /* flush any pending output */ if (f->f_prevcount) fprintlog(f, 0, (char *)NULL); @@ -1528,90 +1547,37 @@ exit(1); } -/* - * INIT -- Initialize syslogd from configuration table - */ -static void -init(int signo) +static int +parse_conf(const char *conf) { int i; FILE *cf; - struct filed *f, *next, **nextp; + struct filed *f; char *p; char cline[LINE_MAX]; char prog[NAME_MAX+1]; char host[MAXHOSTNAMELEN]; - char oldLocalHostName[MAXHOSTNAMELEN]; - char hostMsg[2*MAXHOSTNAMELEN+40]; - char bootfileMsg[LINE_MAX]; - dprintf("init\n"); - - /* - * Load hostname (may have changed). - */ - if (signo != 0) - (void)strlcpy(oldLocalHostName, LocalHostName, - sizeof(oldLocalHostName)); - if (gethostname(LocalHostName, sizeof(LocalHostName))) - err(EX_OSERR, "gethostname() failed"); - if ((p = strchr(LocalHostName, '.')) != NULL) { - *p++ = '\0'; - LocalDomain = p; - } else { - LocalDomain = ""; - } - - /* - * Close all open log files. - */ - Initialized = 0; - for (f = Files; f != NULL; f = next) { - /* flush any pending output */ - if (f->f_prevcount) - fprintlog(f, 0, (char *)NULL); - - switch (f->f_type) { - case F_FILE: - case F_FORW: - case F_CONSOLE: - case F_TTY: - (void)close(f->f_file); - break; - case F_PIPE: - if (f->f_un.f_pipe.f_pid > 0) { - (void)close(f->f_file); - deadq_enter(f->f_un.f_pipe.f_pid, - f->f_un.f_pipe.f_pname); - } - f->f_un.f_pipe.f_pid = 0; - break; - } - next = f->f_next; - if (f->f_program) free(f->f_program); - if (f->f_host) free(f->f_host); - free((char *)f); - } - Files = NULL; - nextp = &Files; - /* open the configuration file */ - if ((cf = fopen(ConfFile, "r")) == NULL) { - dprintf("cannot open %s\n", ConfFile); - *nextp = (struct filed *)calloc(1, sizeof(*f)); - if (*nextp == NULL) { + if ((cf = fopen(conf, "r")) == NULL) { + dprintf("cannot open %s\n", conf); + f = (struct filed *)calloc(1, sizeof(*f)); + if (f == NULL) { logerror("calloc"); exit(1); } - cfline("*.ERR\t/dev/console", *nextp, "*", "*"); - (*nextp)->f_next = (struct filed *)calloc(1, sizeof(*f)); - if ((*nextp)->f_next == NULL) { + cfline("*.ERR\t/dev/console", f, "*", "*"); + TAILQ_INSERT_TAIL(&Files, f, f_next); + + f = (struct filed *)calloc(1, sizeof(*f)); + if (f == NULL) { logerror("calloc"); exit(1); } - cfline("*.PANIC\t*", (*nextp)->f_next, "*", "*"); + cfline("*.PANIC\t*", f, "*", "*"); + TAILQ_INSERT_TAIL(&Files, f, f_next); Initialized = 1; - return; + return (ENOENT); } /* @@ -1687,19 +1653,91 @@ logerror("calloc"); exit(1); } - *nextp = f; - nextp = &f->f_next; cfline(cline, f, prog, host); + TAILQ_INSERT_TAIL(&Files, f, f_next); } /* close the configuration file */ (void)fclose(cf); + return (0); +} + +/* + * INIT -- Initialize syslogd from configuration table + */ +static void +init(int signo) +{ + int i; + char *p; + struct filed *f, *next; + char oldLocalHostName[MAXHOSTNAMELEN]; + char hostMsg[2*MAXHOSTNAMELEN+40]; + char bootfileMsg[LINE_MAX]; + struct conf_file *conf; + int error; + + dprintf("init\n"); + + /* + * Load hostname (may have changed). + */ + if (signo != 0) + (void)strlcpy(oldLocalHostName, LocalHostName, + sizeof(oldLocalHostName)); + if (gethostname(LocalHostName, sizeof(LocalHostName))) + err(EX_OSERR, "gethostname() failed"); + if ((p = strchr(LocalHostName, '.')) != NULL) { + *p++ = '\0'; + LocalDomain = p; + } else { + LocalDomain = ""; + } + + /* + * Close all open log files. + */ + Initialized = 0; + TAILQ_FOREACH_SAFE(f, &Files, f_next, next) { + /* flush any pending output */ + if (f->f_prevcount) + fprintlog(f, 0, (char *)NULL); + + switch (f->f_type) { + case F_FILE: + case F_FORW: + case F_CONSOLE: + case F_TTY: + (void)close(f->f_file); + break; + case F_PIPE: + if (f->f_un.f_pipe.f_pid > 0) { + (void)close(f->f_file); + deadq_enter(f->f_un.f_pipe.f_pid, + f->f_un.f_pipe.f_pname); + } + f->f_un.f_pipe.f_pid = 0; + break; + } + if (f->f_program) free(f->f_program); + if (f->f_host) free(f->f_host); + TAILQ_REMOVE(&Files, f, f_next); + free((char *)f); + } + + TAILQ_FOREACH(conf, &conf_list, next) { + error = parse_conf(conf->name); + + if (error) + return; + } + Initialized = 1; if (Debug) { int port; - for (f = Files; f; f = f->f_next) { + TAILQ_FOREACH(f, &Files, f_next) { for (i = 0; i <= LOG_NFACILITIES; i++) if (f->f_pmask[i] == INTERNAL_NOPRI) printf("X "); @@ -2054,7 +2092,7 @@ MarkSeq = 0; } - for (f = Files; f; f = f->f_next) { + TAILQ_FOREACH(f, &Files, f_next) { if (f->f_prevcount && now >= REPEATTIME(f)) { dprintf("flush %s: repeated %d times, %d sec.\n", TypeNames[f->f_type], f->f_prevcount, From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 15:57:18 2011 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 7207D1065673 for ; Wed, 9 Nov 2011 15:57:18 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7268FC16 for ; Wed, 9 Nov 2011 15:57:17 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MDgic-1R9Jod3xl8-00HQYp; Wed, 09 Nov 2011 16:44:42 +0100 Message-ID: <4EBA9FE8.4080401@brockmann-consult.de> Date: Wed, 09 Nov 2011 16:44:40 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> In-Reply-To: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:NY44hzR7ntLhkphbsZ5bDe2n6MICtXS5K+bn5T/JxUd /YN+lxT9o42kwM6TLRIOtrwq9GRkY3HfaDfYaPJsPdEYpBJHFl eiYZQMUIGZGyqEOarDGX9Hq2worh1gV7j9Jq8DuWpaAG5RtObR IUWdCpuvSd3GGzgxll26F6LUFQKKULM026wJUV/bgil+V1ZUf8 LOCD+ka3eD6Bn5oTIM/x8LXlR0Rh0EwHG86/IjeRhW4WzWpGV0 CIw8mdQfb00vpDLCVopBN/B18wZSbCd81SZ0eGvsU9gDIxEII3 0e3OZv6c9SatVwGELMZrMqkfZ+3GccoHBc+gphsQYe9NtHksFO oc54SJk/Z9RxvhkEFpEI0VLsn7+ckp+45lgG73bzq Subject: Re: samba+zfs 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, 09 Nov 2011 15:57:18 -0000 On 11/09/2011 08:07 AM, Daniel O'Connor wrote: > On 09/11/2011, at 17:32, Garrett Cooper wrote >>> dd's of large files (spooled backups going to tape) to /dev/null are as slow as Samba. >> - Dedupe? > Nope. You are probably right, but just to be sure, let's verify that with: zpool get dedupratio If it is not 1.00x, then even though your dedup may be disabled, your data is deduped. >> - Compression? > On the mail spool & ports, but not on the tape spool. > >> - How much RAM? > 8GB. Why are your memory settings set so low if you have 8 GB of memory? Do you need 6.2 GB left over for other apps? On 11/08/2011 10:26 AM, Dan The Man wrote: > vm.kmem_size="1844M" > vfs.zfs.arc_min="1024M" > vfs.zfs.arc_max="1536M" On my machine with 48 GB of memory, I set: vm.kmem_size="44g" vm.kmem_size_max="44g" vfs.zfs.arc_min="80m" vfs.zfs.arc_max="42g" And now it is very fast. My dataset is only about 10 TiB, and the total space is around 32 TiB. In practice, it uses about 36g of ARC and 151g of L2ARC, rather than the full 42g. Before, writes were quite slow when doing read at the same time (such as simply using cp). You shouldn't set those the way I did, using all for ZFS, because you are also using UFS, which needs some memory too. Also, my machine has no services other than ssh, nfs, and samba. I guess leave some for whatever services you run (or does the kernel give up its memory it used when userspace apps want more, like in Linux?). Also, instead of vfs.zfs.zil_disable="1" you should try setting "sync=disabled" # zfs set sync=disabled somepool/someasyncdataset And to find out if it is a bad disk or some IO bottleneck, use gstat to check the load % while it is doing the slow writing. eg. # gstat -I 5s -f "gpt/root|label/.ank|gpt/log|gpt/cache" >> - What debug options do you have enabled in the kernel? > It is 8.2-GENERIC so.. no WITNESS (for example) > >> I've been noticing a slowdown in some respects with NFS/SMB, but I >> suspected it was because I have an re(4) based NIC. ZFS has also wired >> down a lot of my system memory for the L2ARC… > > re isn't great but I wouldn't expect it to slow down over time.. Unless bounce buffers got used more and more or something. > > I have an em0 card in this system - but in any case it is slow locally (i.e. dd a large file with 64k block size). > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > _______________________________________________ > 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 16:21:12 2011 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 3FB20106564A for ; Wed, 9 Nov 2011 16:21:12 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A29638FC18 for ; Wed, 9 Nov 2011 16:21:11 +0000 (UTC) Received: by wyg36 with SMTP id 36so2442191wyg.13 for ; Wed, 09 Nov 2011 08:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wDCiLZjgJ+NA5ftILGNlOsgbjfDwjk040uJoEPk0nyE=; b=cezQqdd1Xu/b2ZHxBJOXiRtfka0NVp3UE1hWaaUEV0yWS5fRcQ3pWlET/KjO/iG2J0 SKzhFh3rhkAIPzVmIA1e2tFnXLWYyYoSeD89akLb7Di7Cdsws8A1QOlHnamCuWCx2HJm U3aRARiyzoxjikCWjWTSWbN5HrnFFjN/EnOD0= MIME-Version: 1.0 Received: by 10.180.95.134 with SMTP id dk6mr3518146wib.59.1320855670707; Wed, 09 Nov 2011 08:21:10 -0800 (PST) Received: by 10.180.8.34 with HTTP; Wed, 9 Nov 2011 08:21:10 -0800 (PST) In-Reply-To: <20111109160158.GA55645@lor.one-eyed-alien.net> References: <20111109160158.GA55645@lor.one-eyed-alien.net> Date: Wed, 9 Nov 2011 11:21:10 -0500 Message-ID: From: Ryan Stone To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: [PATCH] Allow syslogd to accept multiple configuration files 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, 09 Nov 2011 16:21:12 -0000 On Wed, Nov 9, 2011 at 11:01 AM, Brooks Davis wrote: > Do you happen to know why the code calloc's the struct filed's with 1's? > I didn't do any investigation but that's seems like an odd pattern. calloc(1, sizeof(*f)) returns an array of 1 element of size sizeof(*f) that is pre-zeroed. It's the userland equivalent of malloc(sizeof(*f), ..., M_ZERO). From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 16:42:59 2011 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 27C0A1065670 for ; Wed, 9 Nov 2011 16:42:59 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3150C8FC17 for ; Wed, 9 Nov 2011 16:42:57 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id pA9G1wep055767; Wed, 9 Nov 2011 10:01:58 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id pA9G1wEd055766; Wed, 9 Nov 2011 10:01:58 -0600 (CST) (envelope-from brooks) Date: Wed, 9 Nov 2011 10:01:58 -0600 From: Brooks Davis To: Ryan Stone Message-ID: <20111109160158.GA55645@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current Subject: Re: [PATCH] Allow syslogd to accept multiple configuration files 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, 09 Nov 2011 16:42:59 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 09, 2011 at 10:27:44AM -0500, Ryan Stone wrote: > I've written the following patch to allow syslogd to accept multiple > configuration files by passing multiple -f options. One use case for > this is to specify a common configuration file that applies across > multiple machines along with a second config file specific to the > local machine. >=20 > The patch can also be found at > http://people.freebsd.org/~rstone/patches/syslogd-multiconf.diff >=20 > (Oh, and before somebody asks, the reason that I converted struct > filed to use a TAILQ was that at one point I found myself typing > struct filed ***, then hit myself and refactored the code instead). I gave it a once over and it looks good. Do you happen to know why the code calloc's the struct filed's with 1's? I didn't do any investigation but that's seems like an odd pattern. -- Brooks --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFOuqP1XY6L6fI4GtQRAlQLAJ9fzlfiFObK0MxxaElThJnVbbGWiACdGSQw f8YRir4bysLeXALBme0WmPM= =nfG6 -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 16:33:05 2011 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 E76DD106564A for ; Wed, 9 Nov 2011 16:33:05 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8894E8FC13 for ; Wed, 9 Nov 2011 16:33:04 +0000 (UTC) Received: by wyg36 with SMTP id 36so2459305wyg.13 for ; Wed, 09 Nov 2011 08:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.136.3 with SMTP id v3mr5840833wei.39.1320854624618; Wed, 09 Nov 2011 08:03:44 -0800 (PST) Received: by 10.216.244.204 with HTTP; Wed, 9 Nov 2011 08:03:44 -0800 (PST) Date: Thu, 10 Nov 2011 00:03:44 +0800 Message-ID: From: Alie Tan To: freebsd-current@freebsd.org X-Mailman-Approved-At: Wed, 09 Nov 2011 16:52:22 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unable to full shutdown FreeBSD 9.0-RC1 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, 09 Nov 2011 16:33:06 -0000 "shutdown -p now" and "halt -p" only turn off my screen and keep the power led on and does not spin down my HDD. I need someone help to solve this issue and i am willing to give some debug log but i am not familiar how to get it. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 17:39:24 2011 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 DF7E2106564A for ; Wed, 9 Nov 2011 17:39:24 +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 B9E868FC0A for ; Wed, 9 Nov 2011 17:39:24 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA9HdIvr027360 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Nov 2011 09:39:23 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EBABAC1.2090003@freebsd.org> Date: Wed, 09 Nov 2011 09:39:13 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 09 Nov 2011 17:39:25 -0000 On 11/8/11 9:29 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Nov 8, 2011 at 9:35 PM, Julian Elischer wrote: >> On 11/8/11 5:52 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer >>> wrote: >>>> On 11/8/11 10:49 AM, Arnaud Lacombe wrote: >>>>> Hi, >>>>> To avoid future complaints about the fact that I would be only "talk" >>>>> without "action", I did implement what I suggested above. As it is >>>>> quite a large patch-set, I will not post it directly here, however, it >>>>> is available on github: >>>>> >>>>> https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug >>>>> >>>>> It convert a bunch of debug interface to use the caller instruction >>>>> pointer, as well as a proof-of-concept teaching printf(9) to convert >>>>> IP to symbol_name+offset. >>>>> >>>>> It translates in a direct saving of about +250kB on i386's GENERIC, >>>>> just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, >>>>> translates to a save of +80kB. >>>>> >>>>> Please note that this is still WIP code. >>>> A couple of comments. >>>> Firstly, the idea of a printf method to print the IP as symbol+offset is >>>> an >>>> interesting idea >>>> that should be followed up in its own right. >>>> >>> FWIW, I have no credit in this idea. It has been in Linux for ages and >>> ages. >> yeah as I said at work I use linux and BSD... >> the linux stuff that just prints out IP really annoys me. >> >> the list stuff and netgraph debug (which should be off in any production >> system) > this is, I guess, where we do not agree. You find it acceptable to run > totally different code in production and during debug. I do not. This > is completely insane, even more nowadays where heavy parallelism > increases the likelihood of races, and subtle change in the code, even > optimization, can cause total behavioral change (ie. Heisenbug). > > For the record, we have been tracking for more than 2 months (first > occurrences happened a year ago) an mbuf corruption in the network > stack, present in all released code since at least FreeBSD 7[0]. Each > time we think it is fixed, we are proven wrong by customers within a > few days when the system crashes again. Even the last attempt which > was believed to be bullet-proof failed and crashes daily. > > All that to say that production code should embed enough facilities to > allow the system to be fully debugged with a runtime cost as low as > possible, and a code-size cost as low as possible[1]. I should be able > to connect on a production machine, turn a knob, an see what is going > wrong, without the customer noticing. > > In the worst case, when you have to enable debug-only code, it must > not be done by making the non-debug case more expensive, but wrap > around. The whole original point of the patches was that LOCK_FILE and > LOCK_LINE are a bad answer to a wrong problem. > > `__FILE__, __LINE__' and the bloat introduced is not the problem, > `const char *file, int line' in way too much prototypes is. > in netgraph if you turn off debugging you should not have any char * file stuff. it should all go away. ( he says from memory, not actually looking) > Now, you make me realize that `const char *file, int line' should just > be removed, not replaced by `unsigned long' or anything else. It's > likely to be done in another iteration. > >> just require you to be able to see the console. and have sources nearby. >> if you need the IP use gdb. >> > "console debugging" is yet another abomination which should be hunted > down. Just try to do any useful work at high-pps on a serial > console... if you want to use gdb, then use gdb and if you want to use ktr, then use that. don't just declare the rest of the universe incompetent. these things are usually there for the developer of the module and done in whatever way is most convenient fo rthem. >> it's just what you are used to. You are obviously from the dark side >> ^H^H^H^H^H^H linux. >> > My obedience is totally irrelevant to the problem. > However, if you want to know, my heart tends to be with BSDs. > Unfortunately, it's a sad love-story where your Beloved keeps > deceiving you day after day. You want to change small bits at a time, > make several iteration of progress to make things brighter, but your > Beloved refuses any change because of too much inertia. Sad. mostly it's because you keep attacking your loved one with a steak knife. flowers might get you further. >> so you are used to doing it that way.. but don't expect us to change just >> because that's what Linux does. >> > again, mentioning Linux is totally irrelevant. Use of Instruction > Pointer are implementation details for a not so intrusive solution to > the problem I pointed out, and which you are totally missing. since these modules were written many new options have come. for example the option to throw out a stack backtrace is new. For netgraph however, when I was debugging it, a file/line was exactly what I needed for the type of error I was looking for at the time. > Now, please answer this: do you find any of the bloat to the non-debug > case (ie. passing a NULL pointer and a 0 integer, when `LOCK_DEBUG == > 0') worth the extra debugability comfort to be acceptable ? not talking about lock debug (someone else's area), but in netgraph when netgraph is not in debug mode, there is no extra data passed around. similar for the list/queue macros. > If you do, then your focus is on making things comfortable for > developers, at the expense 100's of users, rather than making things > comfortable for 100's of users, at the expense of developers. > >> When we have a problem at work on teh Linux driver, my first step is always >> to try duplicate it on FreeBSD because: >> > well, you're lucky FreeBSD supports your device! Lately, we got lately > a shiny multi-queue network cards with bypass mechanism... that is not > supported in FreeBSD. So currently, we got an expensive paper-weight. well write a driver for it.. what do you think I'm doing with the driver I'm talking about? I wrote several bypass network card drivers when I was at cisco/ironport.. it's not rocket science, though it would be nice if we were to come up with a standard interface for bypass interfaces. That is a different topic though.. >> 1/ half the time freebsd will just immediatly assert on something and >> present you with the bug.. done. >> > well, certainly not from a release build; assertion are disabled. During development. we NEVER have bugs in production ;-) >> 2/ I can run gdb through firewire on it on ANY standard unmodified kernel >> and find it, where on Linux I need to >> get a whole universe of stupid patches all aligned and MAYBE I might be able >> to see what is going on. >> if it's on redhat I need to do this, on ubuntu that, on suse something else >> ,and on different revisions >> of the kernel it all changes anyhow.. >> > machine (even x86-64 machines) I run FreeBSD on have no firewire, > neither do my desktops, this limit the usability of the feature. > Moreover, I do not use mass-distros either, except for desktop[3], but > small embedded firmware (ala. openwrt), even on "middle-end" system, > and stick to vanilla kernel (when not playing with -next). I also use serial, but having a few spare firewire cards sitting around helps. >>> That said, IP address are barely used in FreeBSD, there is no legacy. >>> As such, the API should not use `unsigned long' but `void *'[0]; this >>> is the natural type returned by `__builtin_return_address()' and the >>> `&&' operator. This would allow to introduce a modifier to `%p' to do >>> the translation. >> possibly intptr_t is what should be used. but I'd expect Bruce to drop in >> here and let us us know. >> > whatever will suit you :) I started by using `uintptr_t', but they > cannot be printed in a portable manner and the printf(9) stuff was not > ready yet. > > - Arnaud > > [0]: I am able to crash any kernel between 7-STABLE to 9.STABLE within > minutes, with the right pattern and (mainstream and well supported) > hardware. and who have you reported that to? bug number? > [1]: for example, when I read in `sys/kern/kern_fail.c': > > * Failpoints allow for injecting fake errors into running code on the fly, > * without modifying code or recompiling with flags. Failpoints are always > * present, and are very efficient when disabled. > > and see that "very efficient when disabled" translates into a > __predict_false() conditional, well, sorry, but I am very dubious. > Entering the branch _is_ still a cost. A most efficient way of doing > this would be using gcc's `asm goto' statement, in which case the hot > path only ever see a `nop', eventually patched at runtime. > > [2]: soekris-like boards do not qualify for "embedded" :) > > [3]: FreeBSD (8-STABLE) is way to limited and un-integrated to be > anywhere but useful, not to speak about kernel bug which leave the > system so fracked up that you have no other choice but to hard-reboot. bug number? > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 17:47:49 2011 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 1C918106566B for ; Wed, 9 Nov 2011 17:47:49 +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 E49BB8FC1D for ; Wed, 9 Nov 2011 17:47:48 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA9HkOrI027388 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Nov 2011 09:46:26 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EBABC6B.2070606@freebsd.org> Date: Wed, 09 Nov 2011 09:46:19 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Julien Ridoux References: <5C5F698C-FA28-4423-BD7B-CCD456752ACA@cubinlab.ee.unimelb.edu.au> In-Reply-To: <5C5F698C-FA28-4423-BD7B-CCD456752ACA@cubinlab.ee.unimelb.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [RFC] Feed-Forward Clock support 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, 09 Nov 2011 17:47:49 -0000 On 11/9/11 4:12 AM, Julien Ridoux wrote: > Hi all, > > I have written a set of patches to support feed-forward clock synchronisation algorithms. To cut a long story short, this work provides support for alternatives to the NTP daemon. The RADclock daemon we developed is one of these alternatives. > > This work is supported by the FreeBSD Foundation and a short project description can be found here: > http://www.freebsdfoundation.org/press/2011Aug-newsletter.shtml#Project4 > > The patches will be committed on the weekend of Nov 19th and suggestions and comments would be very appreciated. > > The patches against r227382 can be found at this URL: > http://www.cubinlab.ee.unimelb.edu.au/~jrid/ffclock_fbsd_r227382.tar.gz > > The patches introduce 3 new system calls and it is then necessary to run 'make sysent' in sys/kern and sys/compat/freebsd32. > The feed-forward support can be compiled by adding the FFCLOCK option to the kernel configuration file. > > For more information, a fairly high level description of the feed-forward approach for clock synchronisation is given in this ACM Queue article. > http://queue.acm.org/detail.cfm?id=1773943 > > All relevant technical papers, the latest stable RADclock version and more can be found here: > http://www.synclab.org/radclock/ > > Please let me know your thoughts, Not a specific thought, more a general thought on new modules coming into the system and adding syscalls... whether we should make new modules add syscalls dynamically and hten export the allocated syscall number via sysctl, or whether static allocation is still good enough.. > Thanks, > Julien > > _______________________________________________ > 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 Nov 9 17:52:22 2011 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 B64331065673 for ; Wed, 9 Nov 2011 17:52:22 +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 8684B8FC1A for ; Wed, 9 Nov 2011 17:52:22 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA9HqKNd027399 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Nov 2011 09:52:21 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EBABDCF.8020107@freebsd.org> Date: Wed, 09 Nov 2011 09:52:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ryan Stone References: <20111109160158.GA55645@lor.one-eyed-alien.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , FreeBSD Current Subject: Re: [PATCH] Allow syslogd to accept multiple configuration files 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, 09 Nov 2011 17:52:22 -0000 On 11/9/11 8:21 AM, Ryan Stone wrote: > On Wed, Nov 9, 2011 at 11:01 AM, Brooks Davis wrote: >> Do you happen to know why the code calloc's the struct filed's with 1's? >> I didn't do any investigation but that's seems like an odd pattern. > calloc(1, sizeof(*f)) returns an array of 1 element of size sizeof(*f) > that is pre-zeroed. It's the userland equivalent of > malloc(sizeof(*f), ..., M_ZERO). I once did similar but changed the parser to have INCLUDE files. so you could insert new parts in between other entries it was about 15 years ago so I can't remember the syntax I used. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 19:39:36 2011 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 C4213106564A for ; Wed, 9 Nov 2011 19:39:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4D48FC08 for ; Wed, 9 Nov 2011 19:39:36 +0000 (UTC) Received: by dyk29 with SMTP id 29so124876dyk.13 for ; Wed, 09 Nov 2011 11:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z0K1tusVeHf5hcqlWendAwerzc/QeV1Rh8cDSLACbRk=; b=Qh8mpDZ8C2/xWEeQlIrKxc0jTvIWHngTA/N328OaGGjbxCwWmFraEVV1llzMVJdjTs kkKTsHYuYfA3/thpeXmCgfoKQkoN5CRRMhFdrc6JvKZ0LcXwI/ceh6/opMs/dOpn3zO9 D2wYk9plYa/DVGLxZRosejVXlMXo0y62bb79c= MIME-Version: 1.0 Received: by 10.182.41.69 with SMTP id d5mr1184287obl.47.1320867574524; Wed, 09 Nov 2011 11:39:34 -0800 (PST) Received: by 10.182.122.33 with HTTP; Wed, 9 Nov 2011 11:39:34 -0800 (PST) In-Reply-To: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> Date: Wed, 9 Nov 2011 11:39:34 -0800 Message-ID: From: Garrett Cooper To: "Daniel O'Connor" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Kurt Touet , "freebsd-current@freebsd.org" , Dan The Man Subject: Re: samba+zfs 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, 09 Nov 2011 19:39:36 -0000 On Nov 8, 2011, at 11:07 PM, "Daniel O'Connor" wrot= e: > > On 09/11/2011, at 17:32, Garrett Cooper wrote >>> dd's of large files (spooled backups going to tape) to /dev/null are as= slow as Samba. >> >> - Dedupe? > > Nope. > >> - Compression? > > On the mail spool & ports, but not on the tape spool. > >> - How much RAM? > > 8GB. >> - What debug options do you have enabled in the kernel? > > It is 8.2-GENERIC so.. no WITNESS (for example) Ok. 8.2 release or stable? >> I've been noticing a slowdown in some respects with NFS/SMB, but I >> suspected it was because I have an re(4) based NIC. ZFS has also wired >> down a lot of my system memory for the L2ARC=85 > > > re isn't great but I wouldn't expect it to slow down over time.. Unless b= ounce buffers got used more and more or something. > > I have an em0 card in this system - but in any case it is slow locally (i= .e. dd a large file with 64k block size). Good point. Simple base cases help isolate the root cause. That being said, my disk speed(s) are a lot better than my network + samba speeds (zfs:store is mfid0 backed with write cache enabled; zfs:sac is a single ada(4) backed disk with write cache enabled -- err... it shouldn't be like that), but I suspect that's misconfiguration on my part: $ sysctl hw.model hw.physmem hw.model: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz hw.physmem: 12863094784 $ sudo mfiutil show volumes mfi0 Volumes: Id Size Level Stripe State Cache Name mfid0 ( 1860G) RAID-6 64k OPTIMAL Enabled $ zpool status pool: sac state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM sac ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 errors: No known data errors pool: store state: ONLINE scan: scrub repaired 0 in 10h9m with 0 errors on Mon Nov 7 18:58:01 2011 config: NAME STATE READ WRITE CKSUM store ONLINE 0 0 0 mfid0p1 ONLINE 0 0 0 errors: No known data errors $ zfs list -o name,mountpoint,atime,sync,compression,dedup NAME MOUNTPOINT ATIME SYNC COMPRESS DEDUP sac legacy on standard off off sac/root / on standard off off sac/scratch /scratch on standard off off sac/scratch/freenas /scratch/freenas off standard on off sac/scratch/freenas/FreeBSD /scratch/freenas/FreeBSD off standard on off sac/usr /usr on standard off off sac/var /var on standard off off store /store on standard off off store/freebsd /store/freebsd on standard on on store/home /usr/home on standard off off $ dd if=3D/dev/zero of=3Dfoo bs=3D1m count=3D1024 1024+0 records out 1073741824 bytes transferred in 13.426620 secs (79971119 bytes/sec) $ cd /store $ dd if=3D/dev/zero of=3Dfoo bs=3D1m count=3D1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 7.565117 secs (141933276 bytes/sec) $ cat /usr/local/etc/smb.conf [global] workgroup =3D WORKGROUP server string =3D BAYONETTA security =3D user load printers =3D no max log size =3D 50 preferred master =3D yes local master =3D yes socket options =3D SO_RCVBUF=3D16384 SO_SNDBUF=3D16384 nt acl support =3D yes inherit acls =3D yes map acl inherit =3D yes aio read size =3D 16384 aio write size =3D 16384 [scratch] path =3D /scratch writeable =3D yes [store] path =3D /store writeable =3D yes $ I'll have to: 1. Recheck what Windows 7 says when transferring out to my box with a large file. 2. Use nc to quickly measure network performance. 3. Try transferring over NFS with both my Macbook and setup FreeBSD or Linux on the other workstation for testing out NFS transfers (64kB rsize/wsize of course). Wash, rinse, repeat with samba. The last I remember the transfer speeds were pitiful with samba36 (somewhere around 45MBps to my 'store' zpool). I've been conservative with the socket settings, but it might be time to bump that up along with the mbuf cluster count (for some odd reason I haven't changed it from the system default), reboot, and retest. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 22:43:46 2011 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 777E3106566C; Wed, 9 Nov 2011 22:43:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1FFA78FC08; Wed, 9 Nov 2011 22:43:45 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so2714409vcb.13 for ; Wed, 09 Nov 2011 14:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=vuUgL+2HLkI1f96BY6C6nh+2+IBqK4rYwjRNSqFchVw=; b=if8mRbtigNoytvvb2lZA+hyHpzmcCbsxfmVVRQHFVyVZ3LbxG6Xq5rVIkflrAdQJaw 27AcJU0jaMc9rTLCJ0X9G6rf3zBomBmjwnVTGoT+aCDVNmB3wOh+myLdgLdhQfYOsSDC MAhvGPshmBOFh+uD7GFIifz+hvn6y/Y2rEFy4= MIME-Version: 1.0 Received: by 10.52.24.210 with SMTP id w18mr8144463vdf.21.1320878625315; Wed, 09 Nov 2011 14:43:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Wed, 9 Nov 2011 14:43:45 -0800 (PST) Date: Wed, 9 Nov 2011 14:43:45 -0800 X-Google-Sender-Auth: pmHZLs57_glCxMzMfUx1VOZ-ND0 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: please test - AR5416/AR9220 PCI on SMP fix 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, 09 Nov 2011 22:43:46 -0000 Hi, I've included a fix into our ath/hal driver which enforces serialised register access on AR5416 and later PCI NICs when running on an SMP system. This is needed to fix a system hang issue that occurs with multiple CPUs doing register IO to/from these devices. I don't have any further information then that. Please update to -head and give things a try. If it still hangs when you bring the interface up, please email me a boot dmesg so I can ensure that it's enabled. You can also enable it manually before you create the interface - sysctl dev.ath.X.hal.serialise_reg_war=1 . Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 23:12:34 2011 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 5075F106564A for ; Wed, 9 Nov 2011 23:12:34 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C31798FC08 for ; Wed, 9 Nov 2011 23:12:33 +0000 (UTC) Received: by wwg14 with SMTP id 14so949597wwg.31 for ; Wed, 09 Nov 2011 15:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=T8CFuWfIWN2++6v25jmixpi91Cks8Gc8yxvyN0jJQBU=; b=RW7g2G6R0Bsy565CdtNvVhcEDUdO3YCZD8+JKjwaW2SYxeRgTRJQwigY2ZCDQ9Njq4 XzpYWnHGeu/6iTENGCm9k57i9MKEZWGwZFdFVlXjvMOh6/1D43dA64E7bVxyJLt1pAa3 0tTnK3w5DjGrrueWwOlkgtd6d68rsAIDOkmhA= MIME-Version: 1.0 Received: by 10.216.133.13 with SMTP id p13mr1516727wei.93.1320880352718; Wed, 09 Nov 2011 15:12:32 -0800 (PST) Received: by 10.216.37.19 with HTTP; Wed, 9 Nov 2011 15:12:32 -0800 (PST) In-Reply-To: References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> Date: Wed, 9 Nov 2011 17:12:32 -0600 Message-ID: From: Kurt Touet To: Garrett Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" , Dan The Man Subject: Re: samba+zfs 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, 09 Nov 2011 23:12:34 -0000 On Wed, Nov 9, 2011 at 1:39 PM, Garrett Cooper wrote: > On Nov 8, 2011, at 11:07 PM, "Daniel O'Connor" wr= ote: > >> >> On 09/11/2011, at 17:32, Garrett Cooper wrote >>>> dd's of large files (spooled backups going to tape) to /dev/null are a= s slow as Samba. >>> >>> =A0 - Dedupe? >> >> Nope. >> >>> =A0 - Compression? >> >> On the mail spool & ports, but not on the tape spool. >> >>> =A0 - How much RAM? >> >> 8GB. >>> =A0 - What debug options do you have enabled in the kernel? >> >> It is 8.2-GENERIC so.. no WITNESS (for example) > > Ok. 8.2 release or stable? > >>> =A0 I've been noticing a slowdown in some respects with NFS/SMB, but I >>> suspected it was because I have an re(4) based NIC. ZFS has also wired >>> down a lot of my system memory for the L2ARC=85 >> >> >> re isn't great but I wouldn't expect it to slow down over time.. Unless = bounce buffers got used more and more or something. >> >> I have an em0 card in this system - but in any case it is slow locally (= i.e. dd a large file with 64k block size). > > =A0 =A0Good point. Simple base cases help isolate the root cause. That > being said, my disk speed(s) are a lot better than my network + samba > speeds (zfs:store is mfid0 backed with write cache enabled; zfs:sac is > a single ada(4) backed disk with write cache enabled -- err... it > shouldn't be like that), but I suspect that's misconfiguration on my > part: > > $ sysctl hw.model hw.physmem > hw.model: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 W3520 =A0@ 2.67GHz > hw.physmem: 12863094784 > $ sudo mfiutil show volumes > mfi0 Volumes: > =A0Id =A0 =A0 Size =A0 =A0Level =A0 Stripe =A0State =A0 Cache =A0 Name > =A0mfid0 ( 1860G) RAID-6 =A0 =A0 =A064k OPTIMAL Enabled =A0 > $ zpool status > =A0pool: sac > =A0state: ONLINE > =A0scan: none requested > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0sac =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > =A0 =A0 =A0 =A0 =A0ada0p3 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > > errors: No known data errors > > =A0pool: store > =A0state: ONLINE > =A0scan: scrub repaired 0 in 10h9m with 0 errors on Mon Nov =A07 18:58:01= 2011 > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0store =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0mfid0p1 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > > errors: No known data errors > $ zfs list -o name,mountpoint,atime,sync,compression,dedup > NAME =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MOUNTPOINT =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0ATIME =A0 =A0 =A0SYNC > =A0COMPRESS =A0 =A0 =A0 =A0 =A0DEDUP > sac =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0legacy =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 on =A0standard > =A0 =A0 =A0off =A0 =A0 =A0 =A0 =A0 =A0off > sac/root =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0on =A0standard > =A0 =A0 =A0off =A0 =A0 =A0 =A0 =A0 =A0off > sac/scratch =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/scratch =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 on =A0standard > =A0 =A0 =A0off =A0 =A0 =A0 =A0 =A0 =A0off > sac/scratch/freenas =A0 =A0 =A0 =A0 =A0/scratch/freenas =A0 =A0 =A0 =A0 = =A0 =A0off =A0standard > =A0 =A0 =A0 on =A0 =A0 =A0 =A0 =A0 =A0off > sac/scratch/freenas/FreeBSD =A0/scratch/freenas/FreeBSD =A0 =A0off =A0sta= ndard > =A0 =A0 =A0 on =A0 =A0 =A0 =A0 =A0 =A0off > sac/usr =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/usr =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 on =A0standard > =A0 =A0 =A0off =A0 =A0 =A0 =A0 =A0 =A0off > sac/var =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/var =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 on =A0standard > =A0 =A0 =A0off =A0 =A0 =A0 =A0 =A0 =A0off > store =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/store =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 on =A0standard > =A0 =A0 =A0off =A0 =A0 =A0 =A0 =A0 =A0off > store/freebsd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/store/freebsd =A0 =A0 =A0 = =A0 =A0 =A0 =A0 on =A0standard > =A0 =A0 =A0 on =A0 =A0 =A0 =A0 =A0 =A0 on > store/home =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /usr/home =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0on =A0standard > =A0 =A0 =A0off =A0 =A0 =A0 =A0 =A0 =A0off > $ dd if=3D/dev/zero of=3Dfoo bs=3D1m count=3D1024 > 1024+0 records out > 1073741824 bytes transferred in 13.426620 secs (79971119 bytes/sec) > $ cd /store > $ dd if=3D/dev/zero of=3Dfoo bs=3D1m count=3D1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 7.565117 secs (141933276 bytes/sec) > $ cat /usr/local/etc/smb.conf > [global] > =A0 =A0 =A0 =A0workgroup =3D WORKGROUP > =A0 =A0 =A0 =A0server string =3D BAYONETTA > =A0 =A0 =A0 =A0security =3D user > =A0 =A0 =A0 =A0load printers =3D no > =A0 =A0 =A0 =A0max log size =3D 50 > =A0 =A0 =A0 =A0preferred master =3D yes > =A0 =A0 =A0 =A0local master =3D yes > =A0 =A0 =A0 =A0socket options =3D SO_RCVBUF=3D16384 SO_SNDBUF=3D16384 > =A0 =A0 =A0 =A0nt acl support =3D yes > =A0 =A0 =A0 =A0inherit acls =3D yes > =A0 =A0 =A0 =A0map acl inherit =3D yes > =A0 =A0 =A0 =A0aio read size =3D 16384 > =A0 =A0 =A0 =A0aio write size =3D 16384 > > [scratch] > =A0 =A0 =A0 =A0path =3D /scratch > =A0 =A0 =A0 =A0writeable =3D yes > > [store] > =A0 =A0 =A0 =A0path =3D /store > =A0 =A0 =A0 =A0writeable =3D yes > $ > > =A0 =A0I'll have to: > =A0 =A01. Recheck what Windows 7 says when transferring out to my box > with a large file. > =A0 =A02. Use nc to quickly measure network performance. > =A0 =A03. Try transferring over NFS with both my Macbook and setup > FreeBSD or Linux on the other workstation for testing out NFS > transfers (64kB rsize/wsize of course). Wash, rinse, repeat with > samba. > =A0 =A0The last I remember the transfer speeds were pitiful with samba36 > (somewhere around 45MBps to my 'store' zpool). I've been conservative > with the socket settings, but it might be time to bump that up along > with the mbuf cluster count (for some odd reason I haven't changed it > from the system default), reboot, and retest. > Thanks, > -Garrett > I have found the source of my speed issues, and they are not tied to samba or zfs. The replacement drive that I put into my array (just after I updated to stable/9 a few weeks ago) is hitting 100% busy in gstat while only writing out1-3MB/s -- it's a WDC WD15EARS-00Z5B1 and some quick googling has demonstrated that there are issues with drives like it. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 23:35:07 2011 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 682E31065676; Wed, 9 Nov 2011 23:35:07 +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 3BFCF8FC0C; Wed, 9 Nov 2011 23:35:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pA9NZ5H1006379; Wed, 9 Nov 2011 18:35:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pA9NZ51x006366; Wed, 9 Nov 2011 23:35:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Nov 2011 23:35:05 GMT Message-Id: <201111092335.pA9NZ51x006366@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 amd64/amd64 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, 09 Nov 2011 23:35:07 -0000 TB --- 2011-11-09 20:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 20:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-09 20:40:00 - cleaning the object tree TB --- 2011-11-09 20:40:48 - cvsupping the source tree TB --- 2011-11-09 20:40:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-09 20:46:31 - building world TB --- 2011-11-09 20:46:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 20:46:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 20:46:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 20:46:31 - SRCCONF=/dev/null TB --- 2011-11-09 20:46:31 - TARGET=amd64 TB --- 2011-11-09 20:46:31 - TARGET_ARCH=amd64 TB --- 2011-11-09 20:46:31 - TZ=UTC TB --- 2011-11-09 20:46:31 - __MAKE_CONF=/dev/null TB --- 2011-11-09 20:46:31 - cd /src TB --- 2011-11-09 20:46:31 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 20:46:32 UTC 2011 >>> 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 Wed Nov 9 23:28:55 UTC 2011 TB --- 2011-11-09 23:28:55 - generating LINT kernel config TB --- 2011-11-09 23:28:55 - cd /src/sys/amd64/conf TB --- 2011-11-09 23:28:55 - /usr/bin/make -B LINT TB --- 2011-11-09 23:28:55 - cd /src/sys/amd64/conf TB --- 2011-11-09 23:28:55 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-09 23:28:55 - building LINT-NOINET kernel TB --- 2011-11-09 23:28:55 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 23:28:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 23:28:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 23:28:55 - SRCCONF=/dev/null TB --- 2011-11-09 23:28:55 - TARGET=amd64 TB --- 2011-11-09 23:28:55 - TARGET_ARCH=amd64 TB --- 2011-11-09 23:28:55 - TZ=UTC TB --- 2011-11-09 23:28:55 - __MAKE_CONF=/dev/null TB --- 2011-11-09 23:28:55 - cd /src TB --- 2011-11-09 23:28:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 9 23:28:55 UTC 2011 >>> 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 -frename-registers -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5416/ar5416_phy.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -frename-registers -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5416/ar5416_power.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -frename-registers -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -frename-registers -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc1: warnings being treated as errors /src/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c: In function 'ar5416OverrideIni': /src/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c:2632: warning: implicit declaration of function 'AR_SREV_KIWI_10_OR_LATER' /src/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c:2632: warning: nested extern declaration of 'AR_SREV_KIWI_10_OR_LATER' [-Wnested-externs] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-09 23:35:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-09 23:35:05 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-09 23:35:05 - 7923.47 user 1538.57 system 10504.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 00:23:41 2011 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 A38F6106566C; Thu, 10 Nov 2011 00:23:41 +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 7683E8FC18; Thu, 10 Nov 2011 00:23:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAA0NeOM051872; Wed, 9 Nov 2011 19:23:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAA0NeC0051855; Thu, 10 Nov 2011 00:23:40 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 00:23:40 GMT Message-Id: <201111100023.pAA0NeC0051855@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: Thu, 10 Nov 2011 00:23:41 -0000 TB --- 2011-11-09 22:44:17 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 22:44:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-09 22:44:17 - cleaning the object tree TB --- 2011-11-09 22:44:32 - cvsupping the source tree TB --- 2011-11-09 22:44:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-09 22:44:46 - building world TB --- 2011-11-09 22:44:46 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 22:44:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 22:44:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 22:44:46 - SRCCONF=/dev/null TB --- 2011-11-09 22:44:46 - TARGET=ia64 TB --- 2011-11-09 22:44:46 - TARGET_ARCH=ia64 TB --- 2011-11-09 22:44:46 - TZ=UTC TB --- 2011-11-09 22:44:46 - __MAKE_CONF=/dev/null TB --- 2011-11-09 22:44:46 - cd /src TB --- 2011-11-09 22:44:46 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 9 22:44:46 UTC 2011 >>> 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 Nov 10 00:13:17 UTC 2011 TB --- 2011-11-10 00:13:17 - generating LINT kernel config TB --- 2011-11-10 00:13:17 - cd /src/sys/ia64/conf TB --- 2011-11-10 00:13:17 - /usr/bin/make -B LINT TB --- 2011-11-10 00:13:17 - cd /src/sys/ia64/conf TB --- 2011-11-10 00:13:17 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 00:13:17 - building GENERIC kernel TB --- 2011-11-10 00:13:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 00:13:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 00:13:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 00:13:17 - SRCCONF=/dev/null TB --- 2011-11-10 00:13:17 - TARGET=ia64 TB --- 2011-11-10 00:13:17 - TARGET_ARCH=ia64 TB --- 2011-11-10 00:13:17 - TZ=UTC TB --- 2011-11-10 00:13:17 - __MAKE_CONF=/dev/null TB --- 2011-11-10 00:13:17 - cd /src TB --- 2011-11-10 00:13:17 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 00:13:18 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_phy.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_power.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_recv.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_reset.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_reset.c: In function 'ar5416OverrideIni': /src/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_reset.c:2632: warning: implicit declaration of function 'AR_SREV_KIWI_10_OR_LATER' /src/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_reset.c:2632: warning: nested extern declaration of 'AR_SREV_KIWI_10_OR_LATER' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 00:23:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 00:23:40 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 00:23:40 - 4701.07 user 903.10 system 5962.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 00:34:36 2011 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 C7A91106566B for ; Thu, 10 Nov 2011 00:34:36 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4868F8FC0A for ; Thu, 10 Nov 2011 00:34:36 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id pAA0YQ2G095677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Nov 2011 11:04:31 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4EBABAC1.2090003@freebsd.org> Date: Thu, 10 Nov 2011 11:04:26 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <2A8EC8AF-7A4D-4335-8B35-18987A583F42@gsoft.com.au> References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> <4EBABAC1.2090003@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: -4.523 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 10 Nov 2011 00:34:36 -0000 On 10/11/2011, at 4:09, Julian Elischer wrote: > well write a driver for it.. what do you think I'm doing with the = driver I'm talking about? > I wrote several bypass network card drivers when I was at = cisco/ironport.. it's not rocket science, > though it would be nice if we were to come up with a standard = interface for bypass interfaces. > That is a different topic though.. http://info.iet.unipi.it/~luigi/netmap/ Perhaps? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:51:54 2011 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 6A4DE1065678; Thu, 10 Nov 2011 03:51: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 21FB58FC17; Thu, 10 Nov 2011 03:51:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAA3prPW005476; Wed, 9 Nov 2011 22:51:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAA3prqU005447; Thu, 10 Nov 2011 03:51:53 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 03:51:53 GMT Message-Id: <201111100351.pAA3prqU005447@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 arm/arm 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, 10 Nov 2011 03:51:54 -0000 TB --- 2011-11-10 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 02:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-10 02:10:00 - cleaning the object tree TB --- 2011-11-10 02:10:32 - cvsupping the source tree TB --- 2011-11-10 02:10:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-10 02:10:48 - building world TB --- 2011-11-10 02:10:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 02:10:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 02:10:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 02:10:48 - SRCCONF=/dev/null TB --- 2011-11-10 02:10:48 - TARGET=arm TB --- 2011-11-10 02:10:48 - TARGET_ARCH=arm TB --- 2011-11-10 02:10:48 - TZ=UTC TB --- 2011-11-10 02:10:48 - __MAKE_CONF=/dev/null TB --- 2011-11-10 02:10:48 - cd /src TB --- 2011-11-10 02:10:48 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 02:10:49 UTC 2011 >>> 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 Nov 10 03:06:49 UTC 2011 TB --- 2011-11-10 03:06:49 - cd /src/sys/arm/conf TB --- 2011-11-10 03:06:49 - /usr/sbin/config -m AVILA TB --- 2011-11-10 03:06:49 - building AVILA kernel TB --- 2011-11-10 03:06:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:06:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:06:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:06:49 - SRCCONF=/dev/null TB --- 2011-11-10 03:06:49 - TARGET=arm TB --- 2011-11-10 03:06:49 - TARGET_ARCH=arm TB --- 2011-11-10 03:06:49 - TZ=UTC TB --- 2011-11-10 03:06:49 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:06:49 - cd /src TB --- 2011-11-10 03:06:49 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 10 03:06:49 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 10 03:10:18 UTC 2011 TB --- 2011-11-10 03:10:18 - cd /src/sys/arm/conf TB --- 2011-11-10 03:10:18 - /usr/sbin/config -m BWCT TB --- 2011-11-10 03:10:18 - building BWCT kernel TB --- 2011-11-10 03:10:18 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:10:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:10:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:10:18 - SRCCONF=/dev/null TB --- 2011-11-10 03:10:18 - TARGET=arm TB --- 2011-11-10 03:10:18 - TARGET_ARCH=arm TB --- 2011-11-10 03:10:18 - TZ=UTC TB --- 2011-11-10 03:10:18 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:10:18 - cd /src TB --- 2011-11-10 03:10:18 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 10 03:10:19 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 10 03:12:26 UTC 2011 TB --- 2011-11-10 03:12:26 - cd /src/sys/arm/conf TB --- 2011-11-10 03:12:26 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-10 03:12:26 - building CAMBRIA kernel TB --- 2011-11-10 03:12:26 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:12:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:12:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:12:26 - SRCCONF=/dev/null TB --- 2011-11-10 03:12:26 - TARGET=arm TB --- 2011-11-10 03:12:26 - TARGET_ARCH=arm TB --- 2011-11-10 03:12:26 - TZ=UTC TB --- 2011-11-10 03:12:26 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:12:26 - cd /src TB --- 2011-11-10 03:12:26 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 10 03:12:26 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 10 03:15:21 UTC 2011 TB --- 2011-11-10 03:15:21 - cd /src/sys/arm/conf TB --- 2011-11-10 03:15:21 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-10 03:15:22 - building CNS11XXNAS kernel TB --- 2011-11-10 03:15:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:15:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:15:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:15:22 - SRCCONF=/dev/null TB --- 2011-11-10 03:15:22 - TARGET=arm TB --- 2011-11-10 03:15:22 - TARGET_ARCH=arm TB --- 2011-11-10 03:15:22 - TZ=UTC TB --- 2011-11-10 03:15:22 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:15:22 - cd /src TB --- 2011-11-10 03:15:22 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 10 03:15:22 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 10 03:18:20 UTC 2011 TB --- 2011-11-10 03:18:20 - cd /src/sys/arm/conf TB --- 2011-11-10 03:18:20 - /usr/sbin/config -m CRB TB --- 2011-11-10 03:18:21 - building CRB kernel TB --- 2011-11-10 03:18:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:18:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:18:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:18:21 - SRCCONF=/dev/null TB --- 2011-11-10 03:18:21 - TARGET=arm TB --- 2011-11-10 03:18:21 - TARGET_ARCH=arm TB --- 2011-11-10 03:18:21 - TZ=UTC TB --- 2011-11-10 03:18:21 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:18:21 - cd /src TB --- 2011-11-10 03:18:21 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 10 03:18:21 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 10 03:21:41 UTC 2011 TB --- 2011-11-10 03:21:41 - cd /src/sys/arm/conf TB --- 2011-11-10 03:21:41 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-10 03:21:41 - building DB-78XXX kernel TB --- 2011-11-10 03:21:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:21:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:21:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:21:41 - SRCCONF=/dev/null TB --- 2011-11-10 03:21:41 - TARGET=arm TB --- 2011-11-10 03:21:41 - TARGET_ARCH=arm TB --- 2011-11-10 03:21:41 - TZ=UTC TB --- 2011-11-10 03:21:41 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:21:41 - cd /src TB --- 2011-11-10 03:21:41 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 10 03:21:41 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 10 03:24:30 UTC 2011 TB --- 2011-11-10 03:24:30 - cd /src/sys/arm/conf TB --- 2011-11-10 03:24:30 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-10 03:24:31 - building DB-88F5XXX kernel TB --- 2011-11-10 03:24:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:24:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:24:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:24:31 - SRCCONF=/dev/null TB --- 2011-11-10 03:24:31 - TARGET=arm TB --- 2011-11-10 03:24:31 - TARGET_ARCH=arm TB --- 2011-11-10 03:24:31 - TZ=UTC TB --- 2011-11-10 03:24:31 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:24:31 - cd /src TB --- 2011-11-10 03:24:31 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 10 03:24:31 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 10 03:27:26 UTC 2011 TB --- 2011-11-10 03:27:26 - cd /src/sys/arm/conf TB --- 2011-11-10 03:27:26 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-10 03:27:26 - building DB-88F6XXX kernel TB --- 2011-11-10 03:27:26 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:27:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:27:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:27:26 - SRCCONF=/dev/null TB --- 2011-11-10 03:27:26 - TARGET=arm TB --- 2011-11-10 03:27:26 - TARGET_ARCH=arm TB --- 2011-11-10 03:27:26 - TZ=UTC TB --- 2011-11-10 03:27:26 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:27:26 - cd /src TB --- 2011-11-10 03:27:26 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 10 03:27:26 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 10 03:30:06 UTC 2011 TB --- 2011-11-10 03:30:06 - cd /src/sys/arm/conf TB --- 2011-11-10 03:30:06 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-10 03:30:06 - building DOCKSTAR kernel TB --- 2011-11-10 03:30:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:30:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:30:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:30:06 - SRCCONF=/dev/null TB --- 2011-11-10 03:30:06 - TARGET=arm TB --- 2011-11-10 03:30:06 - TARGET_ARCH=arm TB --- 2011-11-10 03:30:06 - TZ=UTC TB --- 2011-11-10 03:30:06 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:30:06 - cd /src TB --- 2011-11-10 03:30:06 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 10 03:30:06 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 10 03:33:08 UTC 2011 TB --- 2011-11-10 03:33:08 - cd /src/sys/arm/conf TB --- 2011-11-10 03:33:08 - /usr/sbin/config -m EP80219 TB --- 2011-11-10 03:33:08 - building EP80219 kernel TB --- 2011-11-10 03:33:08 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:33:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:33:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:33:08 - SRCCONF=/dev/null TB --- 2011-11-10 03:33:08 - TARGET=arm TB --- 2011-11-10 03:33:08 - TARGET_ARCH=arm TB --- 2011-11-10 03:33:08 - TZ=UTC TB --- 2011-11-10 03:33:08 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:33:08 - cd /src TB --- 2011-11-10 03:33:08 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 10 03:33:08 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 10 03:36:00 UTC 2011 TB --- 2011-11-10 03:36:00 - WARNING: no kernel config for GENERIC TB --- 2011-11-10 03:36:00 - cd /src/sys/arm/conf TB --- 2011-11-10 03:36:00 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-10 03:36:00 - building GUMSTIX kernel TB --- 2011-11-10 03:36:00 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:36:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:36:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:36:00 - SRCCONF=/dev/null TB --- 2011-11-10 03:36:00 - TARGET=arm TB --- 2011-11-10 03:36:00 - TARGET_ARCH=arm TB --- 2011-11-10 03:36:00 - TZ=UTC TB --- 2011-11-10 03:36:00 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:36:00 - cd /src TB --- 2011-11-10 03:36:00 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 10 03:36:01 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 10 03:38:19 UTC 2011 TB --- 2011-11-10 03:38:19 - cd /src/sys/arm/conf TB --- 2011-11-10 03:38:19 - /usr/sbin/config -m HL200 TB --- 2011-11-10 03:38:19 - building HL200 kernel TB --- 2011-11-10 03:38:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:38:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:38:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:38:19 - SRCCONF=/dev/null TB --- 2011-11-10 03:38:19 - TARGET=arm TB --- 2011-11-10 03:38:19 - TARGET_ARCH=arm TB --- 2011-11-10 03:38:19 - TZ=UTC TB --- 2011-11-10 03:38:19 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:38:19 - cd /src TB --- 2011-11-10 03:38:19 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 10 03:38:19 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 10 03:41:02 UTC 2011 TB --- 2011-11-10 03:41:02 - cd /src/sys/arm/conf TB --- 2011-11-10 03:41:02 - /usr/sbin/config -m HL201 TB --- 2011-11-10 03:41:02 - building HL201 kernel TB --- 2011-11-10 03:41:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:41:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:41:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:41:02 - SRCCONF=/dev/null TB --- 2011-11-10 03:41:02 - TARGET=arm TB --- 2011-11-10 03:41:02 - TARGET_ARCH=arm TB --- 2011-11-10 03:41:02 - TZ=UTC TB --- 2011-11-10 03:41:02 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:41:02 - cd /src TB --- 2011-11-10 03:41:02 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 10 03:41:02 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 10 03:43:55 UTC 2011 TB --- 2011-11-10 03:43:55 - cd /src/sys/arm/conf TB --- 2011-11-10 03:43:55 - /usr/sbin/config -m IQ31244 TB --- 2011-11-10 03:43:55 - building IQ31244 kernel TB --- 2011-11-10 03:43:55 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:43:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:43:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:43:55 - SRCCONF=/dev/null TB --- 2011-11-10 03:43:55 - TARGET=arm TB --- 2011-11-10 03:43:55 - TARGET_ARCH=arm TB --- 2011-11-10 03:43:55 - TZ=UTC TB --- 2011-11-10 03:43:55 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:43:55 - cd /src TB --- 2011-11-10 03:43:55 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 10 03:43:55 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 10 03:47:06 UTC 2011 TB --- 2011-11-10 03:47:06 - cd /src/sys/arm/conf TB --- 2011-11-10 03:47:06 - /usr/sbin/config -m KB920X TB --- 2011-11-10 03:47:07 - building KB920X kernel TB --- 2011-11-10 03:47:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:47:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:47:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:47:07 - SRCCONF=/dev/null TB --- 2011-11-10 03:47:07 - TARGET=arm TB --- 2011-11-10 03:47:07 - TARGET_ARCH=arm TB --- 2011-11-10 03:47:07 - TZ=UTC TB --- 2011-11-10 03:47:07 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:47:07 - cd /src TB --- 2011-11-10 03:47:07 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 10 03:47:08 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 03:51:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 03:51:52 - ERROR: failed to build KB920X kernel TB --- 2011-11-10 03:51:52 - 4537.62 user 1133.38 system 6112.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 04:29:54 2011 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 5F4861065676; Thu, 10 Nov 2011 04: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 2E7AB8FC15; Thu, 10 Nov 2011 04: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.4) with ESMTP id pAA4TrQT075882; Wed, 9 Nov 2011 23:29:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAA4TrQV075861; Thu, 10 Nov 2011 04:29:53 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 04:29:53 GMT Message-Id: <201111100429.pAA4TrQV075861@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: Thu, 10 Nov 2011 04:29:54 -0000 TB --- 2011-11-10 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 02:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-10 02:10:00 - cleaning the object tree TB --- 2011-11-10 02:10:28 - cvsupping the source tree TB --- 2011-11-10 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-10 02:10:45 - building world TB --- 2011-11-10 02:10:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 02:10:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 02:10:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 02:10:45 - SRCCONF=/dev/null TB --- 2011-11-10 02:10:45 - TARGET=pc98 TB --- 2011-11-10 02:10:45 - TARGET_ARCH=i386 TB --- 2011-11-10 02:10:45 - TZ=UTC TB --- 2011-11-10 02:10:45 - __MAKE_CONF=/dev/null TB --- 2011-11-10 02:10:45 - cd /src TB --- 2011-11-10 02:10:45 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 02:10:46 UTC 2011 >>> 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 Nov 10 04:21:50 UTC 2011 TB --- 2011-11-10 04:21:50 - generating LINT kernel config TB --- 2011-11-10 04:21:50 - cd /src/sys/pc98/conf TB --- 2011-11-10 04:21:50 - /usr/bin/make -B LINT TB --- 2011-11-10 04:21:50 - cd /src/sys/pc98/conf TB --- 2011-11-10 04:21:50 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 04:21:50 - building GENERIC kernel TB --- 2011-11-10 04:21:50 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 04:21:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 04:21:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 04:21:50 - SRCCONF=/dev/null TB --- 2011-11-10 04:21:50 - TARGET=pc98 TB --- 2011-11-10 04:21:50 - TARGET_ARCH=i386 TB --- 2011-11-10 04:21:50 - TZ=UTC TB --- 2011-11-10 04:21:50 - __MAKE_CONF=/dev/null TB --- 2011-11-10 04:21:50 - cd /src TB --- 2011-11-10 04:21:50 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 04:21:50 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 04:29:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 04:29:52 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 04:29:52 - 6695.27 user 1202.62 system 8392.51 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 05:32:06 2011 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 9BD101065670; Thu, 10 Nov 2011 05:32:06 +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 6ED438FC15; Thu, 10 Nov 2011 05:32:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAA5W4Ox025237; Thu, 10 Nov 2011 00:32:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAA5W4X7025228; Thu, 10 Nov 2011 05:32:04 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 05:32:04 GMT Message-Id: <201111100532.pAA5W4X7025228@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: Thu, 10 Nov 2011 05:32:06 -0000 TB --- 2011-11-10 03:51:53 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 03:51:53 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-10 03:51:53 - cleaning the object tree TB --- 2011-11-10 03:52:08 - cvsupping the source tree TB --- 2011-11-10 03:52:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-10 03:52:20 - building world TB --- 2011-11-10 03:52:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 03:52:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 03:52:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 03:52:20 - SRCCONF=/dev/null TB --- 2011-11-10 03:52:20 - TARGET=ia64 TB --- 2011-11-10 03:52:20 - TARGET_ARCH=ia64 TB --- 2011-11-10 03:52:20 - TZ=UTC TB --- 2011-11-10 03:52:20 - __MAKE_CONF=/dev/null TB --- 2011-11-10 03:52:20 - cd /src TB --- 2011-11-10 03:52:20 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 03:52:21 UTC 2011 >>> 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 Nov 10 05:21:57 UTC 2011 TB --- 2011-11-10 05:21:57 - generating LINT kernel config TB --- 2011-11-10 05:21:57 - cd /src/sys/ia64/conf TB --- 2011-11-10 05:21:57 - /usr/bin/make -B LINT TB --- 2011-11-10 05:21:57 - cd /src/sys/ia64/conf TB --- 2011-11-10 05:21:57 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 05:21:57 - building GENERIC kernel TB --- 2011-11-10 05:21:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 05:21:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 05:21:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 05:21:57 - SRCCONF=/dev/null TB --- 2011-11-10 05:21:57 - TARGET=ia64 TB --- 2011-11-10 05:21:57 - TARGET_ARCH=ia64 TB --- 2011-11-10 05:21:57 - TZ=UTC TB --- 2011-11-10 05:21:57 - __MAKE_CONF=/dev/null TB --- 2011-11-10 05:21:57 - cd /src TB --- 2011-11-10 05:21:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 05:21:57 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 05:32:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 05:32:03 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 05:32:03 - 4727.10 user 912.53 system 6009.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 06:19:34 2011 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 EE3611065740 for ; Thu, 10 Nov 2011 06:19:34 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A93478FC15 for ; Thu, 10 Nov 2011 06:19:34 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so3043654vcb.13 for ; Wed, 09 Nov 2011 22:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=rpjGdJNHZao4r7VdQKn9Y0WHbiOxKypNsHKvI4WOoIw=; b=wm6Q13aUgcKBp78bvEPqMPDuOT/bYc0NJk8USR02C4zrQ5UDa/3d6DJ8Y6WuMUbCjZ mYDm9sYCiiR1aLW6CqEl6W0IP8R5B/9CfVWZPKWhls8zYow4kGGFCggKEH+BimYpJsSb ovbZ3TBUgDR3VCGh6XuVI8o7BI8bHb6V0rLwU= Received: by 10.52.35.75 with SMTP id f11mr10381138vdj.18.1320904585287; Wed, 09 Nov 2011 21:56:25 -0800 (PST) Received: from schism.local (c-76-124-49-145.hsd1.pa.comcast.net. [76.124.49.145]) by mx.google.com with ESMTPS id bu10sm10810116vdb.3.2011.11.09.21.56.23 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 21:56:24 -0800 (PST) Message-ID: <4EBB6787.8000300@gmail.com> Date: Thu, 10 Nov 2011 00:56:23 -0500 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@freebsd.org X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 06:19:35 -0000 Hi, Netgear has these neat little USB micro wireless network adapters[1] that one could plug in and forget about without fear of, for example, breaking the device. Said devices are really nice for those of us without supported integrated wireless chipsets, such as those found in late 2010 MacBooks, or anything manufactured by Dell recently... The only problem is that the device itself is not supported. The device appears to have a RealTek RTL8188CUS chipset (vendor 0846, device 9041), which, without knowing much more about the device, I suspect could work with the urtw(4) driver. However, my feeble attempts at simulating support for the device ended, well, as expected. :) Is someone out there interested in undertaking the task of tweaking the driver code (if it's feasible in this case, of course) to get this device supported? I suspect more people than just me would be greatly appreciative of support for it. :) Thanks, Glen [1] - http://www.totobay.com/netgear-wna-1000-n-150m-wireless-usb-adapter_p29987.html -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 07:05:41 2011 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 86479106564A; Thu, 10 Nov 2011 07:05:41 +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 590C38FC0A; Thu, 10 Nov 2011 07:05:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAA75exd023296; Thu, 10 Nov 2011 02:05:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAA75eIT023291; Thu, 10 Nov 2011 07:05:40 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 07:05:40 GMT Message-Id: <201111100705.pAA75eIT023291@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/i386 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, 10 Nov 2011 07:05:41 -0000 TB --- 2011-11-10 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 02:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-10 02:10:00 - cleaning the object tree TB --- 2011-11-10 02:10:52 - cvsupping the source tree TB --- 2011-11-10 02:10:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-10 02:11:03 - building world TB --- 2011-11-10 02:11:03 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 02:11:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 02:11:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 02:11:03 - SRCCONF=/dev/null TB --- 2011-11-10 02:11:03 - TARGET=i386 TB --- 2011-11-10 02:11:03 - TARGET_ARCH=i386 TB --- 2011-11-10 02:11:03 - TZ=UTC TB --- 2011-11-10 02:11:03 - __MAKE_CONF=/dev/null TB --- 2011-11-10 02:11:03 - cd /src TB --- 2011-11-10 02:11:03 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 02:11:03 UTC 2011 >>> 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 Nov 10 04:22:28 UTC 2011 TB --- 2011-11-10 04:22:28 - generating LINT kernel config TB --- 2011-11-10 04:22:28 - cd /src/sys/i386/conf TB --- 2011-11-10 04:22:28 - /usr/bin/make -B LINT TB --- 2011-11-10 04:22:28 - cd /src/sys/i386/conf TB --- 2011-11-10 04:22:28 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-10 04:22:28 - building LINT-NOINET kernel TB --- 2011-11-10 04:22:28 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 04:22:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 04:22:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 04:22:28 - SRCCONF=/dev/null TB --- 2011-11-10 04:22:28 - TARGET=i386 TB --- 2011-11-10 04:22:28 - TARGET_ARCH=i386 TB --- 2011-11-10 04:22:28 - TZ=UTC TB --- 2011-11-10 04:22:28 - __MAKE_CONF=/dev/null TB --- 2011-11-10 04:22:28 - cd /src TB --- 2011-11-10 04:22:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 10 04:22:28 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET completed on Thu Nov 10 04:53:09 UTC 2011 TB --- 2011-11-10 04:53:09 - cd /src/sys/i386/conf TB --- 2011-11-10 04:53:09 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-10 04:53:09 - building LINT-NOINET6 kernel TB --- 2011-11-10 04:53:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 04:53:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 04:53:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 04:53:09 - SRCCONF=/dev/null TB --- 2011-11-10 04:53:09 - TARGET=i386 TB --- 2011-11-10 04:53:09 - TARGET_ARCH=i386 TB --- 2011-11-10 04:53:09 - TZ=UTC TB --- 2011-11-10 04:53:09 - __MAKE_CONF=/dev/null TB --- 2011-11-10 04:53:09 - cd /src TB --- 2011-11-10 04:53:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Nov 10 04:53:09 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET6 completed on Thu Nov 10 05:23:36 UTC 2011 TB --- 2011-11-10 05:23:36 - cd /src/sys/i386/conf TB --- 2011-11-10 05:23:36 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-10 05:23:36 - building LINT-NOIP kernel TB --- 2011-11-10 05:23:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 05:23:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 05:23:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 05:23:36 - SRCCONF=/dev/null TB --- 2011-11-10 05:23:36 - TARGET=i386 TB --- 2011-11-10 05:23:36 - TARGET_ARCH=i386 TB --- 2011-11-10 05:23:36 - TZ=UTC TB --- 2011-11-10 05:23:36 - __MAKE_CONF=/dev/null TB --- 2011-11-10 05:23:36 - cd /src TB --- 2011-11-10 05:23:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Nov 10 05:23:36 UTC 2011 >>> 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 >>> Kernel build for LINT-NOIP completed on Thu Nov 10 05:52:09 UTC 2011 TB --- 2011-11-10 05:52:09 - cd /src/sys/i386/conf TB --- 2011-11-10 05:52:09 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-10 05:52:09 - building LINT-VIMAGE kernel TB --- 2011-11-10 05:52:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 05:52:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 05:52:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 05:52:09 - SRCCONF=/dev/null TB --- 2011-11-10 05:52:09 - TARGET=i386 TB --- 2011-11-10 05:52:09 - TARGET_ARCH=i386 TB --- 2011-11-10 05:52:09 - TZ=UTC TB --- 2011-11-10 05:52:09 - __MAKE_CONF=/dev/null TB --- 2011-11-10 05:52:09 - cd /src TB --- 2011-11-10 05:52:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Nov 10 05:52:09 UTC 2011 >>> 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 >>> Kernel build for LINT-VIMAGE completed on Thu Nov 10 06:23:24 UTC 2011 TB --- 2011-11-10 06:23:25 - cd /src/sys/i386/conf TB --- 2011-11-10 06:23:25 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 06:23:25 - building GENERIC kernel TB --- 2011-11-10 06:23:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 06:23:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 06:23:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 06:23:25 - SRCCONF=/dev/null TB --- 2011-11-10 06:23:25 - TARGET=i386 TB --- 2011-11-10 06:23:25 - TARGET_ARCH=i386 TB --- 2011-11-10 06:23:25 - TZ=UTC TB --- 2011-11-10 06:23:25 - __MAKE_CONF=/dev/null TB --- 2011-11-10 06:23:25 - cd /src TB --- 2011-11-10 06:23:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 06:23:25 UTC 2011 >>> 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 >>> Kernel build for GENERIC completed on Thu Nov 10 06:48:25 UTC 2011 TB --- 2011-11-10 06:48:25 - cd /src/sys/i386/conf TB --- 2011-11-10 06:48:25 - /usr/sbin/config -m PAE TB --- 2011-11-10 06:48:25 - building PAE kernel TB --- 2011-11-10 06:48:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 06:48:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 06:48:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 06:48:25 - SRCCONF=/dev/null TB --- 2011-11-10 06:48:25 - TARGET=i386 TB --- 2011-11-10 06:48:25 - TARGET_ARCH=i386 TB --- 2011-11-10 06:48:25 - TZ=UTC TB --- 2011-11-10 06:48:25 - __MAKE_CONF=/dev/null TB --- 2011-11-10 06:48:25 - cd /src TB --- 2011-11-10 06:48:25 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Thu Nov 10 06:48:25 UTC 2011 >>> 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 >>> Kernel build for PAE completed on Thu Nov 10 06:55:10 UTC 2011 TB --- 2011-11-10 06:55:10 - cd /src/sys/i386/conf TB --- 2011-11-10 06:55:10 - /usr/sbin/config -m XBOX TB --- 2011-11-10 06:55:10 - building XBOX kernel TB --- 2011-11-10 06:55:10 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 06:55:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 06:55:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 06:55:10 - SRCCONF=/dev/null TB --- 2011-11-10 06:55:10 - TARGET=i386 TB --- 2011-11-10 06:55:10 - TARGET_ARCH=i386 TB --- 2011-11-10 06:55:10 - TZ=UTC TB --- 2011-11-10 06:55:10 - __MAKE_CONF=/dev/null TB --- 2011-11-10 06:55:10 - cd /src TB --- 2011-11-10 06:55:10 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Thu Nov 10 06:55:10 UTC 2011 >>> 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 >>> Kernel build for XBOX completed on Thu Nov 10 06:58:25 UTC 2011 TB --- 2011-11-10 06:58:25 - cd /src/sys/i386/conf TB --- 2011-11-10 06:58:25 - /usr/sbin/config -m XEN TB --- 2011-11-10 06:58:25 - building XEN kernel TB --- 2011-11-10 06:58:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 06:58:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 06:58:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 06:58:25 - SRCCONF=/dev/null TB --- 2011-11-10 06:58:25 - TARGET=i386 TB --- 2011-11-10 06:58:25 - TARGET_ARCH=i386 TB --- 2011-11-10 06:58:25 - TZ=UTC TB --- 2011-11-10 06:58:25 - __MAKE_CONF=/dev/null TB --- 2011-11-10 06:58:25 - cd /src TB --- 2011-11-10 06:58:25 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Thu Nov 10 06:58:25 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 07:05:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 07:05:39 - ERROR: failed to build XEN kernel TB --- 2011-11-10 07:05:39 - 14136.47 user 2447.81 system 17739.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 07:15:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 968F5106564A; Thu, 10 Nov 2011 07:15:23 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BB2CF14F438; Thu, 10 Nov 2011 07:15:22 +0000 (UTC) Message-ID: <4EBB7A0A.20700@FreeBSD.org> Date: Wed, 09 Nov 2011 23:15:22 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: FreeBSD Tinderbox References: <201111100705.pAA75eIT023291@freebsd-current.sentex.ca> In-Reply-To: <201111100705.pAA75eIT023291@freebsd-current.sentex.ca> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: adrian@FreeBSD.org, current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 10 Nov 2011 07:15:23 -0000 Adrian, This has been going on for a while. Are you subscribed to -current? Any plans to fix this? Doug On 11/09/2011 23:05, FreeBSD Tinderbox wrote: > TB --- 2011-11-10 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca > TB --- 2011-11-10 02:10:00 - starting HEAD tinderbox run for i386/i386 > TB --- 2011-11-10 02:10:00 - cleaning the object tree > TB --- 2011-11-10 02:10:52 - cvsupping the source tree > TB --- 2011-11-10 02:10:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile > TB --- 2011-11-10 02:11:03 - building world > TB --- 2011-11-10 02:11:03 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 02:11:03 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 02:11:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 02:11:03 - SRCCONF=/dev/null > TB --- 2011-11-10 02:11:03 - TARGET=i386 > TB --- 2011-11-10 02:11:03 - TARGET_ARCH=i386 > TB --- 2011-11-10 02:11:03 - TZ=UTC > TB --- 2011-11-10 02:11:03 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 02:11:03 - cd /src > TB --- 2011-11-10 02:11:03 - /usr/bin/make -B buildworld >>>> World build started on Thu Nov 10 02:11:03 UTC 2011 >>>> 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 Nov 10 04:22:28 UTC 2011 > TB --- 2011-11-10 04:22:28 - generating LINT kernel config > TB --- 2011-11-10 04:22:28 - cd /src/sys/i386/conf > TB --- 2011-11-10 04:22:28 - /usr/bin/make -B LINT > TB --- 2011-11-10 04:22:28 - cd /src/sys/i386/conf > TB --- 2011-11-10 04:22:28 - /usr/sbin/config -m LINT-NOINET > TB --- 2011-11-10 04:22:28 - building LINT-NOINET kernel > TB --- 2011-11-10 04:22:28 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 04:22:28 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 04:22:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 04:22:28 - SRCCONF=/dev/null > TB --- 2011-11-10 04:22:28 - TARGET=i386 > TB --- 2011-11-10 04:22:28 - TARGET_ARCH=i386 > TB --- 2011-11-10 04:22:28 - TZ=UTC > TB --- 2011-11-10 04:22:28 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 04:22:28 - cd /src > TB --- 2011-11-10 04:22:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>>> Kernel build for LINT-NOINET started on Thu Nov 10 04:22:28 UTC 2011 >>>> 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 >>>> Kernel build for LINT-NOINET completed on Thu Nov 10 04:53:09 UTC 2011 > TB --- 2011-11-10 04:53:09 - cd /src/sys/i386/conf > TB --- 2011-11-10 04:53:09 - /usr/sbin/config -m LINT-NOINET6 > TB --- 2011-11-10 04:53:09 - building LINT-NOINET6 kernel > TB --- 2011-11-10 04:53:09 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 04:53:09 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 04:53:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 04:53:09 - SRCCONF=/dev/null > TB --- 2011-11-10 04:53:09 - TARGET=i386 > TB --- 2011-11-10 04:53:09 - TARGET_ARCH=i386 > TB --- 2011-11-10 04:53:09 - TZ=UTC > TB --- 2011-11-10 04:53:09 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 04:53:09 - cd /src > TB --- 2011-11-10 04:53:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>>> Kernel build for LINT-NOINET6 started on Thu Nov 10 04:53:09 UTC 2011 >>>> 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 >>>> Kernel build for LINT-NOINET6 completed on Thu Nov 10 05:23:36 UTC 2011 > TB --- 2011-11-10 05:23:36 - cd /src/sys/i386/conf > TB --- 2011-11-10 05:23:36 - /usr/sbin/config -m LINT-NOIP > TB --- 2011-11-10 05:23:36 - building LINT-NOIP kernel > TB --- 2011-11-10 05:23:36 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 05:23:36 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 05:23:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 05:23:36 - SRCCONF=/dev/null > TB --- 2011-11-10 05:23:36 - TARGET=i386 > TB --- 2011-11-10 05:23:36 - TARGET_ARCH=i386 > TB --- 2011-11-10 05:23:36 - TZ=UTC > TB --- 2011-11-10 05:23:36 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 05:23:36 - cd /src > TB --- 2011-11-10 05:23:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>>> Kernel build for LINT-NOIP started on Thu Nov 10 05:23:36 UTC 2011 >>>> 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 >>>> Kernel build for LINT-NOIP completed on Thu Nov 10 05:52:09 UTC 2011 > TB --- 2011-11-10 05:52:09 - cd /src/sys/i386/conf > TB --- 2011-11-10 05:52:09 - /usr/sbin/config -m LINT-VIMAGE > TB --- 2011-11-10 05:52:09 - building LINT-VIMAGE kernel > TB --- 2011-11-10 05:52:09 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 05:52:09 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 05:52:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 05:52:09 - SRCCONF=/dev/null > TB --- 2011-11-10 05:52:09 - TARGET=i386 > TB --- 2011-11-10 05:52:09 - TARGET_ARCH=i386 > TB --- 2011-11-10 05:52:09 - TZ=UTC > TB --- 2011-11-10 05:52:09 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 05:52:09 - cd /src > TB --- 2011-11-10 05:52:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>>> Kernel build for LINT-VIMAGE started on Thu Nov 10 05:52:09 UTC 2011 >>>> 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 >>>> Kernel build for LINT-VIMAGE completed on Thu Nov 10 06:23:24 UTC 2011 > TB --- 2011-11-10 06:23:25 - cd /src/sys/i386/conf > TB --- 2011-11-10 06:23:25 - /usr/sbin/config -m GENERIC > TB --- 2011-11-10 06:23:25 - building GENERIC kernel > TB --- 2011-11-10 06:23:25 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 06:23:25 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 06:23:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 06:23:25 - SRCCONF=/dev/null > TB --- 2011-11-10 06:23:25 - TARGET=i386 > TB --- 2011-11-10 06:23:25 - TARGET_ARCH=i386 > TB --- 2011-11-10 06:23:25 - TZ=UTC > TB --- 2011-11-10 06:23:25 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 06:23:25 - cd /src > TB --- 2011-11-10 06:23:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>>> Kernel build for GENERIC started on Thu Nov 10 06:23:25 UTC 2011 >>>> 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 >>>> Kernel build for GENERIC completed on Thu Nov 10 06:48:25 UTC 2011 > TB --- 2011-11-10 06:48:25 - cd /src/sys/i386/conf > TB --- 2011-11-10 06:48:25 - /usr/sbin/config -m PAE > TB --- 2011-11-10 06:48:25 - building PAE kernel > TB --- 2011-11-10 06:48:25 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 06:48:25 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 06:48:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 06:48:25 - SRCCONF=/dev/null > TB --- 2011-11-10 06:48:25 - TARGET=i386 > TB --- 2011-11-10 06:48:25 - TARGET_ARCH=i386 > TB --- 2011-11-10 06:48:25 - TZ=UTC > TB --- 2011-11-10 06:48:25 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 06:48:25 - cd /src > TB --- 2011-11-10 06:48:25 - /usr/bin/make -B buildkernel KERNCONF=PAE >>>> Kernel build for PAE started on Thu Nov 10 06:48:25 UTC 2011 >>>> 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 >>>> Kernel build for PAE completed on Thu Nov 10 06:55:10 UTC 2011 > TB --- 2011-11-10 06:55:10 - cd /src/sys/i386/conf > TB --- 2011-11-10 06:55:10 - /usr/sbin/config -m XBOX > TB --- 2011-11-10 06:55:10 - building XBOX kernel > TB --- 2011-11-10 06:55:10 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 06:55:10 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 06:55:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 06:55:10 - SRCCONF=/dev/null > TB --- 2011-11-10 06:55:10 - TARGET=i386 > TB --- 2011-11-10 06:55:10 - TARGET_ARCH=i386 > TB --- 2011-11-10 06:55:10 - TZ=UTC > TB --- 2011-11-10 06:55:10 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 06:55:10 - cd /src > TB --- 2011-11-10 06:55:10 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>>> Kernel build for XBOX started on Thu Nov 10 06:55:10 UTC 2011 >>>> 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 >>>> Kernel build for XBOX completed on Thu Nov 10 06:58:25 UTC 2011 > TB --- 2011-11-10 06:58:25 - cd /src/sys/i386/conf > TB --- 2011-11-10 06:58:25 - /usr/sbin/config -m XEN > TB --- 2011-11-10 06:58:25 - building XEN kernel > TB --- 2011-11-10 06:58:25 - CROSS_BUILD_TESTING=YES > TB --- 2011-11-10 06:58:25 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-11-10 06:58:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-10 06:58:25 - SRCCONF=/dev/null > TB --- 2011-11-10 06:58:25 - TARGET=i386 > TB --- 2011-11-10 06:58:25 - TARGET_ARCH=i386 > TB --- 2011-11-10 06:58:25 - TZ=UTC > TB --- 2011-11-10 06:58:25 - __MAKE_CONF=/dev/null > TB --- 2011-11-10 06:58:25 - cd /src > TB --- 2011-11-10 06:58:25 - /usr/bin/make -B buildkernel KERNCONF=XEN >>>> Kernel build for XEN started on Thu Nov 10 06:58:25 UTC 2011 >>>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': > /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' > /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' > /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' > /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' > /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' > /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' > /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' > *** Error code 1 > > Stop in /src/sys/modules/ath. > *** Error code 1 > > Stop in /src/sys/modules. > *** Error code 1 > > Stop in /obj/i386.i386/src/sys/XEN. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2011-11-10 07:05:39 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2011-11-10 07:05:39 - ERROR: failed to build XEN kernel > TB --- 2011-11-10 07:05:39 - 14136.47 user 2447.81 system 17739.35 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.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" > -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 07:23:05 2011 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 8FF90106564A; Thu, 10 Nov 2011 07:23:05 +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 6289A8FC16; Thu, 10 Nov 2011 07:23:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAA7N4DX043301; Thu, 10 Nov 2011 02:23:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAA7N4lP043284; Thu, 10 Nov 2011 07:23:04 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 07:23:04 GMT Message-Id: <201111100723.pAA7N4lP043284@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, 10 Nov 2011 07:23:05 -0000 TB --- 2011-11-10 05:32:04 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 05:32:04 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-10 05:32:04 - cleaning the object tree TB --- 2011-11-10 05:32:24 - cvsupping the source tree TB --- 2011-11-10 05:32:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-10 05:32:43 - building world TB --- 2011-11-10 05:32:43 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 05:32:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 05:32:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 05:32:43 - SRCCONF=/dev/null TB --- 2011-11-10 05:32:43 - TARGET=powerpc TB --- 2011-11-10 05:32:43 - TARGET_ARCH=powerpc64 TB --- 2011-11-10 05:32:43 - TZ=UTC TB --- 2011-11-10 05:32:43 - __MAKE_CONF=/dev/null TB --- 2011-11-10 05:32:43 - cd /src TB --- 2011-11-10 05:32:43 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 05:32:44 UTC 2011 >>> 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 Nov 10 07:14:55 UTC 2011 TB --- 2011-11-10 07:14:55 - generating LINT kernel config TB --- 2011-11-10 07:14:56 - cd /src/sys/powerpc/conf TB --- 2011-11-10 07:14:56 - /usr/bin/make -B LINT TB --- 2011-11-10 07:14:56 - cd /src/sys/powerpc/conf TB --- 2011-11-10 07:14:56 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 07:14:56 - skipping GENERIC kernel TB --- 2011-11-10 07:14:56 - cd /src/sys/powerpc/conf TB --- 2011-11-10 07:14:56 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-10 07:14:56 - building GENERIC64 kernel TB --- 2011-11-10 07:14:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 07:14:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 07:14:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 07:14:56 - SRCCONF=/dev/null TB --- 2011-11-10 07:14:56 - TARGET=powerpc TB --- 2011-11-10 07:14:56 - TARGET_ARCH=powerpc64 TB --- 2011-11-10 07:14:56 - TZ=UTC TB --- 2011-11-10 07:14:56 - __MAKE_CONF=/dev/null TB --- 2011-11-10 07:14:56 - cd /src TB --- 2011-11-10 07:14:56 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 10 07:14:56 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 07:23:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 07:23:04 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-10 07:23:04 - 4958.12 user 1139.49 system 6660.10 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 07:38:50 2011 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 92F421065676; Thu, 10 Nov 2011 07:38:50 +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 5E6678FC12; Thu, 10 Nov 2011 07:38:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAA7cncA025089; Thu, 10 Nov 2011 02:38:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAA7cnEv025072; Thu, 10 Nov 2011 07:38:49 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 07:38:49 GMT Message-Id: <201111100738.pAA7cnEv025072@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, 10 Nov 2011 07:38:50 -0000 TB --- 2011-11-10 05:30:19 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 05:30:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-10 05:30:19 - cleaning the object tree TB --- 2011-11-10 05:30:32 - cvsupping the source tree TB --- 2011-11-10 05:30:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-10 05:31:23 - building world TB --- 2011-11-10 05:31:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 05:31:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 05:31:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 05:31:23 - SRCCONF=/dev/null TB --- 2011-11-10 05:31:23 - TARGET=powerpc TB --- 2011-11-10 05:31:23 - TARGET_ARCH=powerpc TB --- 2011-11-10 05:31:23 - TZ=UTC TB --- 2011-11-10 05:31:23 - __MAKE_CONF=/dev/null TB --- 2011-11-10 05:31:23 - cd /src TB --- 2011-11-10 05:31:23 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 05:31:24 UTC 2011 >>> 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 Nov 10 07:32:38 UTC 2011 TB --- 2011-11-10 07:32:38 - generating LINT kernel config TB --- 2011-11-10 07:32:38 - cd /src/sys/powerpc/conf TB --- 2011-11-10 07:32:38 - /usr/bin/make -B LINT TB --- 2011-11-10 07:32:38 - cd /src/sys/powerpc/conf TB --- 2011-11-10 07:32:38 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 07:32:38 - building GENERIC kernel TB --- 2011-11-10 07:32:38 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 07:32:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 07:32:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 07:32:38 - SRCCONF=/dev/null TB --- 2011-11-10 07:32:38 - TARGET=powerpc TB --- 2011-11-10 07:32:38 - TARGET_ARCH=powerpc TB --- 2011-11-10 07:32:38 - TZ=UTC TB --- 2011-11-10 07:32:38 - __MAKE_CONF=/dev/null TB --- 2011-11-10 07:32:38 - cd /src TB --- 2011-11-10 07:32:38 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 07:32:38 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 07:38:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 07:38:49 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 07:38:49 - 6230.30 user 1044.21 system 7710.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 08:30:05 2011 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 960A8106566B for ; Thu, 10 Nov 2011 08:30:05 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm17-vm0.bullet.mail.sp2.yahoo.com (nm17-vm0.bullet.mail.sp2.yahoo.com [98.139.91.212]) by mx1.freebsd.org (Postfix) with SMTP id 58C178FC18 for ; Thu, 10 Nov 2011 08:30:05 +0000 (UTC) Received: from [98.139.91.70] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 10 Nov 2011 08:16:31 -0000 Received: from [98.136.185.28] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 10 Nov 2011 08:16:31 -0000 Received: from [127.0.0.1] by smtp109.mail.gq1.yahoo.com with NNFMP; 10 Nov 2011 08:16:31 -0000 X-Yahoo-Newman-Id: 520237.13185.bm@smtp109.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nl93w3EVM1mTX_iKzxl.0DKS4IBM8K_Kq51wzBwyfDXdRg8 kbm0.osIGIEc_udUDcKuot4MYFV_uhuBfjVM8F29gaymBAWwgagzdVLh7uqo iJDXYQ6SOKwQmX.yNg3x3FnH1_xMN0OoPIxEUzA1AP85Sve3AItHCo6JBXeU Amg6TfYHEE4ltZ2hYs7TFslkOn_VUN5lvL7pj6lBTY7UABdi.MVf2jtY09t5 1x5TRgThgN2ca4iJaYoetofC9Xyesd._DX47884a9wG1oQG7aDfV.jj5qNMI .I4s8ZNzhJZQKUwAYOQ3BPnBB34zir4fn3wsOSe4ksUTmTnb_yyjKWeyd8Hp 6CujvSQB7aw.HFIjoEXZdkzNe2jd3DuswdxVTzFnhUk9sCAUrqY8UNhlli1b 31z4icCg4dx2Pv9Y- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.153.182 with plain) by smtp109.mail.gq1.yahoo.com with SMTP; 10 Nov 2011 00:16:31 -0800 PST Message-ID: <4EBB885E.9060908@freebsd.org> Date: Thu, 10 Nov 2011 09:16:30 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT 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, 10 Nov 2011 08:30:05 -0000 For a few weeks I have been suffering from a problem that requires manual intervention to get my home workstation boot -CURRENT. The kernel panics at varying places and with different panic messages, e.g. (hand transcribed since kernel dumps don't work at that stage): privileged instruction fault while in kernel mode kmem_alloc_nofault +0x37 kmem_init +0x9e vm_kmem_init +0x39 mi_startup +0x77 btext +0x2c On another cold boot attempt: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode elf_relocinternal +0xa8 link_elf_reloc_local +0x2fe link_elf_link_preload +0x69d linker_preload +0x101 mi_startup +0x77 btext +0x2c In all the cases observed, the system starts without any problems on second attempt (pressing RESET or the reboot command in the debugger). The system is working reliably, once booted. This started a few weeks back (after the switch-over to 10-CURRENT, IIRC), and I did not bother to report it at the time, since I thought it was caused by a temporary instability in the code base. The system is an i2600K on ASUS P8H67-M EVO with 8GB of RAM and an amd64 kernel booting from ZFS (gptzfsboot). The kernel is a stripped down GENERIC plus IPFW and ath (but I doubt that the configuration is causing this, since the failure happens before any devices are probed and the identically configured kernels used to cold boot just fine for half a year). Any hint how to further diagnose this case is welcome (but my spare time is very limited and I cannot easily bisect to find a revision that boots, for example). I can produce further debug output on demand, but I do not have a serial or firewire console setup for debugging. Is anybody else affected by this boot problem? Regards, STefan From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 08:41:33 2011 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 8ACF5106566B; Thu, 10 Nov 2011 08:41:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id DA3D68FC08; Thu, 10 Nov 2011 08:41:32 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 201513843; Thu, 10 Nov 2011 09:41:30 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 10 Nov 2011 09:38:39 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EBB6787.8000300@gmail.com> In-Reply-To: <4EBB6787.8000300@gmail.com> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111100938.39891.hselasky@c2i.net> Cc: Glen Barber , current@freebsd.org Subject: Re: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 08:41:33 -0000 On Thursday 10 November 2011 06:56:23 Glen Barber wrote: > Hi, > > Netgear has these neat little USB micro wireless network adapters[1] > that one could plug in and forget about without fear of, for example, > breaking the device. > > Said devices are really nice for those of us without supported > integrated wireless chipsets, such as those found in late 2010 MacBooks, > or anything manufactured by Dell recently... > > The only problem is that the device itself is not supported. > > The device appears to have a RealTek RTL8188CUS chipset (vendor 0846, > device 9041), which, without knowing much more about the device, I > suspect could work with the urtw(4) driver. However, my feeble attempts > at simulating support for the device ended, well, as expected. :) > > Is someone out there interested in undertaking the task of tweaking the > driver code (if it's feasible in this case, of course) to get this > device supported? I suspect more people than just me would be greatly > appreciative of support for it. :) > > Thanks, > > Glen > > [1] - > http://www.totobay.com/netgear-wna-1000-n-150m-wireless-usb-adapter_p29987. > html Hi, Could you dump the device descriptor using usbconfig and Google the .idVendor and .idProduct values? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 08:41:33 2011 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 8ACF5106566B; Thu, 10 Nov 2011 08:41:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id DA3D68FC08; Thu, 10 Nov 2011 08:41:32 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 201513843; Thu, 10 Nov 2011 09:41:30 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 10 Nov 2011 09:38:39 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EBB6787.8000300@gmail.com> In-Reply-To: <4EBB6787.8000300@gmail.com> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111100938.39891.hselasky@c2i.net> Cc: Glen Barber , current@freebsd.org Subject: Re: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 08:41:33 -0000 On Thursday 10 November 2011 06:56:23 Glen Barber wrote: > Hi, > > Netgear has these neat little USB micro wireless network adapters[1] > that one could plug in and forget about without fear of, for example, > breaking the device. > > Said devices are really nice for those of us without supported > integrated wireless chipsets, such as those found in late 2010 MacBooks, > or anything manufactured by Dell recently... > > The only problem is that the device itself is not supported. > > The device appears to have a RealTek RTL8188CUS chipset (vendor 0846, > device 9041), which, without knowing much more about the device, I > suspect could work with the urtw(4) driver. However, my feeble attempts > at simulating support for the device ended, well, as expected. :) > > Is someone out there interested in undertaking the task of tweaking the > driver code (if it's feasible in this case, of course) to get this > device supported? I suspect more people than just me would be greatly > appreciative of support for it. :) > > Thanks, > > Glen > > [1] - > http://www.totobay.com/netgear-wna-1000-n-150m-wireless-usb-adapter_p29987. > html Hi, Could you dump the device descriptor using usbconfig and Google the .idVendor and .idProduct values? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 10:11:24 2011 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 B7EA1106564A; Thu, 10 Nov 2011 10:11: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 6B3028FC17; Thu, 10 Nov 2011 10:11:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAABN7X040920; Thu, 10 Nov 2011 05:11:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAABN1N040904; Thu, 10 Nov 2011 10:11:23 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 10:11:23 GMT Message-Id: <201111101011.pAAABN1N040904@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 arm/arm 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, 10 Nov 2011 10:11:24 -0000 TB --- 2011-11-10 08:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 08:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-10 08:30:00 - cleaning the object tree TB --- 2011-11-10 08:30:23 - cvsupping the source tree TB --- 2011-11-10 08:30:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-10 08:31:06 - building world TB --- 2011-11-10 08:31:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 08:31:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 08:31:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 08:31:06 - SRCCONF=/dev/null TB --- 2011-11-10 08:31:06 - TARGET=arm TB --- 2011-11-10 08:31:06 - TARGET_ARCH=arm TB --- 2011-11-10 08:31:06 - TZ=UTC TB --- 2011-11-10 08:31:06 - __MAKE_CONF=/dev/null TB --- 2011-11-10 08:31:06 - cd /src TB --- 2011-11-10 08:31:06 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 08:31:07 UTC 2011 >>> 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 Nov 10 09:26:40 UTC 2011 TB --- 2011-11-10 09:26:40 - cd /src/sys/arm/conf TB --- 2011-11-10 09:26:40 - /usr/sbin/config -m AVILA TB --- 2011-11-10 09:26:40 - building AVILA kernel TB --- 2011-11-10 09:26:40 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:26:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:26:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:26:40 - SRCCONF=/dev/null TB --- 2011-11-10 09:26:40 - TARGET=arm TB --- 2011-11-10 09:26:40 - TARGET_ARCH=arm TB --- 2011-11-10 09:26:40 - TZ=UTC TB --- 2011-11-10 09:26:40 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:26:40 - cd /src TB --- 2011-11-10 09:26:40 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 10 09:26:40 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 10 09:29:41 UTC 2011 TB --- 2011-11-10 09:29:41 - cd /src/sys/arm/conf TB --- 2011-11-10 09:29:41 - /usr/sbin/config -m BWCT TB --- 2011-11-10 09:29:41 - building BWCT kernel TB --- 2011-11-10 09:29:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:29:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:29:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:29:41 - SRCCONF=/dev/null TB --- 2011-11-10 09:29:41 - TARGET=arm TB --- 2011-11-10 09:29:41 - TARGET_ARCH=arm TB --- 2011-11-10 09:29:41 - TZ=UTC TB --- 2011-11-10 09:29:41 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:29:41 - cd /src TB --- 2011-11-10 09:29:41 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 10 09:29:41 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 10 09:32:19 UTC 2011 TB --- 2011-11-10 09:32:19 - cd /src/sys/arm/conf TB --- 2011-11-10 09:32:19 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-10 09:32:19 - building CAMBRIA kernel TB --- 2011-11-10 09:32:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:32:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:32:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:32:19 - SRCCONF=/dev/null TB --- 2011-11-10 09:32:19 - TARGET=arm TB --- 2011-11-10 09:32:19 - TARGET_ARCH=arm TB --- 2011-11-10 09:32:19 - TZ=UTC TB --- 2011-11-10 09:32:19 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:32:19 - cd /src TB --- 2011-11-10 09:32:19 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 10 09:32:19 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 10 09:35:16 UTC 2011 TB --- 2011-11-10 09:35:16 - cd /src/sys/arm/conf TB --- 2011-11-10 09:35:16 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-10 09:35:16 - building CNS11XXNAS kernel TB --- 2011-11-10 09:35:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:35:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:35:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:35:16 - SRCCONF=/dev/null TB --- 2011-11-10 09:35:16 - TARGET=arm TB --- 2011-11-10 09:35:16 - TARGET_ARCH=arm TB --- 2011-11-10 09:35:16 - TZ=UTC TB --- 2011-11-10 09:35:16 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:35:16 - cd /src TB --- 2011-11-10 09:35:16 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 10 09:35:16 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 10 09:37:43 UTC 2011 TB --- 2011-11-10 09:37:43 - cd /src/sys/arm/conf TB --- 2011-11-10 09:37:43 - /usr/sbin/config -m CRB TB --- 2011-11-10 09:37:44 - building CRB kernel TB --- 2011-11-10 09:37:44 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:37:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:37:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:37:44 - SRCCONF=/dev/null TB --- 2011-11-10 09:37:44 - TARGET=arm TB --- 2011-11-10 09:37:44 - TARGET_ARCH=arm TB --- 2011-11-10 09:37:44 - TZ=UTC TB --- 2011-11-10 09:37:44 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:37:44 - cd /src TB --- 2011-11-10 09:37:44 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 10 09:37:44 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 10 09:41:33 UTC 2011 TB --- 2011-11-10 09:41:33 - cd /src/sys/arm/conf TB --- 2011-11-10 09:41:33 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-10 09:41:33 - building DB-78XXX kernel TB --- 2011-11-10 09:41:33 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:41:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:41:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:41:33 - SRCCONF=/dev/null TB --- 2011-11-10 09:41:33 - TARGET=arm TB --- 2011-11-10 09:41:33 - TARGET_ARCH=arm TB --- 2011-11-10 09:41:33 - TZ=UTC TB --- 2011-11-10 09:41:33 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:41:33 - cd /src TB --- 2011-11-10 09:41:33 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 10 09:41:33 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 10 09:44:16 UTC 2011 TB --- 2011-11-10 09:44:16 - cd /src/sys/arm/conf TB --- 2011-11-10 09:44:16 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-10 09:44:16 - building DB-88F5XXX kernel TB --- 2011-11-10 09:44:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:44:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:44:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:44:16 - SRCCONF=/dev/null TB --- 2011-11-10 09:44:16 - TARGET=arm TB --- 2011-11-10 09:44:16 - TARGET_ARCH=arm TB --- 2011-11-10 09:44:16 - TZ=UTC TB --- 2011-11-10 09:44:16 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:44:16 - cd /src TB --- 2011-11-10 09:44:16 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 10 09:44:16 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 10 09:46:56 UTC 2011 TB --- 2011-11-10 09:46:56 - cd /src/sys/arm/conf TB --- 2011-11-10 09:46:56 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-10 09:46:56 - building DB-88F6XXX kernel TB --- 2011-11-10 09:46:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:46:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:46:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:46:56 - SRCCONF=/dev/null TB --- 2011-11-10 09:46:56 - TARGET=arm TB --- 2011-11-10 09:46:56 - TARGET_ARCH=arm TB --- 2011-11-10 09:46:56 - TZ=UTC TB --- 2011-11-10 09:46:56 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:46:56 - cd /src TB --- 2011-11-10 09:46:56 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 10 09:46:56 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 10 09:50:03 UTC 2011 TB --- 2011-11-10 09:50:03 - cd /src/sys/arm/conf TB --- 2011-11-10 09:50:03 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-10 09:50:03 - building DOCKSTAR kernel TB --- 2011-11-10 09:50:03 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:50:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:50:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:50:03 - SRCCONF=/dev/null TB --- 2011-11-10 09:50:03 - TARGET=arm TB --- 2011-11-10 09:50:03 - TARGET_ARCH=arm TB --- 2011-11-10 09:50:03 - TZ=UTC TB --- 2011-11-10 09:50:03 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:50:03 - cd /src TB --- 2011-11-10 09:50:03 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 10 09:50:03 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 10 09:52:37 UTC 2011 TB --- 2011-11-10 09:52:37 - cd /src/sys/arm/conf TB --- 2011-11-10 09:52:37 - /usr/sbin/config -m EP80219 TB --- 2011-11-10 09:52:37 - building EP80219 kernel TB --- 2011-11-10 09:52:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:52:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:52:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:52:37 - SRCCONF=/dev/null TB --- 2011-11-10 09:52:37 - TARGET=arm TB --- 2011-11-10 09:52:37 - TARGET_ARCH=arm TB --- 2011-11-10 09:52:37 - TZ=UTC TB --- 2011-11-10 09:52:37 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:52:37 - cd /src TB --- 2011-11-10 09:52:37 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 10 09:52:37 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 10 09:55:29 UTC 2011 TB --- 2011-11-10 09:55:30 - WARNING: no kernel config for GENERIC TB --- 2011-11-10 09:55:30 - cd /src/sys/arm/conf TB --- 2011-11-10 09:55:30 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-10 09:55:30 - building GUMSTIX kernel TB --- 2011-11-10 09:55:30 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:55:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:55:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:55:30 - SRCCONF=/dev/null TB --- 2011-11-10 09:55:30 - TARGET=arm TB --- 2011-11-10 09:55:30 - TARGET_ARCH=arm TB --- 2011-11-10 09:55:30 - TZ=UTC TB --- 2011-11-10 09:55:30 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:55:30 - cd /src TB --- 2011-11-10 09:55:30 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 10 09:55:30 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 10 09:57:53 UTC 2011 TB --- 2011-11-10 09:57:53 - cd /src/sys/arm/conf TB --- 2011-11-10 09:57:53 - /usr/sbin/config -m HL200 TB --- 2011-11-10 09:57:53 - building HL200 kernel TB --- 2011-11-10 09:57:53 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 09:57:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 09:57:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 09:57:53 - SRCCONF=/dev/null TB --- 2011-11-10 09:57:53 - TARGET=arm TB --- 2011-11-10 09:57:53 - TARGET_ARCH=arm TB --- 2011-11-10 09:57:53 - TZ=UTC TB --- 2011-11-10 09:57:53 - __MAKE_CONF=/dev/null TB --- 2011-11-10 09:57:53 - cd /src TB --- 2011-11-10 09:57:53 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 10 09:57:54 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 10 10:00:52 UTC 2011 TB --- 2011-11-10 10:00:52 - cd /src/sys/arm/conf TB --- 2011-11-10 10:00:52 - /usr/sbin/config -m HL201 TB --- 2011-11-10 10:00:52 - building HL201 kernel TB --- 2011-11-10 10:00:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 10:00:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 10:00:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 10:00:52 - SRCCONF=/dev/null TB --- 2011-11-10 10:00:52 - TARGET=arm TB --- 2011-11-10 10:00:52 - TARGET_ARCH=arm TB --- 2011-11-10 10:00:52 - TZ=UTC TB --- 2011-11-10 10:00:52 - __MAKE_CONF=/dev/null TB --- 2011-11-10 10:00:52 - cd /src TB --- 2011-11-10 10:00:52 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 10 10:00:52 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 10 10:03:11 UTC 2011 TB --- 2011-11-10 10:03:11 - cd /src/sys/arm/conf TB --- 2011-11-10 10:03:11 - /usr/sbin/config -m IQ31244 TB --- 2011-11-10 10:03:11 - building IQ31244 kernel TB --- 2011-11-10 10:03:11 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 10:03:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 10:03:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 10:03:11 - SRCCONF=/dev/null TB --- 2011-11-10 10:03:11 - TARGET=arm TB --- 2011-11-10 10:03:11 - TARGET_ARCH=arm TB --- 2011-11-10 10:03:11 - TZ=UTC TB --- 2011-11-10 10:03:11 - __MAKE_CONF=/dev/null TB --- 2011-11-10 10:03:11 - cd /src TB --- 2011-11-10 10:03:11 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 10 10:03:11 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 10 10:06:27 UTC 2011 TB --- 2011-11-10 10:06:27 - cd /src/sys/arm/conf TB --- 2011-11-10 10:06:27 - /usr/sbin/config -m KB920X TB --- 2011-11-10 10:06:27 - building KB920X kernel TB --- 2011-11-10 10:06:27 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 10:06:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 10:06:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 10:06:27 - SRCCONF=/dev/null TB --- 2011-11-10 10:06:27 - TARGET=arm TB --- 2011-11-10 10:06:27 - TARGET_ARCH=arm TB --- 2011-11-10 10:06:27 - TZ=UTC TB --- 2011-11-10 10:06:27 - __MAKE_CONF=/dev/null TB --- 2011-11-10 10:06:27 - cd /src TB --- 2011-11-10 10:06:27 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 10 10:06:27 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 10:11:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 10:11:23 - ERROR: failed to build KB920X kernel TB --- 2011-11-10 10:11:23 - 4508.23 user 1125.09 system 6082.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 10:32:55 2011 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 451C01065745; Thu, 10 Nov 2011 10:32:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A16768FC17; Thu, 10 Nov 2011 10:32:53 +0000 (UTC) Received: by wwg14 with SMTP id 14so1485608wwg.31 for ; Thu, 10 Nov 2011 02:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rBOtWoZM8udu2H4zBELzlL0sp60ffW8Co6eb2gkTms8=; b=lOQ+q1vqkohFxlTO8N4AYRnNnXSsmLk9P0UB/AK2kuvPSkIEvNJgqdRdU5kNzjKZa2 dtOIBsrtrgozRQr/0KsHqA5Me2zAze7OfOoUaqcHL2yxidNgsOsMlQTkHhmhspeDZa8d vLynbHE84jZdhHqVk8q/qkdL3m/0IdEB1fTf8= MIME-Version: 1.0 Received: by 10.216.176.14 with SMTP id a14mr6106899wem.14.1320921172629; Thu, 10 Nov 2011 02:32:52 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Thu, 10 Nov 2011 02:32:52 -0800 (PST) In-Reply-To: <4EBB885E.9060908@freebsd.org> References: <4EBB885E.9060908@freebsd.org> Date: Thu, 10 Nov 2011 11:32:52 +0100 X-Google-Sender-Auth: LpC2nxGOiv4PNz1R4BRfEylsqcY Message-ID: From: Attilio Rao To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current Subject: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT 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, 10 Nov 2011 10:32:55 -0000 2011/11/10 Stefan Esser : > For a few weeks I have been suffering from a problem that requires manual > intervention to get my home workstation boot -CURRENT. > > The kernel panics at varying places and with different panic messages, e.g. > (hand transcribed since kernel dumps don't work at that stage): > > privileged instruction fault while in kernel mode > > kmem_alloc_nofault +0x37 > kmem_init +0x9e > vm_kmem_init +0x39 > mi_startup +0x77 > btext +0x2c > > > On another cold boot attempt: > > kernel trap 12 with interrupts disabled > Fatal trap 12: page fault while in kernel mode > > elf_relocinternal +0xa8 > link_elf_reloc_local +0x2fe > link_elf_link_preload +0x69d > linker_preload +0x101 > mi_startup +0x77 > btext +0x2c > > > In all the cases observed, the system starts without any problems on second > attempt (pressing RESET or the reboot command in the debugger). > The system is working reliably, once booted. > > This started a few weeks back (after the switch-over to 10-CURRENT, > IIRC), and I did not bother to report it at the time, since I thought it was > caused by a temporary instability in the code base. > > The system is an i2600K on ASUS P8H67-M EVO with 8GB of RAM and an amd64 > kernel booting from ZFS (gptzfsboot). The kernel is a stripped down GENERIC > plus IPFW and ath (but I doubt that the configuration is causing this, since > the failure happens before any devices are probed and the identically > configured kernels used to cold boot just fine for half a year). > > Any hint how to further diagnose this case is welcome (but my spare > time is very limited and I cannot easily bisect to find a revision > that boots, for example). > > I can produce further debug output on demand, but I do not have a serial or > firewire console setup for debugging. > > Is anybody else affected by this boot problem? Can you setup a videocamera or a simple serial console? Did you try to boot with both -s and -v on? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 10:48:37 2011 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 21C181065672; Thu, 10 Nov 2011 10:48:37 +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 E24668FC1C; Thu, 10 Nov 2011 10:48:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAAma32006470; Thu, 10 Nov 2011 05:48:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAAmZ5W006461; Thu, 10 Nov 2011 10:48:35 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 10:48:35 GMT Message-Id: <201111101048.pAAAmZ5W006461@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: Thu, 10 Nov 2011 10:48:37 -0000 TB --- 2011-11-10 08:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 08:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-10 08:30:00 - cleaning the object tree TB --- 2011-11-10 08:30:20 - cvsupping the source tree TB --- 2011-11-10 08:30:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-10 08:31:06 - building world TB --- 2011-11-10 08:31:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 08:31:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 08:31:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 08:31:06 - SRCCONF=/dev/null TB --- 2011-11-10 08:31:06 - TARGET=pc98 TB --- 2011-11-10 08:31:06 - TARGET_ARCH=i386 TB --- 2011-11-10 08:31:06 - TZ=UTC TB --- 2011-11-10 08:31:06 - __MAKE_CONF=/dev/null TB --- 2011-11-10 08:31:06 - cd /src TB --- 2011-11-10 08:31:06 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 08:31:07 UTC 2011 >>> 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 Nov 10 10:40:20 UTC 2011 TB --- 2011-11-10 10:40:20 - generating LINT kernel config TB --- 2011-11-10 10:40:20 - cd /src/sys/pc98/conf TB --- 2011-11-10 10:40:20 - /usr/bin/make -B LINT TB --- 2011-11-10 10:40:20 - cd /src/sys/pc98/conf TB --- 2011-11-10 10:40:20 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 10:40:20 - building GENERIC kernel TB --- 2011-11-10 10:40:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 10:40:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 10:40:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 10:40:20 - SRCCONF=/dev/null TB --- 2011-11-10 10:40:20 - TARGET=pc98 TB --- 2011-11-10 10:40:20 - TARGET_ARCH=i386 TB --- 2011-11-10 10:40:20 - TZ=UTC TB --- 2011-11-10 10:40:20 - __MAKE_CONF=/dev/null TB --- 2011-11-10 10:40:20 - cd /src TB --- 2011-11-10 10:40:20 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 10:40:20 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 10:48:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 10:48:35 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 10:48:35 - 6635.59 user 1177.62 system 8315.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 11:50:00 2011 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 8A63D1065673; Thu, 10 Nov 2011 11:50:00 +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 5E2B28FC0C; Thu, 10 Nov 2011 11:50:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAABnxja077403; Thu, 10 Nov 2011 06:49:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAABnxp4077362; Thu, 10 Nov 2011 11:49:59 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 11:49:59 GMT Message-Id: <201111101149.pAABnxp4077362@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: Thu, 10 Nov 2011 11:50:00 -0000 TB --- 2011-11-10 10:11:23 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 10:11:23 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-10 10:11:23 - cleaning the object tree TB --- 2011-11-10 10:11:35 - cvsupping the source tree TB --- 2011-11-10 10:11:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-10 10:11:47 - building world TB --- 2011-11-10 10:11:47 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 10:11:47 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 10:11:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 10:11:47 - SRCCONF=/dev/null TB --- 2011-11-10 10:11:47 - TARGET=ia64 TB --- 2011-11-10 10:11:47 - TARGET_ARCH=ia64 TB --- 2011-11-10 10:11:47 - TZ=UTC TB --- 2011-11-10 10:11:47 - __MAKE_CONF=/dev/null TB --- 2011-11-10 10:11:47 - cd /src TB --- 2011-11-10 10:11:47 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 10:11:48 UTC 2011 >>> 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 Nov 10 11:39:56 UTC 2011 TB --- 2011-11-10 11:39:56 - generating LINT kernel config TB --- 2011-11-10 11:39:56 - cd /src/sys/ia64/conf TB --- 2011-11-10 11:39:56 - /usr/bin/make -B LINT TB --- 2011-11-10 11:39:56 - cd /src/sys/ia64/conf TB --- 2011-11-10 11:39:56 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 11:39:56 - building GENERIC kernel TB --- 2011-11-10 11:39:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 11:39:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 11:39:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 11:39:56 - SRCCONF=/dev/null TB --- 2011-11-10 11:39:56 - TARGET=ia64 TB --- 2011-11-10 11:39:56 - TARGET_ARCH=ia64 TB --- 2011-11-10 11:39:56 - TZ=UTC TB --- 2011-11-10 11:39:56 - __MAKE_CONF=/dev/null TB --- 2011-11-10 11:39:56 - cd /src TB --- 2011-11-10 11:39:56 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 11:39:56 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 11:49:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 11:49:59 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 11:49:59 - 4667.16 user 904.60 system 5915.49 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 06:48:44 2011 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 CB2991065670; Thu, 10 Nov 2011 06:48:44 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D0E68FC16; Thu, 10 Nov 2011 06:48:43 +0000 (UTC) Received: by faar19 with SMTP id r19so3473460faa.13 for ; Wed, 09 Nov 2011 22:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a+T9zRN3YhQkt6/dmbitXOCFSvtfLpmXvjh0J/81DSQ=; b=Fu3pAJl9iaTlMXs8QscE9Z7mwEyC/B78QlZmDNmtVEUKljV2txnTj/J8aoVwxqOkwu p1o9PPMDVUfXHzQTRx8Ct+7gezHXZ1PmKSw/Wd4zde8TckO29jttpzBsuDsSGeRpSLMu xsqRPtmqWw+AHbtq2YVAvgT30plmdtVfdZvdk= MIME-Version: 1.0 Received: by 10.152.104.206 with SMTP id gg14mr3710949lab.41.1320907722931; Wed, 09 Nov 2011 22:48:42 -0800 (PST) Received: by 10.152.9.10 with HTTP; Wed, 9 Nov 2011 22:48:42 -0800 (PST) In-Reply-To: <201111081431.45910.jhb@freebsd.org> References: <201110251555.23066.jhb@freebsd.org> <201111081431.45910.jhb@freebsd.org> Date: Thu, 10 Nov 2011 10:48:42 +0400 Message-ID: From: Pavel Timofeev To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 10 Nov 2011 12:19:14 +0000 Cc: Andriy Gapon , freebsd-current@freebsd.org, Dennis Koegel , Gunnar Schaefer Subject: Re: Fresh installed Freebsd 9 don't boot from hd 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, 10 Nov 2011 06:48:44 -0000 Thank you! I see this fix in 9 STABLE. Works) 2011/11/8 John Baldwin : > On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote: >> FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov =C2=A08 20:52:11 MS= K >> 2011 =C2=A0 =C2=A0 mox@accessor:/usr/obj/usr/src/sys/GENERIC =C2=A0amd64 >> RC2 is coming. Nothing changed. > > Sorry, haven't been able to merge them to 9 yet. > >> 2011/10/25 John Baldwin : >> > On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote: >> >> On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote: >> >> >> >> > On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote: >> >> >> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch >> >> > >> >> > GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type= ": >> >> > >> >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0v86.ds =3D VTOPSEG(params); >> >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0v86.esi =3D VTOPOFF(params); >> >> > >> >> > Changed this to ¶ms. Also changed sector_size to uint16_t as no= ted >> >> > by Andriy. Boots perfectly! (Tested with gcc and clang) >> >> >> >> I'd like to test these patches on my Supermicro machine as well. >> > Unfortunately, I don't know how to go about it, but I'm hopeful to be = able to >> > figure it out with some basic instructions. I'm currently running a fr= esh RC1 >> > install, and I'm able to boot the system if I set the BIOS to IDE mode= , rather >> > than AHCI. >> >> >> >> Any help would be much appreciated, >> > >> > I just committed them to HEAD (226748 along with a cleanup in 226746).= =C2=A0They >> > should backport to 9. >> > >> > -- >> > John Baldwin >> > >> > > -- > John Baldwin > From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 13:21:28 2011 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 18953106566C; Thu, 10 Nov 2011 13:21: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 D6AEE8FC16; Thu, 10 Nov 2011 13:21:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAADLQha070104; Thu, 10 Nov 2011 08:21:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAADLQLS070075; Thu, 10 Nov 2011 13:21:26 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 13:21:26 GMT Message-Id: <201111101321.pAADLQLS070075@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/i386 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, 10 Nov 2011 13:21:28 -0000 TB --- 2011-11-10 08:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 08:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-10 08:30:00 - cleaning the object tree TB --- 2011-11-10 08:30:44 - cvsupping the source tree TB --- 2011-11-10 08:30:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-10 08:31:06 - building world TB --- 2011-11-10 08:31:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 08:31:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 08:31:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 08:31:06 - SRCCONF=/dev/null TB --- 2011-11-10 08:31:06 - TARGET=i386 TB --- 2011-11-10 08:31:06 - TARGET_ARCH=i386 TB --- 2011-11-10 08:31:06 - TZ=UTC TB --- 2011-11-10 08:31:06 - __MAKE_CONF=/dev/null TB --- 2011-11-10 08:31:06 - cd /src TB --- 2011-11-10 08:31:06 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 08:31:07 UTC 2011 >>> 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 Nov 10 10:40:53 UTC 2011 TB --- 2011-11-10 10:40:53 - generating LINT kernel config TB --- 2011-11-10 10:40:53 - cd /src/sys/i386/conf TB --- 2011-11-10 10:40:53 - /usr/bin/make -B LINT TB --- 2011-11-10 10:40:54 - cd /src/sys/i386/conf TB --- 2011-11-10 10:40:54 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-10 10:40:54 - building LINT-NOINET kernel TB --- 2011-11-10 10:40:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 10:40:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 10:40:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 10:40:54 - SRCCONF=/dev/null TB --- 2011-11-10 10:40:54 - TARGET=i386 TB --- 2011-11-10 10:40:54 - TARGET_ARCH=i386 TB --- 2011-11-10 10:40:54 - TZ=UTC TB --- 2011-11-10 10:40:54 - __MAKE_CONF=/dev/null TB --- 2011-11-10 10:40:54 - cd /src TB --- 2011-11-10 10:40:54 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 10 10:40:54 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET completed on Thu Nov 10 11:11:11 UTC 2011 TB --- 2011-11-10 11:11:11 - cd /src/sys/i386/conf TB --- 2011-11-10 11:11:11 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-10 11:11:11 - building LINT-NOINET6 kernel TB --- 2011-11-10 11:11:11 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 11:11:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 11:11:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 11:11:11 - SRCCONF=/dev/null TB --- 2011-11-10 11:11:11 - TARGET=i386 TB --- 2011-11-10 11:11:11 - TARGET_ARCH=i386 TB --- 2011-11-10 11:11:11 - TZ=UTC TB --- 2011-11-10 11:11:11 - __MAKE_CONF=/dev/null TB --- 2011-11-10 11:11:11 - cd /src TB --- 2011-11-10 11:11:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Nov 10 11:11:11 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET6 completed on Thu Nov 10 11:41:36 UTC 2011 TB --- 2011-11-10 11:41:36 - cd /src/sys/i386/conf TB --- 2011-11-10 11:41:36 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-10 11:41:36 - building LINT-NOIP kernel TB --- 2011-11-10 11:41:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 11:41:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 11:41:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 11:41:36 - SRCCONF=/dev/null TB --- 2011-11-10 11:41:36 - TARGET=i386 TB --- 2011-11-10 11:41:36 - TARGET_ARCH=i386 TB --- 2011-11-10 11:41:36 - TZ=UTC TB --- 2011-11-10 11:41:36 - __MAKE_CONF=/dev/null TB --- 2011-11-10 11:41:36 - cd /src TB --- 2011-11-10 11:41:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Nov 10 11:41:36 UTC 2011 >>> 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 >>> Kernel build for LINT-NOIP completed on Thu Nov 10 12:09:24 UTC 2011 TB --- 2011-11-10 12:09:24 - cd /src/sys/i386/conf TB --- 2011-11-10 12:09:24 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-10 12:09:24 - building LINT-VIMAGE kernel TB --- 2011-11-10 12:09:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 12:09:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 12:09:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 12:09:24 - SRCCONF=/dev/null TB --- 2011-11-10 12:09:24 - TARGET=i386 TB --- 2011-11-10 12:09:24 - TARGET_ARCH=i386 TB --- 2011-11-10 12:09:24 - TZ=UTC TB --- 2011-11-10 12:09:24 - __MAKE_CONF=/dev/null TB --- 2011-11-10 12:09:24 - cd /src TB --- 2011-11-10 12:09:24 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Nov 10 12:09:24 UTC 2011 >>> 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 >>> Kernel build for LINT-VIMAGE completed on Thu Nov 10 12:40:09 UTC 2011 TB --- 2011-11-10 12:40:09 - cd /src/sys/i386/conf TB --- 2011-11-10 12:40:09 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 12:40:09 - building GENERIC kernel TB --- 2011-11-10 12:40:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 12:40:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 12:40:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 12:40:09 - SRCCONF=/dev/null TB --- 2011-11-10 12:40:09 - TARGET=i386 TB --- 2011-11-10 12:40:09 - TARGET_ARCH=i386 TB --- 2011-11-10 12:40:09 - TZ=UTC TB --- 2011-11-10 12:40:09 - __MAKE_CONF=/dev/null TB --- 2011-11-10 12:40:09 - cd /src TB --- 2011-11-10 12:40:09 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 12:40:09 UTC 2011 >>> 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 >>> Kernel build for GENERIC completed on Thu Nov 10 13:04:48 UTC 2011 TB --- 2011-11-10 13:04:48 - cd /src/sys/i386/conf TB --- 2011-11-10 13:04:48 - /usr/sbin/config -m PAE TB --- 2011-11-10 13:04:49 - building PAE kernel TB --- 2011-11-10 13:04:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 13:04:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 13:04:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 13:04:49 - SRCCONF=/dev/null TB --- 2011-11-10 13:04:49 - TARGET=i386 TB --- 2011-11-10 13:04:49 - TARGET_ARCH=i386 TB --- 2011-11-10 13:04:49 - TZ=UTC TB --- 2011-11-10 13:04:49 - __MAKE_CONF=/dev/null TB --- 2011-11-10 13:04:49 - cd /src TB --- 2011-11-10 13:04:49 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Thu Nov 10 13:04:49 UTC 2011 >>> 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 >>> Kernel build for PAE completed on Thu Nov 10 13:11:05 UTC 2011 TB --- 2011-11-10 13:11:05 - cd /src/sys/i386/conf TB --- 2011-11-10 13:11:05 - /usr/sbin/config -m XBOX TB --- 2011-11-10 13:11:05 - building XBOX kernel TB --- 2011-11-10 13:11:05 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 13:11:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 13:11:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 13:11:05 - SRCCONF=/dev/null TB --- 2011-11-10 13:11:05 - TARGET=i386 TB --- 2011-11-10 13:11:05 - TARGET_ARCH=i386 TB --- 2011-11-10 13:11:05 - TZ=UTC TB --- 2011-11-10 13:11:05 - __MAKE_CONF=/dev/null TB --- 2011-11-10 13:11:05 - cd /src TB --- 2011-11-10 13:11:05 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Thu Nov 10 13:11:05 UTC 2011 >>> 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 >>> Kernel build for XBOX completed on Thu Nov 10 13:14:21 UTC 2011 TB --- 2011-11-10 13:14:21 - cd /src/sys/i386/conf TB --- 2011-11-10 13:14:21 - /usr/sbin/config -m XEN TB --- 2011-11-10 13:14:21 - building XEN kernel TB --- 2011-11-10 13:14:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 13:14:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 13:14:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 13:14:21 - SRCCONF=/dev/null TB --- 2011-11-10 13:14:21 - TARGET=i386 TB --- 2011-11-10 13:14:21 - TARGET_ARCH=i386 TB --- 2011-11-10 13:14:21 - TZ=UTC TB --- 2011-11-10 13:14:21 - __MAKE_CONF=/dev/null TB --- 2011-11-10 13:14:21 - cd /src TB --- 2011-11-10 13:14:21 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Thu Nov 10 13:14:21 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 13:21:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 13:21:26 - ERROR: failed to build XEN kernel TB --- 2011-11-10 13:21:26 - 13933.04 user 2411.23 system 17485.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 13:38:58 2011 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 398AE1065670; Thu, 10 Nov 2011 13:38:58 +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 063818FC08; Thu, 10 Nov 2011 13:38:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAADcuie098947; Thu, 10 Nov 2011 08:38:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAADcuYd098933; Thu, 10 Nov 2011 13:38:56 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 13:38:56 GMT Message-Id: <201111101338.pAADcuYd098933@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, 10 Nov 2011 13:38:58 -0000 TB --- 2011-11-10 11:49:59 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 11:49:59 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-10 11:49:59 - cleaning the object tree TB --- 2011-11-10 11:50:16 - cvsupping the source tree TB --- 2011-11-10 11:50:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-10 11:51:03 - building world TB --- 2011-11-10 11:51:03 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 11:51:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 11:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 11:51:03 - SRCCONF=/dev/null TB --- 2011-11-10 11:51:03 - TARGET=powerpc TB --- 2011-11-10 11:51:03 - TARGET_ARCH=powerpc64 TB --- 2011-11-10 11:51:03 - TZ=UTC TB --- 2011-11-10 11:51:03 - __MAKE_CONF=/dev/null TB --- 2011-11-10 11:51:03 - cd /src TB --- 2011-11-10 11:51:03 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 11:51:04 UTC 2011 >>> 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 Nov 10 13:31:19 UTC 2011 TB --- 2011-11-10 13:31:19 - generating LINT kernel config TB --- 2011-11-10 13:31:19 - cd /src/sys/powerpc/conf TB --- 2011-11-10 13:31:19 - /usr/bin/make -B LINT TB --- 2011-11-10 13:31:19 - cd /src/sys/powerpc/conf TB --- 2011-11-10 13:31:19 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 13:31:19 - skipping GENERIC kernel TB --- 2011-11-10 13:31:19 - cd /src/sys/powerpc/conf TB --- 2011-11-10 13:31:19 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-10 13:31:19 - building GENERIC64 kernel TB --- 2011-11-10 13:31:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 13:31:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 13:31:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 13:31:19 - SRCCONF=/dev/null TB --- 2011-11-10 13:31:19 - TARGET=powerpc TB --- 2011-11-10 13:31:19 - TARGET_ARCH=powerpc64 TB --- 2011-11-10 13:31:19 - TZ=UTC TB --- 2011-11-10 13:31:19 - __MAKE_CONF=/dev/null TB --- 2011-11-10 13:31:19 - cd /src TB --- 2011-11-10 13:31:19 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 10 13:31:19 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 13:38:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 13:38:55 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-10 13:38:55 - 4831.67 user 1127.78 system 6535.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 13:53:54 2011 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 4FA201065672; Thu, 10 Nov 2011 13:53: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 BAD8A8FC08; Thu, 10 Nov 2011 13:53:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAADrrQh078661; Thu, 10 Nov 2011 08:53:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAADrrbS078660; Thu, 10 Nov 2011 13:53:53 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 13:53:53 GMT Message-Id: <201111101353.pAADrrbS078660@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, 10 Nov 2011 13:53:54 -0000 TB --- 2011-11-10 11:48:08 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 11:48:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-10 11:48:08 - cleaning the object tree TB --- 2011-11-10 11:48:20 - cvsupping the source tree TB --- 2011-11-10 11:48:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-10 11:48:32 - building world TB --- 2011-11-10 11:48:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 11:48:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 11:48:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 11:48:32 - SRCCONF=/dev/null TB --- 2011-11-10 11:48:32 - TARGET=powerpc TB --- 2011-11-10 11:48:32 - TARGET_ARCH=powerpc TB --- 2011-11-10 11:48:32 - TZ=UTC TB --- 2011-11-10 11:48:32 - __MAKE_CONF=/dev/null TB --- 2011-11-10 11:48:32 - cd /src TB --- 2011-11-10 11:48:32 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 11:48:33 UTC 2011 >>> 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 Nov 10 13:47:37 UTC 2011 TB --- 2011-11-10 13:47:37 - generating LINT kernel config TB --- 2011-11-10 13:47:37 - cd /src/sys/powerpc/conf TB --- 2011-11-10 13:47:37 - /usr/bin/make -B LINT TB --- 2011-11-10 13:47:37 - cd /src/sys/powerpc/conf TB --- 2011-11-10 13:47:37 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 13:47:37 - building GENERIC kernel TB --- 2011-11-10 13:47:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 13:47:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 13:47:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 13:47:37 - SRCCONF=/dev/null TB --- 2011-11-10 13:47:37 - TARGET=powerpc TB --- 2011-11-10 13:47:37 - TARGET_ARCH=powerpc TB --- 2011-11-10 13:47:37 - TZ=UTC TB --- 2011-11-10 13:47:37 - __MAKE_CONF=/dev/null TB --- 2011-11-10 13:47:37 - cd /src TB --- 2011-11-10 13:47:37 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 13:47:37 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 13:53:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 13:53:52 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 13:53:52 - 6080.80 user 1058.38 system 7544.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 14:30:40 2011 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 AA60F1065672 for ; Thu, 10 Nov 2011 14:30:40 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2F08FC0A for ; Thu, 10 Nov 2011 14:30:40 +0000 (UTC) Received: by vws11 with SMTP id 11so3563699vws.13 for ; Thu, 10 Nov 2011 06:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=wb2VurL1PzKYp2MGp3Yvc9KcKar/h0Ypjxmm0MYnn3M=; b=qJN5DwvOuHodMb3U3W9B1RVjWnBAF3XqzhcGj6qjDzA9RNgakaL4TdD5bxqH8WYJUI hcFEhnOgYPDcOzGJP1HgJmSwFP2/cwfLB7dvq5Hw/M9uqbx3tyqdnhAdIxUO0kQ7FKql yXstfWbovJpwMa76Qzh2ldE49csqzSxmRkWeQ= Received: by 10.52.95.34 with SMTP id dh2mr13298236vdb.12.1320935439471; Thu, 10 Nov 2011 06:30:39 -0800 (PST) Received: from schism.local (75-146-225-65-Philadelphia.hfc.comcastbusiness.net. [75.146.225.65]) by mx.google.com with ESMTPS id bu10sm12416067vdb.3.2011.11.10.06.30.36 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 06:30:36 -0800 (PST) Message-ID: <4EBBE00B.1090203@gmail.com> Date: Thu, 10 Nov 2011 09:30:35 -0500 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EBB6787.8000300@gmail.com> <201111100938.39891.hselasky@c2i.net> In-Reply-To: <201111100938.39891.hselasky@c2i.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 14:30:40 -0000 On 11/10/11 3:38 AM, Hans Petter Selasky wrote: > On Thursday 10 November 2011 06:56:23 Glen Barber wrote: >> Hi, >> >> Netgear has these neat little USB micro wireless network adapters[1] >> that one could plug in and forget about without fear of, for example, >> breaking the device. >> >> Said devices are really nice for those of us without supported >> integrated wireless chipsets, such as those found in late 2010 MacBooks, >> or anything manufactured by Dell recently... >> >> The only problem is that the device itself is not supported. >> >> The device appears to have a RealTek RTL8188CUS chipset (vendor 0846, >> device 9041), which, without knowing much more about the device, I >> suspect could work with the urtw(4) driver. However, my feeble attempts >> at simulating support for the device ended, well, as expected. :) >> >> Is someone out there interested in undertaking the task of tweaking the >> driver code (if it's feasible in this case, of course) to get this >> device supported? I suspect more people than just me would be greatly >> appreciative of support for it. :) >> >> Thanks, >> >> Glen >> >> [1] - >> http://www.totobay.com/netgear-wna-1000-n-150m-wireless-usb-adapter_p29987. >> html > > Hi, > > Could you dump the device descriptor using usbconfig and Google the .idVendor > and .idProduct values? > Hi, Of course. Here is the device dump: # usbconfig -d ugen2.5 dump_info ugen2.5: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Searching for "vendor 0x0846 product 0x9041" seems to give many of the same results. Is there anything in particular I can add to the search that would be helpful? Thanks for the response. Glen -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 15:35:58 2011 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 755CB1065678 for ; Thu, 10 Nov 2011 15:35:58 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 371A18FC17 for ; Thu, 10 Nov 2011 15:35:58 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id pAAFZvda090250; Thu, 10 Nov 2011 08:35:57 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id pAAFZvLc090247; Thu, 10 Nov 2011 08:35:57 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 10 Nov 2011 08:35:57 -0700 (MST) From: Warren Block To: Glen Barber In-Reply-To: <4EBB6787.8000300@gmail.com> Message-ID: References: <4EBB6787.8000300@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 10 Nov 2011 08:35:57 -0700 (MST) Cc: current@freebsd.org Subject: Re: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 15:35:58 -0000 On Thu, 10 Nov 2011, Glen Barber wrote: > Netgear has these neat little USB micro wireless network adapters[1] > that one could plug in and forget about without fear of, for example, > breaking the device. > > Said devices are really nice for those of us without supported > integrated wireless chipsets, such as those found in late 2010 MacBooks, > or anything manufactured by Dell recently... > > The only problem is that the device itself is not supported. > > The device appears to have a RealTek RTL8188CUS chipset (vendor 0846, > device 9041), which, without knowing much more about the device, I > suspect could work with the urtw(4) driver. However, my feeble attempts > at simulating support for the device ended, well, as expected. :) OpenBSD has a urtwn driver. No idea whether anyone is working on a port. http://www.openbsd.org/cgi-bin/man.cgi?query=urtwn&sektion=4&format=html From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:01:58 2011 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 752EF106564A for ; Thu, 10 Nov 2011 16:01:58 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6908FC08 for ; Thu, 10 Nov 2011 16:01:57 +0000 (UTC) Received: by vws11 with SMTP id 11so3706692vws.13 for ; Thu, 10 Nov 2011 08:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=MpMZd7hS4vh5p3pyDVUg6/KKsOkXSWKzMXiIOUYndQo=; b=GoELd3Z5fbRRF/e2tGINJHG8Mpeu7i/3PlA0zUHdHIiFNL0v6S0oHaRm8IIGs/zPL/ 46vdHGJmd/MX90XgCSwI4uL7FA3vRiShqKBygqFwX3+0q8m+uPz1Yb5JAEkuumDQOBks Bqta4zAgqrE5QqYjqH/8W+uVVmy125MMoCc5o= Received: by 10.52.26.14 with SMTP id h14mr13436513vdg.132.1320940917571; Thu, 10 Nov 2011 08:01:57 -0800 (PST) Received: from schism.local (75-146-225-65-Philadelphia.hfc.comcastbusiness.net. [75.146.225.65]) by mx.google.com with ESMTPS id ey9sm12698530vdc.19.2011.11.10.08.01.55 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 08:01:55 -0800 (PST) Message-ID: <4EBBF572.9010805@gmail.com> Date: Thu, 10 Nov 2011 11:01:54 -0500 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Warren Block References: <4EBB6787.8000300@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 16:01:58 -0000 On 11/10/11 10:35 AM, Warren Block wrote: > On Thu, 10 Nov 2011, Glen Barber wrote: > >> Netgear has these neat little USB micro wireless network adapters[1] >> that one could plug in and forget about without fear of, for example, >> breaking the device. >> >> Said devices are really nice for those of us without supported >> integrated wireless chipsets, such as those found in late 2010 MacBooks, >> or anything manufactured by Dell recently... >> >> The only problem is that the device itself is not supported. >> >> The device appears to have a RealTek RTL8188CUS chipset (vendor 0846, >> device 9041), which, without knowing much more about the device, I >> suspect could work with the urtw(4) driver. However, my feeble attempts >> at simulating support for the device ended, well, as expected. :) > > OpenBSD has a urtwn driver. No idea whether anyone is working on a port. > http://www.openbsd.org/cgi-bin/man.cgi?query=urtwn&sektion=4&format=html > Ooh, that's good news. Thanks! -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:08:41 2011 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 85750106564A; Thu, 10 Nov 2011 16:08:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1B39B8FC14; Thu, 10 Nov 2011 16:08:40 +0000 (UTC) Received: by vws11 with SMTP id 11so3717977vws.13 for ; Thu, 10 Nov 2011 08:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Mzcgg0DxCyh+deunlUMWXYXcknMk8/5ljHkkdqK9HdQ=; b=o3fhMMH+VVRanmK7B3aWEO8+/s5gfvaAyiQ9erNGk4nflkw0iWZl1cS+J6iTcR61JI jHi6acwzgfkRG6Aj1cpfrSJg7R9aNc28/+J06ABK11+kz4hqNNkkxYqM8KOA/Sa4WWmd 4TZvv50wxV5uoZ6El2rWN7PbuCTRXab9ZfspI= MIME-Version: 1.0 Received: by 10.52.65.78 with SMTP id v14mr6806934vds.89.1320941320277; Thu, 10 Nov 2011 08:08:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 08:08:40 -0800 (PST) In-Reply-To: <4EBB7A0A.20700@FreeBSD.org> References: <201111100705.pAA75eIT023291@freebsd-current.sentex.ca> <4EBB7A0A.20700@FreeBSD.org> Date: Thu, 10 Nov 2011 08:08:40 -0800 X-Google-Sender-Auth: 9sIvKEIOiUydFxLhp-VHssXSRTA Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: i386@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 10 Nov 2011 16:08:41 -0000 This is a new problem - it seems some kernels don't have AH_SUPPORT_AR5416 in them. The module was thus being built with the default opt_ah.h which enabled it. I'd like to just get that option added to kernels for now. I'll then fix the ath/hal build to work without the extra AR5416 fields but it's going to take a bit of effort. (It won't be impossible, just will take a little more time.) So if you/others would like to fix all the kernels for which this breaks by simply adding "options AH_SUPPORT_AR5416" to the kernel configuration, or just add an option to not build ath/ath_pci/ath_ahb for those devices, please feel free. Thanks, adrian From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:11:01 2011 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 D479A1065672 for ; Thu, 10 Nov 2011 16:11:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECCE8FC17 for ; Thu, 10 Nov 2011 16:11:01 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so3706952vcb.13 for ; Thu, 10 Nov 2011 08:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mYytR2MqJ3xkSD6Xx2dm8qRE2p00Eprv8gTn6Dx2jNM=; b=iu8NrMPWm83SLpZIShH0xf7xKf/hFNgRWVZJjZG47YOyOWE9p7yQMPHMu+UARxP/WQ IrAemQ681nSdha2XJpw+WaHH1rrrKj9YyxprpmLxCNymNDd0mbQ3BOKxb5fZ03sgg3oX UjkSwNSPJFv96sONzs+z0pTwuWDWkrolXvajk= MIME-Version: 1.0 Received: by 10.52.65.78 with SMTP id v14mr6821793vds.89.1320941460406; Thu, 10 Nov 2011 08:11:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 08:11:00 -0800 (PST) In-Reply-To: <4EBBF572.9010805@gmail.com> References: <4EBB6787.8000300@gmail.com> <4EBBF572.9010805@gmail.com> Date: Thu, 10 Nov 2011 08:11:00 -0800 X-Google-Sender-Auth: mfmGQeCDN4VePL_AiswNAa3Td00 Message-ID: From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Cc: Warren Block , current@freebsd.org Subject: Re: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 16:11:01 -0000 .. it's only good news if someone ports it. There's been efforts here and there to tinker with it but no-one's submitted a working driver for inclusion into -HEAD ;) Adrian From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:16:40 2011 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 3F533106564A; Thu, 10 Nov 2011 16:16:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC6BF8FC12; Thu, 10 Nov 2011 16:16:39 +0000 (UTC) Received: by vws11 with SMTP id 11so3732494vws.13 for ; Thu, 10 Nov 2011 08:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ocbUStDqdQxoASX4n2oDO4wiA2SU/H55mChiDmCGPK0=; b=VNpe5Hc75d4UtKrhAWLxznF75nDsFweP5He+qva1imKcZvtL+haA0OYuJtDIOCEUjJ 4z0iEyE9UHhaqQND3hrCupVx7KfuMVWz7vtiegAmOLLCeCfZQekmnjqszmxUyUYTsJgE hVmujrHuokEbj6eJWOdQsVMGSAgzEJVikIjLg= MIME-Version: 1.0 Received: by 10.52.38.4 with SMTP id c4mr13600231vdk.123.1320941799316; Thu, 10 Nov 2011 08:16:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 08:16:39 -0800 (PST) In-Reply-To: References: <201111100705.pAA75eIT023291@freebsd-current.sentex.ca> <4EBB7A0A.20700@FreeBSD.org> Date: Thu, 10 Nov 2011 08:16:39 -0800 X-Google-Sender-Auth: irpgyvJGcmwFzUS1Z5M8QI68AxU Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: i386@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 10 Nov 2011 16:16:40 -0000 .. and I'm going to try to quieten some of those errors now. Since the software aggregation side requires the 802.11n fields to work, I can't easily fix it all in one hit. But I'll see what I can do to make things buildable again. Thanks and sorry for this! Adrian From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:22:06 2011 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 AF8D5106566C; Thu, 10 Nov 2011 16:22:06 +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 239348FC12; Thu, 10 Nov 2011 16:22:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAGM5qm010801; Thu, 10 Nov 2011 11:22:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAGM5ud010785; Thu, 10 Nov 2011 16:22:05 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 16:22:05 GMT Message-Id: <201111101622.pAAGM5ud010785@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 arm/arm 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, 10 Nov 2011 16:22:06 -0000 TB --- 2011-11-10 14:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 14:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-10 14:40:00 - cleaning the object tree TB --- 2011-11-10 14:40:23 - cvsupping the source tree TB --- 2011-11-10 14:40:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-10 14:40:36 - building world TB --- 2011-11-10 14:40:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 14:40:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 14:40:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 14:40:36 - SRCCONF=/dev/null TB --- 2011-11-10 14:40:36 - TARGET=arm TB --- 2011-11-10 14:40:36 - TARGET_ARCH=arm TB --- 2011-11-10 14:40:36 - TZ=UTC TB --- 2011-11-10 14:40:36 - __MAKE_CONF=/dev/null TB --- 2011-11-10 14:40:36 - cd /src TB --- 2011-11-10 14:40:36 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 14:40:37 UTC 2011 >>> 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 Nov 10 15:36:58 UTC 2011 TB --- 2011-11-10 15:36:59 - cd /src/sys/arm/conf TB --- 2011-11-10 15:36:59 - /usr/sbin/config -m AVILA TB --- 2011-11-10 15:36:59 - building AVILA kernel TB --- 2011-11-10 15:36:59 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:36:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:36:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:36:59 - SRCCONF=/dev/null TB --- 2011-11-10 15:36:59 - TARGET=arm TB --- 2011-11-10 15:36:59 - TARGET_ARCH=arm TB --- 2011-11-10 15:36:59 - TZ=UTC TB --- 2011-11-10 15:36:59 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:36:59 - cd /src TB --- 2011-11-10 15:36:59 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 10 15:36:59 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 10 15:39:59 UTC 2011 TB --- 2011-11-10 15:39:59 - cd /src/sys/arm/conf TB --- 2011-11-10 15:39:59 - /usr/sbin/config -m BWCT TB --- 2011-11-10 15:40:00 - building BWCT kernel TB --- 2011-11-10 15:40:00 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:40:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:40:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:40:00 - SRCCONF=/dev/null TB --- 2011-11-10 15:40:00 - TARGET=arm TB --- 2011-11-10 15:40:00 - TARGET_ARCH=arm TB --- 2011-11-10 15:40:00 - TZ=UTC TB --- 2011-11-10 15:40:00 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:40:00 - cd /src TB --- 2011-11-10 15:40:00 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 10 15:40:01 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 10 15:42:09 UTC 2011 TB --- 2011-11-10 15:42:09 - cd /src/sys/arm/conf TB --- 2011-11-10 15:42:09 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-10 15:42:10 - building CAMBRIA kernel TB --- 2011-11-10 15:42:10 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:42:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:42:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:42:10 - SRCCONF=/dev/null TB --- 2011-11-10 15:42:10 - TARGET=arm TB --- 2011-11-10 15:42:10 - TARGET_ARCH=arm TB --- 2011-11-10 15:42:10 - TZ=UTC TB --- 2011-11-10 15:42:10 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:42:10 - cd /src TB --- 2011-11-10 15:42:10 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 10 15:42:10 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 10 15:45:37 UTC 2011 TB --- 2011-11-10 15:45:37 - cd /src/sys/arm/conf TB --- 2011-11-10 15:45:37 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-10 15:45:37 - building CNS11XXNAS kernel TB --- 2011-11-10 15:45:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:45:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:45:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:45:37 - SRCCONF=/dev/null TB --- 2011-11-10 15:45:37 - TARGET=arm TB --- 2011-11-10 15:45:37 - TARGET_ARCH=arm TB --- 2011-11-10 15:45:37 - TZ=UTC TB --- 2011-11-10 15:45:37 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:45:37 - cd /src TB --- 2011-11-10 15:45:37 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 10 15:45:37 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 10 15:48:07 UTC 2011 TB --- 2011-11-10 15:48:07 - cd /src/sys/arm/conf TB --- 2011-11-10 15:48:07 - /usr/sbin/config -m CRB TB --- 2011-11-10 15:48:07 - building CRB kernel TB --- 2011-11-10 15:48:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:48:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:48:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:48:07 - SRCCONF=/dev/null TB --- 2011-11-10 15:48:07 - TARGET=arm TB --- 2011-11-10 15:48:07 - TARGET_ARCH=arm TB --- 2011-11-10 15:48:07 - TZ=UTC TB --- 2011-11-10 15:48:07 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:48:07 - cd /src TB --- 2011-11-10 15:48:07 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 10 15:48:07 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 10 15:51:58 UTC 2011 TB --- 2011-11-10 15:51:58 - cd /src/sys/arm/conf TB --- 2011-11-10 15:51:58 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-10 15:51:58 - building DB-78XXX kernel TB --- 2011-11-10 15:51:58 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:51:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:51:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:51:58 - SRCCONF=/dev/null TB --- 2011-11-10 15:51:58 - TARGET=arm TB --- 2011-11-10 15:51:58 - TARGET_ARCH=arm TB --- 2011-11-10 15:51:58 - TZ=UTC TB --- 2011-11-10 15:51:58 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:51:58 - cd /src TB --- 2011-11-10 15:51:58 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 10 15:51:58 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 10 15:54:37 UTC 2011 TB --- 2011-11-10 15:54:37 - cd /src/sys/arm/conf TB --- 2011-11-10 15:54:37 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-10 15:54:37 - building DB-88F5XXX kernel TB --- 2011-11-10 15:54:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:54:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:54:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:54:37 - SRCCONF=/dev/null TB --- 2011-11-10 15:54:37 - TARGET=arm TB --- 2011-11-10 15:54:37 - TARGET_ARCH=arm TB --- 2011-11-10 15:54:37 - TZ=UTC TB --- 2011-11-10 15:54:37 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:54:37 - cd /src TB --- 2011-11-10 15:54:37 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 10 15:54:37 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 10 15:57:17 UTC 2011 TB --- 2011-11-10 15:57:17 - cd /src/sys/arm/conf TB --- 2011-11-10 15:57:17 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-10 15:57:17 - building DB-88F6XXX kernel TB --- 2011-11-10 15:57:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 15:57:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 15:57:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 15:57:17 - SRCCONF=/dev/null TB --- 2011-11-10 15:57:17 - TARGET=arm TB --- 2011-11-10 15:57:17 - TARGET_ARCH=arm TB --- 2011-11-10 15:57:17 - TZ=UTC TB --- 2011-11-10 15:57:17 - __MAKE_CONF=/dev/null TB --- 2011-11-10 15:57:17 - cd /src TB --- 2011-11-10 15:57:17 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 10 15:57:17 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 10 16:00:25 UTC 2011 TB --- 2011-11-10 16:00:25 - cd /src/sys/arm/conf TB --- 2011-11-10 16:00:25 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-10 16:00:25 - building DOCKSTAR kernel TB --- 2011-11-10 16:00:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:00:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:00:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:00:25 - SRCCONF=/dev/null TB --- 2011-11-10 16:00:25 - TARGET=arm TB --- 2011-11-10 16:00:25 - TARGET_ARCH=arm TB --- 2011-11-10 16:00:25 - TZ=UTC TB --- 2011-11-10 16:00:25 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:00:25 - cd /src TB --- 2011-11-10 16:00:25 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 10 16:00:25 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 10 16:02:59 UTC 2011 TB --- 2011-11-10 16:02:59 - cd /src/sys/arm/conf TB --- 2011-11-10 16:02:59 - /usr/sbin/config -m EP80219 TB --- 2011-11-10 16:02:59 - building EP80219 kernel TB --- 2011-11-10 16:02:59 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:02:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:02:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:02:59 - SRCCONF=/dev/null TB --- 2011-11-10 16:02:59 - TARGET=arm TB --- 2011-11-10 16:02:59 - TARGET_ARCH=arm TB --- 2011-11-10 16:02:59 - TZ=UTC TB --- 2011-11-10 16:02:59 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:02:59 - cd /src TB --- 2011-11-10 16:02:59 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 10 16:02:59 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 10 16:05:50 UTC 2011 TB --- 2011-11-10 16:05:50 - WARNING: no kernel config for GENERIC TB --- 2011-11-10 16:05:50 - cd /src/sys/arm/conf TB --- 2011-11-10 16:05:50 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-10 16:05:51 - building GUMSTIX kernel TB --- 2011-11-10 16:05:51 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:05:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:05:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:05:51 - SRCCONF=/dev/null TB --- 2011-11-10 16:05:51 - TARGET=arm TB --- 2011-11-10 16:05:51 - TARGET_ARCH=arm TB --- 2011-11-10 16:05:51 - TZ=UTC TB --- 2011-11-10 16:05:51 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:05:51 - cd /src TB --- 2011-11-10 16:05:51 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 10 16:05:51 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 10 16:08:38 UTC 2011 TB --- 2011-11-10 16:08:38 - cd /src/sys/arm/conf TB --- 2011-11-10 16:08:38 - /usr/sbin/config -m HL200 TB --- 2011-11-10 16:08:38 - building HL200 kernel TB --- 2011-11-10 16:08:38 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:08:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:08:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:08:38 - SRCCONF=/dev/null TB --- 2011-11-10 16:08:38 - TARGET=arm TB --- 2011-11-10 16:08:38 - TARGET_ARCH=arm TB --- 2011-11-10 16:08:38 - TZ=UTC TB --- 2011-11-10 16:08:38 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:08:38 - cd /src TB --- 2011-11-10 16:08:38 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 10 16:08:38 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 10 16:11:18 UTC 2011 TB --- 2011-11-10 16:11:18 - cd /src/sys/arm/conf TB --- 2011-11-10 16:11:18 - /usr/sbin/config -m HL201 TB --- 2011-11-10 16:11:18 - building HL201 kernel TB --- 2011-11-10 16:11:18 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:11:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:11:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:11:18 - SRCCONF=/dev/null TB --- 2011-11-10 16:11:18 - TARGET=arm TB --- 2011-11-10 16:11:18 - TARGET_ARCH=arm TB --- 2011-11-10 16:11:18 - TZ=UTC TB --- 2011-11-10 16:11:18 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:11:18 - cd /src TB --- 2011-11-10 16:11:18 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 10 16:11:18 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 10 16:13:35 UTC 2011 TB --- 2011-11-10 16:13:35 - cd /src/sys/arm/conf TB --- 2011-11-10 16:13:35 - /usr/sbin/config -m IQ31244 TB --- 2011-11-10 16:13:35 - building IQ31244 kernel TB --- 2011-11-10 16:13:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:13:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:13:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:13:35 - SRCCONF=/dev/null TB --- 2011-11-10 16:13:35 - TARGET=arm TB --- 2011-11-10 16:13:35 - TARGET_ARCH=arm TB --- 2011-11-10 16:13:35 - TZ=UTC TB --- 2011-11-10 16:13:35 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:13:35 - cd /src TB --- 2011-11-10 16:13:35 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 10 16:13:36 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 10 16:17:16 UTC 2011 TB --- 2011-11-10 16:17:16 - cd /src/sys/arm/conf TB --- 2011-11-10 16:17:16 - /usr/sbin/config -m KB920X TB --- 2011-11-10 16:17:16 - building KB920X kernel TB --- 2011-11-10 16:17:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:17:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:17:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:17:16 - SRCCONF=/dev/null TB --- 2011-11-10 16:17:16 - TARGET=arm TB --- 2011-11-10 16:17:16 - TARGET_ARCH=arm TB --- 2011-11-10 16:17:16 - TZ=UTC TB --- 2011-11-10 16:17:16 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:17:16 - cd /src TB --- 2011-11-10 16:17:16 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 10 16:17:16 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 16:22:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 16:22:04 - ERROR: failed to build KB920X kernel TB --- 2011-11-10 16:22:04 - 4563.14 user 1137.72 system 6123.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:27:13 2011 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 E2EFC106564A for ; Thu, 10 Nov 2011 16:27:13 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5C58FC0C for ; Thu, 10 Nov 2011 16:27:13 +0000 (UTC) Received: by vws11 with SMTP id 11so3749353vws.13 for ; Thu, 10 Nov 2011 08:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=dGqLTNJMYiR8I8iCbOu6uK0/giOA9RWbL2s4Zm9WfKg=; b=bcr5mgWf5fBq0OZWUeaJ3/TluPTJRSX34K5lVOBC2Hen8h6dXMW5f4ifzJ5f2Av+lJ 3/c8F9FO4kjZh7bPKbkcTl7+jQgcBpfPoMzFadIHkx3ehBhJqsRJuJlLj1ws5A4p22gZ x34rVnMRG3yL3CQXajKHb3nLDfsYFAfCgT0Uo= Received: by 10.52.174.115 with SMTP id br19mr13668303vdc.130.1320942433026; Thu, 10 Nov 2011 08:27:13 -0800 (PST) Received: from schism.local (75-146-225-65-Philadelphia.hfc.comcastbusiness.net. [75.146.225.65]) by mx.google.com with ESMTPS id z6sm2625773vdg.18.2011.11.10.08.27.07 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 08:27:11 -0800 (PST) Message-ID: <4EBBFB5B.8080102@gmail.com> Date: Thu, 10 Nov 2011 11:27:07 -0500 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <4EBB6787.8000300@gmail.com> <4EBBF572.9010805@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Warren Block , current@freebsd.org Subject: Re: Netgear WNA1000N USB wlan device 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, 10 Nov 2011 16:27:14 -0000 On 11/10/11 11:11 AM, Adrian Chadd wrote: > .. it's only good news if someone ports it. There's been efforts here > and there to tinker with it but no-one's submitted a working driver > for inclusion into -HEAD ;) > Agreed. :) Though, I may have gotten my hopes up for no reason. I've just tested the device in an OpenBSD 4.9 VM without much luck. Though, OpenBSD definitely recognizes the device is a wireless adapter, so I guess that's a plus... Thanks. Glen -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 17:00:14 2011 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 17A1E106566B; Thu, 10 Nov 2011 17:00:14 +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 C9E858FC1A; Thu, 10 Nov 2011 17:00:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAH0DTo081229; Thu, 10 Nov 2011 12:00:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAH0DQW081200; Thu, 10 Nov 2011 17:00:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 17:00:13 GMT Message-Id: <201111101700.pAAH0DQW081200@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: Thu, 10 Nov 2011 17:00:14 -0000 TB --- 2011-11-10 14:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 14:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-10 14:40:00 - cleaning the object tree TB --- 2011-11-10 14:40:21 - cvsupping the source tree TB --- 2011-11-10 14:40:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-10 14:40:34 - building world TB --- 2011-11-10 14:40:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 14:40:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 14:40:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 14:40:34 - SRCCONF=/dev/null TB --- 2011-11-10 14:40:34 - TARGET=pc98 TB --- 2011-11-10 14:40:34 - TARGET_ARCH=i386 TB --- 2011-11-10 14:40:34 - TZ=UTC TB --- 2011-11-10 14:40:34 - __MAKE_CONF=/dev/null TB --- 2011-11-10 14:40:34 - cd /src TB --- 2011-11-10 14:40:34 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 14:40:36 UTC 2011 >>> 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 Nov 10 16:52:05 UTC 2011 TB --- 2011-11-10 16:52:06 - generating LINT kernel config TB --- 2011-11-10 16:52:06 - cd /src/sys/pc98/conf TB --- 2011-11-10 16:52:06 - /usr/bin/make -B LINT TB --- 2011-11-10 16:52:06 - cd /src/sys/pc98/conf TB --- 2011-11-10 16:52:06 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 16:52:06 - building GENERIC kernel TB --- 2011-11-10 16:52:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:52:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:52:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:52:06 - SRCCONF=/dev/null TB --- 2011-11-10 16:52:06 - TARGET=pc98 TB --- 2011-11-10 16:52:06 - TARGET_ARCH=i386 TB --- 2011-11-10 16:52:06 - TZ=UTC TB --- 2011-11-10 16:52:06 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:52:06 - cd /src TB --- 2011-11-10 16:52:06 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 16:52:06 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 17:00:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 17:00:12 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 17:00:12 - 6723.03 user 1193.45 system 8411.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 17:15:16 2011 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 0516D106566C; Thu, 10 Nov 2011 17:15:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9A05F8FC0A; Thu, 10 Nov 2011 17:15:15 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so3808929vcb.13 for ; Thu, 10 Nov 2011 09:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dk6mgFsgyIoLwD4/QqfOwIFPK5aONaZw7dELYp0BHck=; b=Bz2vf1RyIQvmV+HKCOdvnWwLvIefgrRJoAFrFO7pqt/by5e6eEwkAcULf2Df2GV4VI L/DJ0H8/6iW2Y0H8AAgGa80ezaRmJWlGQRYg3RUyfqJr5LC4jPMjUkxM1SGfMdD/iB9B B61+ov+W1lm4i3/QmLyM1VBH3JaS+QVO64Exg= MIME-Version: 1.0 Received: by 10.52.24.210 with SMTP id w18mr14279089vdf.21.1320945314817; Thu, 10 Nov 2011 09:15:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 09:15:14 -0800 (PST) In-Reply-To: References: <201111100705.pAA75eIT023291@freebsd-current.sentex.ca> <4EBB7A0A.20700@FreeBSD.org> Date: Thu, 10 Nov 2011 09:15:14 -0800 X-Google-Sender-Auth: 0jHeGJJLY2Jl2DFZotMx2FmXXuU Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 10 Nov 2011 17:15:16 -0000 Hi, The problem right now is that when the code is compiled as a module, it sucks in -all- of the chipset support rather than only a subset. So there are two problems: * AH_SUPPORT_AR5416 is still needed to build the driver and HAL, and * the module builds all chipset support, whether or not AH_SUPPORT_AR5416 is defined. I notice that some modules do check whether VIMAGE is defined (.if defined(VIMAGE)) - is there some equally evil way that I can propagate some build time options to the module build to specify which modules are built, based on the existance or not of AH_SUPPORT_AR5416? (It gets messier, as at least two wireless SoC modules just don't need to be built unless the user definitely wants them to be.) I still think the correct thing to do at the present time is to explicitly not build the ath modules unless the architecture can use it, and if it can use it, build them with explicit net80211/ath configuration. Otherwise you end up with modules/kernel being out of sync in terms of configuration. For example, a user reported (and this is why I "fixed" sys/modules/ath/Makefile) that they had added ATH_DEBUG and AH_DEBUG - but because the Makefile overrides opt_ah.h regardless of whether it exists or not, it didn't include the debugging code. Similar hilarity occurs with/without IEEE80211_TDMA and IEEE80211_DEBUG for example. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 18:02:17 2011 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 065A4106564A; Thu, 10 Nov 2011 18:02:17 +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 CF6F08FC0A; Thu, 10 Nov 2011 18:02:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAI2Ftl033762; Thu, 10 Nov 2011 13:02:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAI2FQZ033683; Thu, 10 Nov 2011 18:02:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 18:02:15 GMT Message-Id: <201111101802.pAAI2FQZ033683@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: Thu, 10 Nov 2011 18:02:17 -0000 TB --- 2011-11-10 16:22:05 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 16:22:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-10 16:22:05 - cleaning the object tree TB --- 2011-11-10 16:22:17 - cvsupping the source tree TB --- 2011-11-10 16:22:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-10 16:22:29 - building world TB --- 2011-11-10 16:22:29 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:22:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:22:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:22:29 - SRCCONF=/dev/null TB --- 2011-11-10 16:22:29 - TARGET=ia64 TB --- 2011-11-10 16:22:29 - TARGET_ARCH=ia64 TB --- 2011-11-10 16:22:29 - TZ=UTC TB --- 2011-11-10 16:22:29 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:22:29 - cd /src TB --- 2011-11-10 16:22:29 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 16:22:30 UTC 2011 >>> 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 Nov 10 17:52:18 UTC 2011 TB --- 2011-11-10 17:52:18 - generating LINT kernel config TB --- 2011-11-10 17:52:18 - cd /src/sys/ia64/conf TB --- 2011-11-10 17:52:18 - /usr/bin/make -B LINT TB --- 2011-11-10 17:52:18 - cd /src/sys/ia64/conf TB --- 2011-11-10 17:52:18 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 17:52:18 - building GENERIC kernel TB --- 2011-11-10 17:52:18 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 17:52:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 17:52:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 17:52:18 - SRCCONF=/dev/null TB --- 2011-11-10 17:52:18 - TARGET=ia64 TB --- 2011-11-10 17:52:18 - TARGET_ARCH=ia64 TB --- 2011-11-10 17:52:18 - TZ=UTC TB --- 2011-11-10 17:52:18 - __MAKE_CONF=/dev/null TB --- 2011-11-10 17:52:18 - cd /src TB --- 2011-11-10 17:52:18 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 17:52:18 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 18:02:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 18:02:15 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 18:02:15 - 4757.26 user 912.12 system 6009.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:36:28 2011 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 3CCA8106578D; Thu, 10 Nov 2011 19:36: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 9EF278FC15; Thu, 10 Nov 2011 19:36:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAJaPbu031431; Thu, 10 Nov 2011 14:36:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAJaPJ2031423; Thu, 10 Nov 2011 19:36:25 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 19:36:25 GMT Message-Id: <201111101936.pAAJaPJ2031423@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/i386 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, 10 Nov 2011 19:36:28 -0000 TB --- 2011-11-10 14:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 14:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-10 14:40:00 - cleaning the object tree TB --- 2011-11-10 14:40:49 - cvsupping the source tree TB --- 2011-11-10 14:40:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-10 14:41:01 - building world TB --- 2011-11-10 14:41:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 14:41:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 14:41:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 14:41:01 - SRCCONF=/dev/null TB --- 2011-11-10 14:41:01 - TARGET=i386 TB --- 2011-11-10 14:41:01 - TARGET_ARCH=i386 TB --- 2011-11-10 14:41:01 - TZ=UTC TB --- 2011-11-10 14:41:01 - __MAKE_CONF=/dev/null TB --- 2011-11-10 14:41:01 - cd /src TB --- 2011-11-10 14:41:01 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 14:41:01 UTC 2011 >>> 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 Nov 10 16:52:56 UTC 2011 TB --- 2011-11-10 16:52:56 - generating LINT kernel config TB --- 2011-11-10 16:52:56 - cd /src/sys/i386/conf TB --- 2011-11-10 16:52:56 - /usr/bin/make -B LINT TB --- 2011-11-10 16:52:57 - cd /src/sys/i386/conf TB --- 2011-11-10 16:52:57 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-10 16:52:57 - building LINT-NOINET kernel TB --- 2011-11-10 16:52:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 16:52:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 16:52:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 16:52:57 - SRCCONF=/dev/null TB --- 2011-11-10 16:52:57 - TARGET=i386 TB --- 2011-11-10 16:52:57 - TARGET_ARCH=i386 TB --- 2011-11-10 16:52:57 - TZ=UTC TB --- 2011-11-10 16:52:57 - __MAKE_CONF=/dev/null TB --- 2011-11-10 16:52:57 - cd /src TB --- 2011-11-10 16:52:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 10 16:52:57 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET completed on Thu Nov 10 17:23:37 UTC 2011 TB --- 2011-11-10 17:23:37 - cd /src/sys/i386/conf TB --- 2011-11-10 17:23:37 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-10 17:23:37 - building LINT-NOINET6 kernel TB --- 2011-11-10 17:23:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 17:23:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 17:23:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 17:23:37 - SRCCONF=/dev/null TB --- 2011-11-10 17:23:37 - TARGET=i386 TB --- 2011-11-10 17:23:37 - TARGET_ARCH=i386 TB --- 2011-11-10 17:23:37 - TZ=UTC TB --- 2011-11-10 17:23:37 - __MAKE_CONF=/dev/null TB --- 2011-11-10 17:23:37 - cd /src TB --- 2011-11-10 17:23:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Nov 10 17:23:37 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET6 completed on Thu Nov 10 17:54:36 UTC 2011 TB --- 2011-11-10 17:54:36 - cd /src/sys/i386/conf TB --- 2011-11-10 17:54:36 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-10 17:54:36 - building LINT-NOIP kernel TB --- 2011-11-10 17:54:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 17:54:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 17:54:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 17:54:36 - SRCCONF=/dev/null TB --- 2011-11-10 17:54:36 - TARGET=i386 TB --- 2011-11-10 17:54:36 - TARGET_ARCH=i386 TB --- 2011-11-10 17:54:36 - TZ=UTC TB --- 2011-11-10 17:54:36 - __MAKE_CONF=/dev/null TB --- 2011-11-10 17:54:36 - cd /src TB --- 2011-11-10 17:54:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Nov 10 17:54:37 UTC 2011 >>> 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 >>> Kernel build for LINT-NOIP completed on Thu Nov 10 18:23:01 UTC 2011 TB --- 2011-11-10 18:23:01 - cd /src/sys/i386/conf TB --- 2011-11-10 18:23:01 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-10 18:23:01 - building LINT-VIMAGE kernel TB --- 2011-11-10 18:23:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 18:23:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 18:23:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 18:23:01 - SRCCONF=/dev/null TB --- 2011-11-10 18:23:01 - TARGET=i386 TB --- 2011-11-10 18:23:01 - TARGET_ARCH=i386 TB --- 2011-11-10 18:23:01 - TZ=UTC TB --- 2011-11-10 18:23:01 - __MAKE_CONF=/dev/null TB --- 2011-11-10 18:23:01 - cd /src TB --- 2011-11-10 18:23:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Nov 10 18:23:01 UTC 2011 >>> 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 >>> Kernel build for LINT-VIMAGE completed on Thu Nov 10 18:54:22 UTC 2011 TB --- 2011-11-10 18:54:22 - cd /src/sys/i386/conf TB --- 2011-11-10 18:54:22 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 18:54:22 - building GENERIC kernel TB --- 2011-11-10 18:54:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 18:54:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 18:54:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 18:54:22 - SRCCONF=/dev/null TB --- 2011-11-10 18:54:22 - TARGET=i386 TB --- 2011-11-10 18:54:22 - TARGET_ARCH=i386 TB --- 2011-11-10 18:54:22 - TZ=UTC TB --- 2011-11-10 18:54:22 - __MAKE_CONF=/dev/null TB --- 2011-11-10 18:54:22 - cd /src TB --- 2011-11-10 18:54:22 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 18:54:23 UTC 2011 >>> 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 >>> Kernel build for GENERIC completed on Thu Nov 10 19:19:22 UTC 2011 TB --- 2011-11-10 19:19:22 - cd /src/sys/i386/conf TB --- 2011-11-10 19:19:22 - /usr/sbin/config -m PAE TB --- 2011-11-10 19:19:22 - building PAE kernel TB --- 2011-11-10 19:19:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 19:19:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 19:19:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 19:19:22 - SRCCONF=/dev/null TB --- 2011-11-10 19:19:22 - TARGET=i386 TB --- 2011-11-10 19:19:22 - TARGET_ARCH=i386 TB --- 2011-11-10 19:19:22 - TZ=UTC TB --- 2011-11-10 19:19:22 - __MAKE_CONF=/dev/null TB --- 2011-11-10 19:19:22 - cd /src TB --- 2011-11-10 19:19:22 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Thu Nov 10 19:19:22 UTC 2011 >>> 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 >>> Kernel build for PAE completed on Thu Nov 10 19:26:06 UTC 2011 TB --- 2011-11-10 19:26:06 - cd /src/sys/i386/conf TB --- 2011-11-10 19:26:06 - /usr/sbin/config -m XBOX TB --- 2011-11-10 19:26:06 - building XBOX kernel TB --- 2011-11-10 19:26:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 19:26:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 19:26:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 19:26:06 - SRCCONF=/dev/null TB --- 2011-11-10 19:26:06 - TARGET=i386 TB --- 2011-11-10 19:26:06 - TARGET_ARCH=i386 TB --- 2011-11-10 19:26:06 - TZ=UTC TB --- 2011-11-10 19:26:06 - __MAKE_CONF=/dev/null TB --- 2011-11-10 19:26:06 - cd /src TB --- 2011-11-10 19:26:06 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Thu Nov 10 19:26:06 UTC 2011 >>> 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 >>> Kernel build for XBOX completed on Thu Nov 10 19:29:21 UTC 2011 TB --- 2011-11-10 19:29:21 - cd /src/sys/i386/conf TB --- 2011-11-10 19:29:21 - /usr/sbin/config -m XEN TB --- 2011-11-10 19:29:21 - building XEN kernel TB --- 2011-11-10 19:29:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 19:29:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 19:29:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 19:29:21 - SRCCONF=/dev/null TB --- 2011-11-10 19:29:21 - TARGET=i386 TB --- 2011-11-10 19:29:21 - TARGET_ARCH=i386 TB --- 2011-11-10 19:29:21 - TZ=UTC TB --- 2011-11-10 19:29:21 - __MAKE_CONF=/dev/null TB --- 2011-11-10 19:29:21 - cd /src TB --- 2011-11-10 19:29:21 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Thu Nov 10 19:29:21 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 19:36:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 19:36:24 - ERROR: failed to build XEN kernel TB --- 2011-11-10 19:36:24 - 14188.42 user 2442.88 system 17784.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:52:57 2011 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 1265E106564A; Thu, 10 Nov 2011 19:52: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 D44D78FC16; Thu, 10 Nov 2011 19:52:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAJquKt047847; Thu, 10 Nov 2011 14:52:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAJquVH047822; Thu, 10 Nov 2011 19:52:56 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 19:52:56 GMT Message-Id: <201111101952.pAAJquVH047822@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, 10 Nov 2011 19:52:57 -0000 TB --- 2011-11-10 18:02:16 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 18:02:16 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-10 18:02:16 - cleaning the object tree TB --- 2011-11-10 18:02:30 - cvsupping the source tree TB --- 2011-11-10 18:02:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-10 18:02:41 - building world TB --- 2011-11-10 18:02:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 18:02:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 18:02:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 18:02:41 - SRCCONF=/dev/null TB --- 2011-11-10 18:02:41 - TARGET=powerpc TB --- 2011-11-10 18:02:41 - TARGET_ARCH=powerpc64 TB --- 2011-11-10 18:02:41 - TZ=UTC TB --- 2011-11-10 18:02:41 - __MAKE_CONF=/dev/null TB --- 2011-11-10 18:02:41 - cd /src TB --- 2011-11-10 18:02:41 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 18:02:42 UTC 2011 >>> 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 Nov 10 19:44:48 UTC 2011 TB --- 2011-11-10 19:44:48 - generating LINT kernel config TB --- 2011-11-10 19:44:48 - cd /src/sys/powerpc/conf TB --- 2011-11-10 19:44:48 - /usr/bin/make -B LINT TB --- 2011-11-10 19:44:48 - cd /src/sys/powerpc/conf TB --- 2011-11-10 19:44:48 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 19:44:48 - skipping GENERIC kernel TB --- 2011-11-10 19:44:48 - cd /src/sys/powerpc/conf TB --- 2011-11-10 19:44:48 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-10 19:44:48 - building GENERIC64 kernel TB --- 2011-11-10 19:44:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 19:44:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 19:44:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 19:44:48 - SRCCONF=/dev/null TB --- 2011-11-10 19:44:48 - TARGET=powerpc TB --- 2011-11-10 19:44:48 - TARGET_ARCH=powerpc64 TB --- 2011-11-10 19:44:48 - TZ=UTC TB --- 2011-11-10 19:44:48 - __MAKE_CONF=/dev/null TB --- 2011-11-10 19:44:48 - cd /src TB --- 2011-11-10 19:44:48 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 10 19:44:48 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 19:52:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 19:52:55 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-10 19:52:55 - 4964.46 user 1133.80 system 6639.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 20:08:31 2011 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 CB6D4106564A; Thu, 10 Nov 2011 20:08:31 +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 9FD8F8FC0C; Thu, 10 Nov 2011 20:08:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAK8UZd024993; Thu, 10 Nov 2011 15:08:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAK8U6F024977; Thu, 10 Nov 2011 20:08:30 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 20:08:30 GMT Message-Id: <201111102008.pAAK8U6F024977@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, 10 Nov 2011 20:08:32 -0000 TB --- 2011-11-10 18:00:11 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 18:00:11 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-10 18:00:11 - cleaning the object tree TB --- 2011-11-10 18:00:32 - cvsupping the source tree TB --- 2011-11-10 18:00:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-10 18:00:51 - building world TB --- 2011-11-10 18:00:51 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 18:00:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 18:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 18:00:51 - SRCCONF=/dev/null TB --- 2011-11-10 18:00:51 - TARGET=powerpc TB --- 2011-11-10 18:00:51 - TARGET_ARCH=powerpc TB --- 2011-11-10 18:00:51 - TZ=UTC TB --- 2011-11-10 18:00:51 - __MAKE_CONF=/dev/null TB --- 2011-11-10 18:00:51 - cd /src TB --- 2011-11-10 18:00:51 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 18:00:52 UTC 2011 >>> 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 Nov 10 20:02:19 UTC 2011 TB --- 2011-11-10 20:02:19 - generating LINT kernel config TB --- 2011-11-10 20:02:19 - cd /src/sys/powerpc/conf TB --- 2011-11-10 20:02:19 - /usr/bin/make -B LINT TB --- 2011-11-10 20:02:19 - cd /src/sys/powerpc/conf TB --- 2011-11-10 20:02:19 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 20:02:19 - building GENERIC kernel TB --- 2011-11-10 20:02:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 20:02:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 20:02:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 20:02:19 - SRCCONF=/dev/null TB --- 2011-11-10 20:02:19 - TARGET=powerpc TB --- 2011-11-10 20:02:19 - TARGET_ARCH=powerpc TB --- 2011-11-10 20:02:19 - TZ=UTC TB --- 2011-11-10 20:02:19 - __MAKE_CONF=/dev/null TB --- 2011-11-10 20:02:19 - cd /src TB --- 2011-11-10 20:02:19 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 20:02:19 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 20:08:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 20:08:30 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 20:08:30 - 6225.80 user 1065.49 system 7699.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 22:42:36 2011 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 55123106564A; Thu, 10 Nov 2011 22:42: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 124BD8FC13; Thu, 10 Nov 2011 22:42:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAAMgUNb043385; Thu, 10 Nov 2011 17:42:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAAMgU18043320; Thu, 10 Nov 2011 22:42:30 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 22:42:30 GMT Message-Id: <201111102242.pAAMgU18043320@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 arm/arm 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, 10 Nov 2011 22:42:36 -0000 TB --- 2011-11-10 21:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 21:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-10 21:00:00 - cleaning the object tree TB --- 2011-11-10 21:00:29 - cvsupping the source tree TB --- 2011-11-10 21:00:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-10 21:00:57 - building world TB --- 2011-11-10 21:00:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 21:00:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 21:00:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 21:00:57 - SRCCONF=/dev/null TB --- 2011-11-10 21:00:57 - TARGET=arm TB --- 2011-11-10 21:00:57 - TARGET_ARCH=arm TB --- 2011-11-10 21:00:57 - TZ=UTC TB --- 2011-11-10 21:00:57 - __MAKE_CONF=/dev/null TB --- 2011-11-10 21:00:57 - cd /src TB --- 2011-11-10 21:00:57 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 21:00:58 UTC 2011 >>> 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 Nov 10 21:57:02 UTC 2011 TB --- 2011-11-10 21:57:02 - cd /src/sys/arm/conf TB --- 2011-11-10 21:57:02 - /usr/sbin/config -m AVILA TB --- 2011-11-10 21:57:02 - building AVILA kernel TB --- 2011-11-10 21:57:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 21:57:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 21:57:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 21:57:02 - SRCCONF=/dev/null TB --- 2011-11-10 21:57:02 - TARGET=arm TB --- 2011-11-10 21:57:02 - TARGET_ARCH=arm TB --- 2011-11-10 21:57:02 - TZ=UTC TB --- 2011-11-10 21:57:02 - __MAKE_CONF=/dev/null TB --- 2011-11-10 21:57:02 - cd /src TB --- 2011-11-10 21:57:02 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 10 21:57:03 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 10 22:00:35 UTC 2011 TB --- 2011-11-10 22:00:35 - cd /src/sys/arm/conf TB --- 2011-11-10 22:00:35 - /usr/sbin/config -m BWCT TB --- 2011-11-10 22:00:35 - building BWCT kernel TB --- 2011-11-10 22:00:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:00:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:00:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:00:35 - SRCCONF=/dev/null TB --- 2011-11-10 22:00:35 - TARGET=arm TB --- 2011-11-10 22:00:35 - TARGET_ARCH=arm TB --- 2011-11-10 22:00:35 - TZ=UTC TB --- 2011-11-10 22:00:35 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:00:35 - cd /src TB --- 2011-11-10 22:00:35 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 10 22:00:35 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 10 22:02:45 UTC 2011 TB --- 2011-11-10 22:02:45 - cd /src/sys/arm/conf TB --- 2011-11-10 22:02:45 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-10 22:02:45 - building CAMBRIA kernel TB --- 2011-11-10 22:02:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:02:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:02:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:02:45 - SRCCONF=/dev/null TB --- 2011-11-10 22:02:45 - TARGET=arm TB --- 2011-11-10 22:02:45 - TARGET_ARCH=arm TB --- 2011-11-10 22:02:45 - TZ=UTC TB --- 2011-11-10 22:02:45 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:02:45 - cd /src TB --- 2011-11-10 22:02:45 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 10 22:02:45 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 10 22:05:43 UTC 2011 TB --- 2011-11-10 22:05:43 - cd /src/sys/arm/conf TB --- 2011-11-10 22:05:43 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-10 22:05:44 - building CNS11XXNAS kernel TB --- 2011-11-10 22:05:44 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:05:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:05:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:05:44 - SRCCONF=/dev/null TB --- 2011-11-10 22:05:44 - TARGET=arm TB --- 2011-11-10 22:05:44 - TARGET_ARCH=arm TB --- 2011-11-10 22:05:44 - TZ=UTC TB --- 2011-11-10 22:05:44 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:05:44 - cd /src TB --- 2011-11-10 22:05:44 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 10 22:05:44 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 10 22:08:41 UTC 2011 TB --- 2011-11-10 22:08:41 - cd /src/sys/arm/conf TB --- 2011-11-10 22:08:41 - /usr/sbin/config -m CRB TB --- 2011-11-10 22:08:41 - building CRB kernel TB --- 2011-11-10 22:08:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:08:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:08:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:08:41 - SRCCONF=/dev/null TB --- 2011-11-10 22:08:41 - TARGET=arm TB --- 2011-11-10 22:08:41 - TARGET_ARCH=arm TB --- 2011-11-10 22:08:41 - TZ=UTC TB --- 2011-11-10 22:08:41 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:08:41 - cd /src TB --- 2011-11-10 22:08:41 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 10 22:08:41 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 10 22:12:02 UTC 2011 TB --- 2011-11-10 22:12:02 - cd /src/sys/arm/conf TB --- 2011-11-10 22:12:02 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-10 22:12:02 - building DB-78XXX kernel TB --- 2011-11-10 22:12:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:12:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:12:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:12:02 - SRCCONF=/dev/null TB --- 2011-11-10 22:12:02 - TARGET=arm TB --- 2011-11-10 22:12:02 - TARGET_ARCH=arm TB --- 2011-11-10 22:12:02 - TZ=UTC TB --- 2011-11-10 22:12:02 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:12:02 - cd /src TB --- 2011-11-10 22:12:02 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 10 22:12:02 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 10 22:15:10 UTC 2011 TB --- 2011-11-10 22:15:10 - cd /src/sys/arm/conf TB --- 2011-11-10 22:15:10 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-10 22:15:10 - building DB-88F5XXX kernel TB --- 2011-11-10 22:15:10 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:15:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:15:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:15:10 - SRCCONF=/dev/null TB --- 2011-11-10 22:15:10 - TARGET=arm TB --- 2011-11-10 22:15:10 - TARGET_ARCH=arm TB --- 2011-11-10 22:15:10 - TZ=UTC TB --- 2011-11-10 22:15:10 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:15:10 - cd /src TB --- 2011-11-10 22:15:10 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 10 22:15:10 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 10 22:17:48 UTC 2011 TB --- 2011-11-10 22:17:48 - cd /src/sys/arm/conf TB --- 2011-11-10 22:17:48 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-10 22:17:48 - building DB-88F6XXX kernel TB --- 2011-11-10 22:17:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:17:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:17:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:17:48 - SRCCONF=/dev/null TB --- 2011-11-10 22:17:48 - TARGET=arm TB --- 2011-11-10 22:17:48 - TARGET_ARCH=arm TB --- 2011-11-10 22:17:48 - TZ=UTC TB --- 2011-11-10 22:17:48 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:17:48 - cd /src TB --- 2011-11-10 22:17:48 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 10 22:17:48 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 10 22:20:25 UTC 2011 TB --- 2011-11-10 22:20:25 - cd /src/sys/arm/conf TB --- 2011-11-10 22:20:25 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-10 22:20:25 - building DOCKSTAR kernel TB --- 2011-11-10 22:20:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:20:25 - SRCCONF=/dev/null TB --- 2011-11-10 22:20:25 - TARGET=arm TB --- 2011-11-10 22:20:25 - TARGET_ARCH=arm TB --- 2011-11-10 22:20:25 - TZ=UTC TB --- 2011-11-10 22:20:25 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:20:25 - cd /src TB --- 2011-11-10 22:20:25 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 10 22:20:25 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 10 22:23:28 UTC 2011 TB --- 2011-11-10 22:23:28 - cd /src/sys/arm/conf TB --- 2011-11-10 22:23:28 - /usr/sbin/config -m EP80219 TB --- 2011-11-10 22:23:28 - building EP80219 kernel TB --- 2011-11-10 22:23:28 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:23:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:23:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:23:28 - SRCCONF=/dev/null TB --- 2011-11-10 22:23:28 - TARGET=arm TB --- 2011-11-10 22:23:28 - TARGET_ARCH=arm TB --- 2011-11-10 22:23:28 - TZ=UTC TB --- 2011-11-10 22:23:28 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:23:28 - cd /src TB --- 2011-11-10 22:23:28 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 10 22:23:28 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 10 22:26:21 UTC 2011 TB --- 2011-11-10 22:26:21 - WARNING: no kernel config for GENERIC TB --- 2011-11-10 22:26:21 - cd /src/sys/arm/conf TB --- 2011-11-10 22:26:21 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-10 22:26:21 - building GUMSTIX kernel TB --- 2011-11-10 22:26:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:26:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:26:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:26:21 - SRCCONF=/dev/null TB --- 2011-11-10 22:26:21 - TARGET=arm TB --- 2011-11-10 22:26:21 - TARGET_ARCH=arm TB --- 2011-11-10 22:26:21 - TZ=UTC TB --- 2011-11-10 22:26:21 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:26:21 - cd /src TB --- 2011-11-10 22:26:21 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 10 22:26:21 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 10 22:28:38 UTC 2011 TB --- 2011-11-10 22:28:38 - cd /src/sys/arm/conf TB --- 2011-11-10 22:28:38 - /usr/sbin/config -m HL200 TB --- 2011-11-10 22:28:41 - building HL200 kernel TB --- 2011-11-10 22:28:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:28:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:28:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:28:41 - SRCCONF=/dev/null TB --- 2011-11-10 22:28:41 - TARGET=arm TB --- 2011-11-10 22:28:41 - TARGET_ARCH=arm TB --- 2011-11-10 22:28:41 - TZ=UTC TB --- 2011-11-10 22:28:41 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:28:41 - cd /src TB --- 2011-11-10 22:28:41 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 10 22:28:41 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 10 22:31:47 UTC 2011 TB --- 2011-11-10 22:31:47 - cd /src/sys/arm/conf TB --- 2011-11-10 22:31:47 - /usr/sbin/config -m HL201 TB --- 2011-11-10 22:31:49 - building HL201 kernel TB --- 2011-11-10 22:31:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:31:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:31:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:31:49 - SRCCONF=/dev/null TB --- 2011-11-10 22:31:49 - TARGET=arm TB --- 2011-11-10 22:31:49 - TARGET_ARCH=arm TB --- 2011-11-10 22:31:49 - TZ=UTC TB --- 2011-11-10 22:31:49 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:31:49 - cd /src TB --- 2011-11-10 22:31:49 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 10 22:31:49 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 10 22:34:04 UTC 2011 TB --- 2011-11-10 22:34:04 - cd /src/sys/arm/conf TB --- 2011-11-10 22:34:04 - /usr/sbin/config -m IQ31244 TB --- 2011-11-10 22:34:04 - building IQ31244 kernel TB --- 2011-11-10 22:34:04 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:34:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:34:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:34:04 - SRCCONF=/dev/null TB --- 2011-11-10 22:34:04 - TARGET=arm TB --- 2011-11-10 22:34:04 - TARGET_ARCH=arm TB --- 2011-11-10 22:34:04 - TZ=UTC TB --- 2011-11-10 22:34:04 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:34:04 - cd /src TB --- 2011-11-10 22:34:04 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 10 22:34:04 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 10 22:37:18 UTC 2011 TB --- 2011-11-10 22:37:18 - cd /src/sys/arm/conf TB --- 2011-11-10 22:37:18 - /usr/sbin/config -m KB920X TB --- 2011-11-10 22:37:19 - building KB920X kernel TB --- 2011-11-10 22:37:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:37:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:37:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:37:19 - SRCCONF=/dev/null TB --- 2011-11-10 22:37:19 - TARGET=arm TB --- 2011-11-10 22:37:19 - TARGET_ARCH=arm TB --- 2011-11-10 22:37:19 - TZ=UTC TB --- 2011-11-10 22:37:19 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:37:19 - cd /src TB --- 2011-11-10 22:37:19 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 10 22:37:19 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 22:42:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 22:42:29 - ERROR: failed to build KB920X kernel TB --- 2011-11-10 22:42:29 - 4574.45 user 1142.27 system 6149.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 23:20:45 2011 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 2439A1065670; Thu, 10 Nov 2011 23:20:45 +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 E522F8FC1C; Thu, 10 Nov 2011 23:20:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAANKi2l012945; Thu, 10 Nov 2011 18:20:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAANKixh012922; Thu, 10 Nov 2011 23:20:44 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Nov 2011 23:20:44 GMT Message-Id: <201111102320.pAANKixh012922@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: Thu, 10 Nov 2011 23:20:45 -0000 TB --- 2011-11-10 21:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 21:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-10 21:00:00 - cleaning the object tree TB --- 2011-11-10 21:00:25 - cvsupping the source tree TB --- 2011-11-10 21:00:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-10 21:00:57 - building world TB --- 2011-11-10 21:00:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 21:00:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 21:00:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 21:00:57 - SRCCONF=/dev/null TB --- 2011-11-10 21:00:57 - TARGET=pc98 TB --- 2011-11-10 21:00:57 - TARGET_ARCH=i386 TB --- 2011-11-10 21:00:57 - TZ=UTC TB --- 2011-11-10 21:00:57 - __MAKE_CONF=/dev/null TB --- 2011-11-10 21:00:57 - cd /src TB --- 2011-11-10 21:00:57 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 21:00:58 UTC 2011 >>> 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 Nov 10 23:12:36 UTC 2011 TB --- 2011-11-10 23:12:36 - generating LINT kernel config TB --- 2011-11-10 23:12:36 - cd /src/sys/pc98/conf TB --- 2011-11-10 23:12:36 - /usr/bin/make -B LINT TB --- 2011-11-10 23:12:36 - cd /src/sys/pc98/conf TB --- 2011-11-10 23:12:36 - /usr/sbin/config -m GENERIC TB --- 2011-11-10 23:12:36 - building GENERIC kernel TB --- 2011-11-10 23:12:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 23:12:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 23:12:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 23:12:36 - SRCCONF=/dev/null TB --- 2011-11-10 23:12:36 - TARGET=pc98 TB --- 2011-11-10 23:12:36 - TARGET_ARCH=i386 TB --- 2011-11-10 23:12:36 - TZ=UTC TB --- 2011-11-10 23:12:36 - __MAKE_CONF=/dev/null TB --- 2011-11-10 23:12:36 - cd /src TB --- 2011-11-10 23:12:36 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 10 23:12:36 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-10 23:20:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-10 23:20:43 - ERROR: failed to build GENERIC kernel TB --- 2011-11-10 23:20:43 - 6737.02 user 1193.78 system 8443.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 00:22:41 2011 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 4166F106566C; Fri, 11 Nov 2011 00:22:41 +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 146708FC14; Fri, 11 Nov 2011 00:22:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAB0MeKR076003; Thu, 10 Nov 2011 19:22:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAB0Me3W075985; Fri, 11 Nov 2011 00:22:40 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 11 Nov 2011 00:22:40 GMT Message-Id: <201111110022.pAB0Me3W075985@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: Fri, 11 Nov 2011 00:22:41 -0000 TB --- 2011-11-10 22:42:30 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 22:42:30 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-10 22:42:30 - cleaning the object tree TB --- 2011-11-10 22:42:45 - cvsupping the source tree TB --- 2011-11-10 22:42:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-10 22:42:58 - building world TB --- 2011-11-10 22:42:58 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 22:42:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 22:42:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 22:42:58 - SRCCONF=/dev/null TB --- 2011-11-10 22:42:58 - TARGET=ia64 TB --- 2011-11-10 22:42:58 - TARGET_ARCH=ia64 TB --- 2011-11-10 22:42:58 - TZ=UTC TB --- 2011-11-10 22:42:58 - __MAKE_CONF=/dev/null TB --- 2011-11-10 22:42:58 - cd /src TB --- 2011-11-10 22:42:58 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 22:42:58 UTC 2011 >>> 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 Fri Nov 11 00:12:34 UTC 2011 TB --- 2011-11-11 00:12:35 - generating LINT kernel config TB --- 2011-11-11 00:12:35 - cd /src/sys/ia64/conf TB --- 2011-11-11 00:12:35 - /usr/bin/make -B LINT TB --- 2011-11-11 00:12:35 - cd /src/sys/ia64/conf TB --- 2011-11-11 00:12:35 - /usr/sbin/config -m GENERIC TB --- 2011-11-11 00:12:35 - building GENERIC kernel TB --- 2011-11-11 00:12:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 00:12:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 00:12:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 00:12:35 - SRCCONF=/dev/null TB --- 2011-11-11 00:12:35 - TARGET=ia64 TB --- 2011-11-11 00:12:35 - TARGET_ARCH=ia64 TB --- 2011-11-11 00:12:35 - TZ=UTC TB --- 2011-11-11 00:12:35 - __MAKE_CONF=/dev/null TB --- 2011-11-11 00:12:35 - cd /src TB --- 2011-11-11 00:12:35 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 11 00:12:35 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-11 00:22:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-11 00:22:39 - ERROR: failed to build GENERIC kernel TB --- 2011-11-11 00:22:39 - 4720.67 user 916.48 system 6008.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 01:56:09 2011 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 E6BA7106566C; Fri, 11 Nov 2011 01:56:08 +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 B896C8FC0C; Fri, 11 Nov 2011 01:56:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAB1u7uG076499; Thu, 10 Nov 2011 20:56:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAB1u7mK076488; Fri, 11 Nov 2011 01:56:07 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 11 Nov 2011 01:56:07 GMT Message-Id: <201111110156.pAB1u7mK076488@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/i386 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: Fri, 11 Nov 2011 01:56:09 -0000 TB --- 2011-11-10 21:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 21:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-10 21:00:00 - cleaning the object tree TB --- 2011-11-10 21:00:53 - cvsupping the source tree TB --- 2011-11-10 21:00:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-10 21:01:04 - building world TB --- 2011-11-10 21:01:04 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 21:01:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 21:01:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 21:01:04 - SRCCONF=/dev/null TB --- 2011-11-10 21:01:04 - TARGET=i386 TB --- 2011-11-10 21:01:04 - TARGET_ARCH=i386 TB --- 2011-11-10 21:01:04 - TZ=UTC TB --- 2011-11-10 21:01:04 - __MAKE_CONF=/dev/null TB --- 2011-11-10 21:01:04 - cd /src TB --- 2011-11-10 21:01:04 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 10 21:01:04 UTC 2011 >>> 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 Nov 10 23:12:44 UTC 2011 TB --- 2011-11-10 23:12:45 - generating LINT kernel config TB --- 2011-11-10 23:12:45 - cd /src/sys/i386/conf TB --- 2011-11-10 23:12:45 - /usr/bin/make -B LINT TB --- 2011-11-10 23:12:45 - cd /src/sys/i386/conf TB --- 2011-11-10 23:12:45 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-10 23:12:45 - building LINT-NOINET kernel TB --- 2011-11-10 23:12:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 23:12:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 23:12:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 23:12:45 - SRCCONF=/dev/null TB --- 2011-11-10 23:12:45 - TARGET=i386 TB --- 2011-11-10 23:12:45 - TARGET_ARCH=i386 TB --- 2011-11-10 23:12:45 - TZ=UTC TB --- 2011-11-10 23:12:45 - __MAKE_CONF=/dev/null TB --- 2011-11-10 23:12:45 - cd /src TB --- 2011-11-10 23:12:45 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 10 23:12:45 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET completed on Thu Nov 10 23:43:27 UTC 2011 TB --- 2011-11-10 23:43:27 - cd /src/sys/i386/conf TB --- 2011-11-10 23:43:27 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-10 23:43:27 - building LINT-NOINET6 kernel TB --- 2011-11-10 23:43:27 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 23:43:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 23:43:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 23:43:27 - SRCCONF=/dev/null TB --- 2011-11-10 23:43:27 - TARGET=i386 TB --- 2011-11-10 23:43:27 - TARGET_ARCH=i386 TB --- 2011-11-10 23:43:27 - TZ=UTC TB --- 2011-11-10 23:43:27 - __MAKE_CONF=/dev/null TB --- 2011-11-10 23:43:27 - cd /src TB --- 2011-11-10 23:43:27 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Nov 10 23:43:27 UTC 2011 >>> 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 >>> Kernel build for LINT-NOINET6 completed on Fri Nov 11 00:14:36 UTC 2011 TB --- 2011-11-11 00:14:36 - cd /src/sys/i386/conf TB --- 2011-11-11 00:14:36 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-11 00:14:36 - building LINT-NOIP kernel TB --- 2011-11-11 00:14:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 00:14:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 00:14:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 00:14:36 - SRCCONF=/dev/null TB --- 2011-11-11 00:14:36 - TARGET=i386 TB --- 2011-11-11 00:14:36 - TARGET_ARCH=i386 TB --- 2011-11-11 00:14:36 - TZ=UTC TB --- 2011-11-11 00:14:36 - __MAKE_CONF=/dev/null TB --- 2011-11-11 00:14:36 - cd /src TB --- 2011-11-11 00:14:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Nov 11 00:14:36 UTC 2011 >>> 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 >>> Kernel build for LINT-NOIP completed on Fri Nov 11 00:42:29 UTC 2011 TB --- 2011-11-11 00:42:29 - cd /src/sys/i386/conf TB --- 2011-11-11 00:42:29 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-11 00:42:29 - building LINT-VIMAGE kernel TB --- 2011-11-11 00:42:29 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 00:42:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 00:42:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 00:42:29 - SRCCONF=/dev/null TB --- 2011-11-11 00:42:29 - TARGET=i386 TB --- 2011-11-11 00:42:29 - TARGET_ARCH=i386 TB --- 2011-11-11 00:42:29 - TZ=UTC TB --- 2011-11-11 00:42:29 - __MAKE_CONF=/dev/null TB --- 2011-11-11 00:42:29 - cd /src TB --- 2011-11-11 00:42:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Fri Nov 11 00:42:29 UTC 2011 >>> 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 >>> Kernel build for LINT-VIMAGE completed on Fri Nov 11 01:13:54 UTC 2011 TB --- 2011-11-11 01:13:54 - cd /src/sys/i386/conf TB --- 2011-11-11 01:13:54 - /usr/sbin/config -m GENERIC TB --- 2011-11-11 01:13:54 - building GENERIC kernel TB --- 2011-11-11 01:13:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 01:13:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 01:13:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 01:13:54 - SRCCONF=/dev/null TB --- 2011-11-11 01:13:54 - TARGET=i386 TB --- 2011-11-11 01:13:54 - TARGET_ARCH=i386 TB --- 2011-11-11 01:13:54 - TZ=UTC TB --- 2011-11-11 01:13:54 - __MAKE_CONF=/dev/null TB --- 2011-11-11 01:13:54 - cd /src TB --- 2011-11-11 01:13:54 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 11 01:13:54 UTC 2011 >>> 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 >>> Kernel build for GENERIC completed on Fri Nov 11 01:38:52 UTC 2011 TB --- 2011-11-11 01:38:52 - cd /src/sys/i386/conf TB --- 2011-11-11 01:38:52 - /usr/sbin/config -m PAE TB --- 2011-11-11 01:38:52 - building PAE kernel TB --- 2011-11-11 01:38:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 01:38:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 01:38:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 01:38:52 - SRCCONF=/dev/null TB --- 2011-11-11 01:38:52 - TARGET=i386 TB --- 2011-11-11 01:38:52 - TARGET_ARCH=i386 TB --- 2011-11-11 01:38:52 - TZ=UTC TB --- 2011-11-11 01:38:52 - __MAKE_CONF=/dev/null TB --- 2011-11-11 01:38:52 - cd /src TB --- 2011-11-11 01:38:52 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Nov 11 01:38:52 UTC 2011 >>> 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 >>> Kernel build for PAE completed on Fri Nov 11 01:45:45 UTC 2011 TB --- 2011-11-11 01:45:45 - cd /src/sys/i386/conf TB --- 2011-11-11 01:45:45 - /usr/sbin/config -m XBOX TB --- 2011-11-11 01:45:45 - building XBOX kernel TB --- 2011-11-11 01:45:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 01:45:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 01:45:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 01:45:45 - SRCCONF=/dev/null TB --- 2011-11-11 01:45:45 - TARGET=i386 TB --- 2011-11-11 01:45:45 - TARGET_ARCH=i386 TB --- 2011-11-11 01:45:45 - TZ=UTC TB --- 2011-11-11 01:45:45 - __MAKE_CONF=/dev/null TB --- 2011-11-11 01:45:45 - cd /src TB --- 2011-11-11 01:45:45 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Fri Nov 11 01:45:45 UTC 2011 >>> 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 >>> Kernel build for XBOX completed on Fri Nov 11 01:49:04 UTC 2011 TB --- 2011-11-11 01:49:04 - cd /src/sys/i386/conf TB --- 2011-11-11 01:49:04 - /usr/sbin/config -m XEN TB --- 2011-11-11 01:49:04 - building XEN kernel TB --- 2011-11-11 01:49:04 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 01:49:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 01:49:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 01:49:04 - SRCCONF=/dev/null TB --- 2011-11-11 01:49:04 - TARGET=i386 TB --- 2011-11-11 01:49:04 - TARGET_ARCH=i386 TB --- 2011-11-11 01:49:04 - TZ=UTC TB --- 2011-11-11 01:49:04 - __MAKE_CONF=/dev/null TB --- 2011-11-11 01:49:04 - cd /src TB --- 2011-11-11 01:49:04 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Nov 11 01:49:04 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-11 01:56:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-11 01:56:06 - ERROR: failed to build XEN kernel TB --- 2011-11-11 01:56:07 - 14169.23 user 2439.74 system 17766.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 02:13:39 2011 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 EE0A3106566B; Fri, 11 Nov 2011 02:13:38 +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 A10C08FC16; Fri, 11 Nov 2011 02:13:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAB2Dbsw001286; Thu, 10 Nov 2011 21:13:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAB2Dbf3001281; Fri, 11 Nov 2011 02:13:37 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 11 Nov 2011 02:13:37 GMT Message-Id: <201111110213.pAB2Dbf3001281@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: Fri, 11 Nov 2011 02:13:39 -0000 TB --- 2011-11-11 00:22:40 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-11 00:22:40 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-11 00:22:40 - cleaning the object tree TB --- 2011-11-11 00:22:56 - cvsupping the source tree TB --- 2011-11-11 00:22:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-11 00:23:08 - building world TB --- 2011-11-11 00:23:08 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 00:23:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 00:23:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 00:23:08 - SRCCONF=/dev/null TB --- 2011-11-11 00:23:08 - TARGET=powerpc TB --- 2011-11-11 00:23:08 - TARGET_ARCH=powerpc64 TB --- 2011-11-11 00:23:08 - TZ=UTC TB --- 2011-11-11 00:23:08 - __MAKE_CONF=/dev/null TB --- 2011-11-11 00:23:08 - cd /src TB --- 2011-11-11 00:23:08 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 11 00:23:08 UTC 2011 >>> 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 Fri Nov 11 02:05:32 UTC 2011 TB --- 2011-11-11 02:05:32 - generating LINT kernel config TB --- 2011-11-11 02:05:32 - cd /src/sys/powerpc/conf TB --- 2011-11-11 02:05:32 - /usr/bin/make -B LINT TB --- 2011-11-11 02:05:32 - cd /src/sys/powerpc/conf TB --- 2011-11-11 02:05:32 - /usr/sbin/config -m GENERIC TB --- 2011-11-11 02:05:32 - skipping GENERIC kernel TB --- 2011-11-11 02:05:32 - cd /src/sys/powerpc/conf TB --- 2011-11-11 02:05:32 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-11 02:05:32 - building GENERIC64 kernel TB --- 2011-11-11 02:05:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 02:05:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 02:05:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 02:05:32 - SRCCONF=/dev/null TB --- 2011-11-11 02:05:32 - TARGET=powerpc TB --- 2011-11-11 02:05:32 - TARGET_ARCH=powerpc64 TB --- 2011-11-11 02:05:32 - TZ=UTC TB --- 2011-11-11 02:05:32 - __MAKE_CONF=/dev/null TB --- 2011-11-11 02:05:32 - cd /src TB --- 2011-11-11 02:05:32 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Fri Nov 11 02:05:32 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-11 02:13:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-11 02:13:37 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-11 02:13:37 - 4942.64 user 1145.05 system 6656.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 02:29:34 2011 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 1F50D106566B; Fri, 11 Nov 2011 02:29:34 +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 DFFDD8FC13; Fri, 11 Nov 2011 02:29:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAB2TXSN088514; Thu, 10 Nov 2011 21:29:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAB2TWH0088489; Fri, 11 Nov 2011 02:29:32 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 11 Nov 2011 02:29:32 GMT Message-Id: <201111110229.pAB2TWH0088489@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: Fri, 11 Nov 2011 02:29:34 -0000 TB --- 2011-11-11 00:20:58 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-11 00:20:58 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-11 00:20:58 - cleaning the object tree TB --- 2011-11-11 00:21:10 - cvsupping the source tree TB --- 2011-11-11 00:21:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-11 00:21:24 - building world TB --- 2011-11-11 00:21:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 00:21:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 00:21:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 00:21:24 - SRCCONF=/dev/null TB --- 2011-11-11 00:21:24 - TARGET=powerpc TB --- 2011-11-11 00:21:24 - TARGET_ARCH=powerpc TB --- 2011-11-11 00:21:24 - TZ=UTC TB --- 2011-11-11 00:21:24 - __MAKE_CONF=/dev/null TB --- 2011-11-11 00:21:24 - cd /src TB --- 2011-11-11 00:21:24 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 11 00:21:35 UTC 2011 >>> 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 Fri Nov 11 02:23:18 UTC 2011 TB --- 2011-11-11 02:23:18 - generating LINT kernel config TB --- 2011-11-11 02:23:18 - cd /src/sys/powerpc/conf TB --- 2011-11-11 02:23:18 - /usr/bin/make -B LINT TB --- 2011-11-11 02:23:18 - cd /src/sys/powerpc/conf TB --- 2011-11-11 02:23:18 - /usr/sbin/config -m GENERIC TB --- 2011-11-11 02:23:18 - building GENERIC kernel TB --- 2011-11-11 02:23:18 - CROSS_BUILD_TESTING=YES TB --- 2011-11-11 02:23:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-11 02:23:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-11 02:23:18 - SRCCONF=/dev/null TB --- 2011-11-11 02:23:18 - TARGET=powerpc TB --- 2011-11-11 02:23:18 - TARGET_ARCH=powerpc TB --- 2011-11-11 02:23:18 - TZ=UTC TB --- 2011-11-11 02:23:18 - __MAKE_CONF=/dev/null TB --- 2011-11-11 02:23:18 - cd /src TB --- 2011-11-11 02:23:18 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 11 02:23:18 UTC 2011 >>> 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/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /src/sys/modules/ath/../../dev/ath/if_ath.c:3775: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3777: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3779: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3781: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3783: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3785: error: 'struct ath_rx_status' has no member named 'rs_flags' /src/sys/modules/ath/../../dev/ath/if_ath.c:3975: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-11 02:29:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-11 02:29:32 - ERROR: failed to build GENERIC kernel TB --- 2011-11-11 02:29:32 - 6215.05 user 1068.10 system 7714.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 04:39:17 2011 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 67797106566B for ; Fri, 11 Nov 2011 04:39:17 +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 2ABE38FC08 for ; Fri, 11 Nov 2011 04:39:16 +0000 (UTC) Received: (qmail 17020 invoked by uid 0); 10 Nov 2011 23:12:35 -0500 Received: from unknown (HELO schism.local) (gjb@76.124.49.145) by 0 with SMTP; 10 Nov 2011 23:12:35 -0500 Message-ID: <4EBCA0AB.60200@FreeBSD.org> Date: Thu, 10 Nov 2011 23:12:27 -0500 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <201111100705.pAA75eIT023291@freebsd-current.sentex.ca> <4EBB7A0A.20700@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig05F968A9F5F2973DC90C990A" Cc: Doug Barton , current@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 11 Nov 2011 04:39:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05F968A9F5F2973DC90C990A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 11/10/11 12:15 PM, Adrian Chadd wrote: > Hi, >=20 > The problem right now is that when the code is compiled as a module, > it sucks in -all- of the chipset support rather than only a subset. > So there are two problems: >=20 Is it too disruptive for the offending commit to be reverted, so the tinderbox emails can be silenced? --=20 Glen Barber | gjb@FreeBSD.org FreeBSD Documentation Project --------------enig05F968A9F5F2973DC90C990A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBCAAGBQJOvKCxAAoJEFJPDDeguUaj5asH/Rbei3x82xKfHbHSgpHyioFt RQfMTQPWW50W5Cqnt1l6xmzZpzD/LB31MKdFB04Eb/p7bt8oX37Al3T3jUdRyfz9 cw3VTSt21h6Cdd6+vYiZPsSCyee7GgjD/jkFO+rENaOoSQVxHjn7QfEWt13T+MZI 7mO5/I02ahAQI1bWhkyQF1/Klsjx7eeiCJHbzyRYxF72q4n8497CBGfgTK5wSsZE tvu1tUbkBqonIsmk65zrFUugWX+CHgHI78jw8TRTVHsoieVIOqlBBav6Ur773qQf UO1DWpxhXQYETUMe4tsR/ahxY9/g4Rbx/btEe3o+bwjmzBQ95+b1PIxq0J6MVKI= =jnV/ -----END PGP SIGNATURE----- --------------enig05F968A9F5F2973DC90C990A-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 05:53:47 2011 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 20754106566B for ; Fri, 11 Nov 2011 05:53:47 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA43B8FC0A for ; Fri, 11 Nov 2011 05:53:46 +0000 (UTC) Received: by faar19 with SMTP id r19so5174596faa.13 for ; Thu, 10 Nov 2011 21:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=z7i+j+j5/Uaw7onbKaV6b+lmMECagz7CPpIvB/ICiYE=; b=TDJayu5+uBW4GwCL7YhhTXpGD8s2tPMkcrGT8iJvUTIvxwssP0lc+ke7SyXDxxEUGG RdYwH/e9jm1hCoTcSCvwpsfiZoTjf9EGYLoQRTVCgSJK/dd4Um9F4+ccyURro85ph7TQ 2Dwib82zMElzi6XOf87y+K/BLIgEhEpxb0W5Q= MIME-Version: 1.0 Received: by 10.223.17.23 with SMTP id q23mr16956401faa.11.1320990825447; Thu, 10 Nov 2011 21:53:45 -0800 (PST) Received: by 10.223.116.145 with HTTP; Thu, 10 Nov 2011 21:53:45 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Nov 2011 13:53:45 +0800 Message-ID: From: Paul Ambrose To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: [PATCH] Fix types of arguments to dtrace syscall return probes 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, 11 Nov 2011 05:53:47 -0000 If there is anything I can do for kern/160307 or other Dtrace issue , please let me know 2011/11/8 Ryan Stone : > On Mon, Nov 7, 2011 at 9:16 AM, Paul Ambrose wrote= : >> diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c >> index bdff96e..2737860 100644 >> --- a/sys/kern/kern_ctf.c >> +++ b/sys/kern/kern_ctf.c >> @@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc) >> =A0 =A0 =A0 =A0 * ctfcnt to -1. See below. >> =A0 =A0 =A0 =A0 */ >> =A0 =A0 =A0 =A0if (ef->ctfcnt < 0) >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EFTYPE); >> >> =A0 =A0 =A0 =A0/* Now check if we've already loaded the CTF data.. */ >> =A0 =A0 =A0 =A0if (ef->ctfcnt > 0) { >> ------------------------------------------------------------------------= --------------- > > I have committed this as r227342. =A0Thanks for the fix. > >> And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you >> check it for me? > > Yes, I can take a look. > >> =A0kern/160307, I check the /boot/kernel/kernel with ctfdump, and found >> the kernel image has right ctf information, do you >> have any idea? > > Offhand, no. =A0I'll try to find some time to look at your PRs. > From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 07:16:14 2011 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 F3800106566C; Fri, 11 Nov 2011 07:16:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 482088FC0C; Fri, 11 Nov 2011 07:16:12 +0000 (UTC) Received: by vws11 with SMTP id 11so4639110vws.13 for ; Thu, 10 Nov 2011 23:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eVDDQ+Om2CgyLhnf+exccO+ZVb5bX6si602hSqCmyMQ=; b=xhe4HhHsW0U7SrB4MrlDPGIiAM0/rdC87n5utST+7m1XHz5WvNphUpYz+zVUUQ0yUq uXXZEWlgKT28Vwq0HoHEjZjTPixMzXXc0C1jJicI7fkQ8ZWHtsyFk0FrpXjL6D5zmYXJ nzborALjAsa1Ca3ySN4ZEbi80ZeNs1DJyMbLs= MIME-Version: 1.0 Received: by 10.52.27.72 with SMTP id r8mr18619992vdg.71.1320995772441; Thu, 10 Nov 2011 23:16:12 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 23:16:12 -0800 (PST) In-Reply-To: <4EBCA0AB.60200@FreeBSD.org> References: <201111100705.pAA75eIT023291@freebsd-current.sentex.ca> <4EBB7A0A.20700@FreeBSD.org> <4EBCA0AB.60200@FreeBSD.org> Date: Thu, 10 Nov 2011 23:16:12 -0800 X-Google-Sender-Auth: uzyikeAz4V87oVSSz8XjBKMpYHM Message-ID: From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , current@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 11 Nov 2011 07:16:14 -0000 I already have reverted the relevant commit. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 10:52:01 2011 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 A5B6A1065673; Fri, 11 Nov 2011 10:52:01 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC098FC08; Fri, 11 Nov 2011 10:52:01 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id D94EF555; Fri, 11 Nov 2011 11:51:58 +0100 (CET) Date: Fri, 11 Nov 2011 11:51:08 +0100 From: Pawel Jakub Dawidek To: Sebastian Chmielewski Message-ID: <20111111105107.GB1659@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: invalid zap_type=134218628 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, 11 Nov 2011 10:52:01 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 08, 2011 at 08:02:13PM +0100, Sebastian Chmielewski wrote: > I've got following error after upgrading my 9.0-RC1 to RC2 using source a= nd > got this error at loader prompt: >=20 > ZFS: invalid zap_type=3D134218628 >=20 > when I tried zfsboottest from 9.0-STABLE it failed > ./zfsboottest /boot/kernel/kernel /dev/ada0p4 > returns pool status correctly but ends with the same message >=20 > zfsboottest from 10.0-CURRENT returns pool status, zfsboottest.sh zroot > printed OK message at the end > (very useful zfsboottest.sh wasn't yet merged from current to stable). > I've installed gptzfsboot, zfsloader, loader from -CURRENT and it boots > fine. >=20 > I'm running ZFS on GPT partitions, zfs version 28 with dedup on. > File system can be successfully mount using FreeBSD memstick. >=20 > I think that patches for boot should be merged to 9.0-RELEASE otherwise > users may have the same problems I had. Yes, I plan to include those fixes in 9.0-RELEASE. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk68/hsACgkQForvXbEpPzRerACgzYix0ViD+VoWafOPlMLb3FKE Bi4An35Q88RKGkStQDmH+ddtqsrgo7tu =Bd9Y -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 12:11:20 2011 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 1C4581065677 for ; Fri, 11 Nov 2011 12:11:20 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by mx1.freebsd.org (Postfix) with SMTP id F04E68FC08 for ; Fri, 11 Nov 2011 12:11:19 +0000 (UTC) Received: from [98.139.91.69] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 11 Nov 2011 12:11:19 -0000 Received: from [208.71.42.212] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 11 Nov 2011 12:11:19 -0000 Received: from [127.0.0.1] by smtp223.mail.gq1.yahoo.com with NNFMP; 11 Nov 2011 12:11:19 -0000 X-Yahoo-Newman-Id: 762207.25645.bm@smtp223.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Y1pTE00VM1k3TNnoMoW2XhW0vf2Y2Dt3z.qhsqjov_l10Um hBWy9ZwlE3nc_n20UeO6haMztj8Kpl9fBdac4eoajYwHaUH0oMqDf_nu5L2_ cOJKNx8.yho3E057FpS2d_hm4o832v94zkNuyb7DCmyabYMoPmBGF7Y8HP66 hgtKil6rBYCl9PUpEn3Zasb6vC8GhoxOaDUZ6BG3LkVgN7sSEvmU7_2.HwhU jjDJ3dLwmkOukrATUmtijcDpiudWhW8uPZ6rlJfM5aVUFh7EzBeFOSdDkltB kr3mJURHNKWY0m59_GcUTI_5wm0l1bQ7mQgGGMWnspqTrw.GZUh6M._1lLOh aYCRrGPTJgI92fWksHgfNHpIjP4idwyUSEQ8jPK.hTeTxtKCdsYvk1Ac3zDA HfPZOy8Gun1XWgQ-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.75 with plain) by smtp223.mail.gq1.yahoo.com with SMTP; 11 Nov 2011 04:11:19 -0800 PST Message-ID: <4EBD10E6.9000302@freebsd.org> Date: Fri, 11 Nov 2011 13:11:18 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <4EBB885E.9060908@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT 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, 11 Nov 2011 12:11:20 -0000 Am 10.11.2011 11:32, schrieb Attilio Rao: > 2011/11/10 Stefan Esser: >> I can produce further debug output on demand, but I do not have a serial or >> firewire console setup for debugging. >> >> Is anybody else affected by this boot problem? > > Can you setup a videocamera or a simple serial console? > Did you try to boot with both -s and -v on? > > Attilio I should be able to attach a serial console. Booting with -s should make no difference (since booting fails during a very early initialization stage). I tried -v, but found that I could not reproduce the cold boot problem without the system being at least in S5 for hours (just switching off power and waiting a few minutes did not suffice, but this morning the system again booted only on the first attempt). This behavior obviously limits the rate of tests possible ... It looks as if the memory holding the loaded kernel and/or modules is corrupted before the kernel is reloaded and started, as indicated by this morning's boot failure: kldload: unexpected relocation type 268435457 kldload: unexpected relocation type 67108865 Fatal trap 12: ... The rest of the panic message and back trace is identical to the trap 12 panic details in my previous message. It really looks as if the loaded kernel image is corrupted at random positions, leading to random panics (but often of the type trap 12 or page fault in kernel) when execution reaches damaged code or data. A reboot succeeded without any problem as in all prior cases ... Any ideas? Regards, STefan From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 12:15:59 2011 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 C8634106566B; Fri, 11 Nov 2011 12:15:59 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 351808FC1A; Fri, 11 Nov 2011 12:15:58 +0000 (UTC) Received: by wwg14 with SMTP id 14so3281721wwg.31 for ; Fri, 11 Nov 2011 04:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=H6w7hKtEPjL/rq0bPwZMRwOHGm0ToEU0blBfYwTSPuQ=; b=QFCLAICEAsgEsJOJV01VcAJJXK+gdNJ5m/ZQOhBVWNXYlfsU7pjJjTqSs9esEJ/0at epPJuA+7zCtxB6Oo5HFz9KKRpK6Ow6wWyVYRxX8Eak8L9IQnXH5td6zNOjXYCRJFDAQf cO5L4I+GNzDj5hHH4zBEzS3tvqRGWcIdqqWYM= MIME-Version: 1.0 Received: by 10.216.176.14 with SMTP id a14mr101216wem.14.1321013757174; Fri, 11 Nov 2011 04:15:57 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Fri, 11 Nov 2011 04:15:57 -0800 (PST) In-Reply-To: <4EBD10E6.9000302@freebsd.org> References: <4EBB885E.9060908@freebsd.org> <4EBD10E6.9000302@freebsd.org> Date: Fri, 11 Nov 2011 13:15:57 +0100 X-Google-Sender-Auth: dpL5xuYvt0AsSGAFIklJ_jUT6nU Message-ID: From: Attilio Rao To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current Subject: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT 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, 11 Nov 2011 12:15:59 -0000 Can you try rebuilding your kernel and modules from scratch and see if it fixes your problem? Attilio 2011/11/11 Stefan Esser : > Am 10.11.2011 11:32, schrieb Attilio Rao: >> >> 2011/11/10 Stefan Esser: >>> >>> I can produce further debug output on demand, but I do not have a serial >>> or >>> firewire console setup for debugging. >>> >>> Is anybody else affected by this boot problem? >> >> Can you setup a videocamera or a simple serial console? >> Did you try to boot with both -s and -v on? >> >> Attilio > > I should be able to attach a serial console. > > Booting with -s should make no difference (since booting fails during a very > early initialization stage). > > I tried -v, but found that I could not reproduce the cold boot problem > without the system being at least in S5 for hours (just switching off > power and waiting a few minutes did not suffice, but this morning the > system again booted only on the first attempt). This behavior obviously > limits the rate of tests possible ... > > > It looks as if the memory holding the loaded kernel and/or modules is > corrupted before the kernel is reloaded and started, as indicated by > this morning's boot failure: > > kldload: unexpected relocation type 268435457 > kldload: unexpected relocation type 67108865 > Fatal trap 12: ... > > The rest of the panic message and back trace is identical to the trap 12 > panic details in my previous message. > > > It really looks as if the loaded kernel image is corrupted at random > positions, leading to random panics (but often of the type trap 12 or > page fault in kernel) when execution reaches damaged code or data. > > A reboot succeeded without any problem as in all prior cases ... > > Any ideas? > > Regards, STefan > _______________________________________________ > 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" > -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 12:29:48 2011 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 E9D4B106566C for ; Fri, 11 Nov 2011 12:29:48 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id AAECC8FC13 for ; Fri, 11 Nov 2011 12:29:48 +0000 (UTC) Received: by qabj40 with SMTP id j40so4112707qab.13 for ; Fri, 11 Nov 2011 04:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=S4hXh696wTg16zq2aqx0jxGqi/62fEU7i6Lv3eQZztc=; b=DyY5kbxT2EBhGMGxQM4m5DOurbdWwnV9Io7nksET7VZ9U92zsodEXTWXfY79DXTEzw hK/tK1ncRcNbU76vt652zuazruTuBaoxv9BpL5m6XT9kQC5GCh3EHgrevMEbdsA/VjkW tOZEkzgZU6ksnXF64CZ1nUyfDvzGS6EhKIo/Y= MIME-Version: 1.0 Received: by 10.224.215.73 with SMTP id hd9mr8428525qab.94.1321014586563; Fri, 11 Nov 2011 04:29:46 -0800 (PST) Received: by 10.224.73.195 with HTTP; Fri, 11 Nov 2011 04:29:46 -0800 (PST) Date: Fri, 11 Nov 2011 07:29:46 -0500 Message-ID: From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 12:29:49 -0000 Dear all , Instead of using Current and then renaming everything for a new version number , is it not possible to use the newest version number in place of Current when it is branched . Such a change will prevent unnecessary renaming problems . For everyone , it i very easy to understand that 10.0 is the latest , therefore the current one . The current may be used as a symbolic link to the newest version number , such as used by Debian . For example , for FreeBSD 9.0 RC1 , the ports directory name was ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ which is NOT available now , and pkg_add -r * is giving error about directory not found . This is preventing testing and / or using efforts . I know , it is possible to rename local link names , but everyone is not so much knowledgeable . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 13:05:17 2011 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 8F5EF1065672 for ; Fri, 11 Nov 2011 13:05:17 +0000 (UTC) (envelope-from break19@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 4C8788FC17 for ; Fri, 11 Nov 2011 13:05:17 +0000 (UTC) Received: by ywe9 with SMTP id 9so703953ywe.13 for ; Fri, 11 Nov 2011 05:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=i8/EhXq8gNkBhJKfCRJWkNJOk60xTERNSpt6OSnHeFk=; b=C/Y5rEACYN8Nku41lvhvJqkAxshZh3dnKzPOykqi7IE21pJ0LpcE4fONyte4BI1fyJ XzVL0AeWTFNDNmYEfAgVlEeyYt94Vpqbq051Bq4C0tH8446DKtKcjfU4zzVv2GJDGuWQ Y0SP7QbM7/WD4afjqmKMVyxfvug6ZXns9Q+ZI= Received: by 10.146.190.21 with SMTP id n21mr123906yaf.39.1321016716593; Fri, 11 Nov 2011 05:05:16 -0800 (PST) Received: from funbeast.localnet (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id m29sm16906312yhi.20.2011.11.11.05.05.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 05:05:15 -0800 (PST) From: Chuck Burns To: freebsd-current@freebsd.org Date: Fri, 11 Nov 2011 07:04:48 -0600 Message-ID: <2171368.58yxYs0Lbv@funbeast> User-Agent: KMail/4.7.3 (Linux/3.1.0-gentoo; KDE/4.7.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 13:05:17 -0000 On Friday, November 11, 2011 07:29:46 AM Mehmet Erol Sanliturk wrote: -(snipped stuff)- > This is preventing testing and / or using efforts . > > > I know , it is possible to rename local link names , but > everyone is not so much knowledgeable . > > > > Thank you very much . > > Mehmet Erol Sanliturk Quite honestly, if someone isn't that knowledgeable, then they probably shouldn't be running current. In fact, the handbook even states that. I don't really see an issue here. -current is a bleeding edge development release, that must be built from source, and SHOULD always point to the latest source code. If you are using pkg_add -r to install software, on anything but release versions, you should expect breakage. If you do not wish to build from source, then you should probably stick to release versions. Chuck Burns From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 13:17:53 2011 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 3D96C106564A for ; Fri, 11 Nov 2011 13:17:53 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id EF3528FC18 for ; Fri, 11 Nov 2011 13:17:52 +0000 (UTC) Received: by qabj40 with SMTP id j40so4155056qab.13 for ; Fri, 11 Nov 2011 05:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xSBMBjIopYto/rZ3M+sp1IyZ+SM16z1zruP59By+BpE=; b=okdikF9K7WJfRm1o+EIB4YybOh6VjzB/GEKKXypUgIjhnrPsPrzs+amqT01gyRxXwH ORlIKMN64CXXl2enwEeTZoEktoivoqUPfyjmDhWigJbsdnU3Ih52rdclF+lQmMS4A4pS PXmhFT6TklAy4uWYI/bSdLJXw59E/yST/J+vg= MIME-Version: 1.0 Received: by 10.224.183.15 with SMTP id ce15mr8493226qab.42.1321017472191; Fri, 11 Nov 2011 05:17:52 -0800 (PST) Received: by 10.224.73.195 with HTTP; Fri, 11 Nov 2011 05:17:52 -0800 (PST) In-Reply-To: <2171368.58yxYs0Lbv@funbeast> References: <2171368.58yxYs0Lbv@funbeast> Date: Fri, 11 Nov 2011 08:17:52 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Chuck Burns Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 13:17:53 -0000 On Fri, Nov 11, 2011 at 8:04 AM, Chuck Burns wrote: > On Friday, November 11, 2011 07:29:46 AM Mehmet Erol Sanliturk wrote: > -(snipped stuff)- > > > This is preventing testing and / or using efforts . > > > > > > I know , it is possible to rename local link names , but > > everyone is not so much knowledgeable . > > > > > > > > Thank you very much . > > > > Mehmet Erol Sanliturk > > Quite honestly, if someone isn't that knowledgeable, then they probably > shouldn't be running current. In fact, the handbook even states that. I > don't > really see an issue here. -current is a bleeding edge development release, > that must be built from source, and SHOULD always point to the latest > source > code. > My sentence is NOT about "Current" , but 9.0 RC1 . Perhaps , you will NOT say , if a person is NOT knowledgeable , he should NOT use 9.0 RC1 . > > If you are using pkg_add -r to install software, on anything but > release versions, you should expect breakage. > > If you do not wish to build from source, then you should probably stick to > release versions. > > Chuck Burns > Up to now , my most disappointed situation is that , there is NO any tendency to lower required expertise level to use FreeBSD . Such an approach is confining FreeBSD to a small number of elite users when compared to millions of Linux users let alone hundred millions of some other operating systems which they are approaching to billions when version users are summed in spite of paying money also . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 13:30:57 2011 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 90E21106568B for ; Fri, 11 Nov 2011 13:30:57 +0000 (UTC) (envelope-from break19@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 4C0438FC08 for ; Fri, 11 Nov 2011 13:30:57 +0000 (UTC) Received: by yenl2 with SMTP id l2so3047656yen.13 for ; Fri, 11 Nov 2011 05:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=lJSMgANkzFPnnCWA7zHRclMUztiYqmkIYN4QROykKuk=; b=itGGEoSftGoZJFdWWWZbYQslRsVAWOeCk6LHUMnP2VQ/rKmSYhXVmwry9G9J5IXoPb 2U1wDWs5m30lFNW9lRLWp1yu5Wge/NEUuiBGAfkqVnjb09O8W977gzQBlfZ1DyD5q1CL 1rygojTAyj/GxXBf1iohzq/4EmOxzL1WK/Qpc= Received: by 10.101.194.39 with SMTP id w39mr2440981anp.115.1321018256612; Fri, 11 Nov 2011 05:30:56 -0800 (PST) Received: from funbeast.localnet (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id i67sm17008473yhm.16.2011.11.11.05.30.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 05:30:56 -0800 (PST) From: Chuck Burns To: freebsd-current@freebsd.org Date: Fri, 11 Nov 2011 07:30:29 -0600 Message-ID: <2185571.xNZoOVfxaV@funbeast> User-Agent: KMail/4.7.3 (Linux/3.1.0-gentoo; KDE/4.7.3; x86_64; ; ) In-Reply-To: References: <2171368.58yxYs0Lbv@funbeast> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 13:30:57 -0000 On Friday, November 11, 2011 08:17:52 AM you wrote: -snip- > My sentence is NOT about "Current" , but 9.0 RC1 . > Perhaps , you will NOT say , if a person is NOT knowledgeable , he should > NOT use 9.0 RC1 . > If you use a proper RC, then pkg_add will work until a new RC, and since there is no binary upgrade path for anything other than releases, you will need to reinstall, with the newly released RC. -snip- > Up to now , my most disappointed situation is that , there is NO any > tendency to > lower required expertise level to use FreeBSD . > Such an approach is confining FreeBSD to a small number of elite users > when compared to millions of Linux users let alone hundred millions of > some other operating systems which they are approaching to billions when > version users are summed in spite of paying money also . GhostBSD, PCBSD are two options for "lower expertise" and, as such, are billed as desktop versions of FreeBSD. FreeBSD itself (as well as the other BSDs) is a minimalistic OS, where you can build your own system, making it either into a server, workstation, or even into a desktop system if you so desire. If you want something with point-n-click ease of use, go use one of the two desktop-oriented versions. Both GhostBSD, and PCBSD are just a desktop environment built on top of FreeBSD. PCBSD even has a 9.0 RC out now as well, if you're into testing. PCBSD uses the kde environment, and GhostBSD uses the gnome 2.32 environment. If you want something else, feel free to create your own. There is nothing in the BSD license that prevents you from doing that. Instead of complaining that SOMEONE ELSE should do something that YOU want done, why not just do it yourself. In other words, put up, or shut up. :) Chuck Burns From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 14:39:32 2011 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 BF0DA106564A for ; Fri, 11 Nov 2011 14:39:32 +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 7E9438FC0A for ; Fri, 11 Nov 2011 14:39:32 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 6FBBA28428; Fri, 11 Nov 2011 15:39:31 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7E8C328427; Fri, 11 Nov 2011 15:39:30 +0100 (CET) Message-ID: <4EBD33A1.2070705@quip.cz> Date: Fri, 11 Nov 2011 15:39:29 +0100 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: Chuck Burns References: <2171368.58yxYs0Lbv@funbeast> <2185571.xNZoOVfxaV@funbeast> In-Reply-To: <2185571.xNZoOVfxaV@funbeast> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 14:39:32 -0000 Chuck Burns wrote: > On Friday, November 11, 2011 08:17:52 AM you wrote: > -snip- >> My sentence is NOT about "Current" , but 9.0 RC1 . >> Perhaps , you will NOT say , if a person is NOT knowledgeable , he should >> NOT use 9.0 RC1 . >> > > If you use a proper RC, then pkg_add will work until a new RC, and since there > is no binary upgrade path for anything other than releases, you will need to > reinstall, with the newly released RC. You can use freebsd-update for RC upgrades too! > -snip- >> Up to now , my most disappointed situation is that , there is NO any >> tendency to >> lower required expertise level to use FreeBSD . >> Such an approach is confining FreeBSD to a small number of elite users >> when compared to millions of Linux users let alone hundred millions of >> some other operating systems which they are approaching to billions when >> version users are summed in spite of paying money also . > > GhostBSD, PCBSD are two options for "lower expertise" and, as such, are billed > as desktop versions of FreeBSD. > > FreeBSD itself (as well as the other BSDs) is a minimalistic OS, where you can > build your own system, making it either into a server, workstation, or even > into a desktop system if you so desire. > > If you want something with point-n-click ease of use, go use one of the two > desktop-oriented versions. > > Both GhostBSD, and PCBSD are just a desktop environment built on top of > FreeBSD. PCBSD even has a 9.0 RC out now as well, if you're into testing. > > PCBSD uses the kde environment, and GhostBSD uses the gnome 2.32 environment. > If you want something else, feel free to create your own. There is nothing in > the BSD license that prevents you from doing that. > > Instead of complaining that SOMEONE ELSE should do something that YOU want > done, why not just do it yourself. > > In other words, put up, or shut up. :) Really, this is not a proper worded answer to someone who just tried to request some more friendliness to new users and increase our user base. It doesn't metter if there are some other "freebsd based" projects. FreeBSD it-self has a problem - fewer users = fewer manufacturers will support FreeBSD (drivers). Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 15:14:37 2011 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 CBE741065676 for ; Fri, 11 Nov 2011 15:14:37 +0000 (UTC) (envelope-from yerenkow@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 8CEDE8FC0A for ; Fri, 11 Nov 2011 15:14:37 +0000 (UTC) Received: by ywe9 with SMTP id 9so879379ywe.13 for ; Fri, 11 Nov 2011 07:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=zhgZVzfoEzSd5AQZNTNnVd1H+8zXUFR4UCStoJRiXvg=; b=GJnzDIfnVct+Bo2l2LNGicZj34awlED98vIpcMtsJ49BSz4eWt0aSxnmED+ss/dTs3 HF9wZRX2eoKRkYImEwYnDZOx5957fJbgjHAL44f2fI7L6lrGPtscITurTRjgYynHej1f Mk3gloRzvRGS8n6wH3kqWBLZ6Dl6+xWF5QXcY= MIME-Version: 1.0 Received: by 10.101.137.20 with SMTP id p20mr2046031ann.55.1321024476586; Fri, 11 Nov 2011 07:14:36 -0800 (PST) Received: by 10.151.44.17 with HTTP; Fri, 11 Nov 2011 07:14:36 -0800 (PST) Date: Fri, 11 Nov 2011 17:14:36 +0200 Message-ID: From: Alexander Yerenkow To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: KMS testing, intel only 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, 11 Nov 2011 15:14:37 -0000 Hello all. Before I begin, I appreciate any help/comments/criticism. Please, don't hesitate to support this topic. Some time ago I've announced new project - of creating rolling images of FreeBSD from SVN. Along with plain standard ones (plain world+kernel install of bare system) I'm working on creating specific images. Like with preset installed packages (kde-set, gnome-set, etc.), like with some patches (area51/kde-wip/kms) etc. So, I did not fully automated (yet) creating of this one image, but you already can grab it to test: http://gits.kiev.ua/FreeBSD/FreeBSD-9-kms-i386-r227337-2011-11-10.img.xz I'm sure you find filename fully descriptive :) What can be done with this image (after unpacking): dd if=this.img of=your-usb bs=64M and simply boot from your usb. After you boot, login with root. First, you can try just launch ./runx.sh It will use /root/xorg.conf, create few log files (probably useful ones) in /root and launch two xterms and openbox for WM. How you can test graphics: 1. glxgears/glxinfo - it's not a benchmar, as you may know :) 2. blender - extensive graphics usage 3. stellarium - also extensive graphics usage 4. seamonkey (which starts for about 2-3 minutes in absence of internet) - can be used to immediately send feedback and/or log files. Please, note that switching to tty not working; after you finish with playing KMS you simply shutdown system. If you had some troubles, you always can reboot and edit /root/xorg.conf before launch X. Before each X start copy of xorg are creating, so you can make some tests and find difference between files, not worrying for backuping/storing configs. Misc notes: there is a script exist: /root/addpackage.sh to make life easier if you want to test some other software (remotely installs packages, e.g. ./ addpackage.sh firefox will get you firefox. maybe.) Also, on image about 1G free space, so you can install something even big, to try it. Also, on image pretty fresh ports tree present, with applied xorg-dev patch, you can play with ports too. Full package list: OpenEXR-1.6.1_3 aalib-1.4.r5_6 atk-2.0.1 autoconf-2.68 autoconf-wrapper-20101119 automake-1.11.1 automake-wrapper-20101119 bigreqsproto-1.1.1 bison-2.4.3,1 bitstream-vera-1.10_5 blender-2.60 ca_root_nss-3.12.11_1 cairo-1.10.2_2,1 compositeproto-0.4.2 consolekit-0.4.3 cups-client-1.5.0 damageproto-1.2.1 dbus-1.4.14_1 dbus-glib-0.94 desktop-file-utils-0.18 dmidecode-2.11 dri-7.11,2 dri2proto-2.6 eggdbus-0.6_1 encodings-1.0.4,1 evieext-1.1.1 expat-2.0.1_2 ffmpeg-0.7.6,1 fftw3-3.3_1 fixesproto-5.0 flac-1.2.1_2 flex-2.5.35_4 font-bh-ttf-1.0.3 font-misc-ethiopic-1.0.3 font-misc-meltho-1.0.3 font-util-1.2.0 fontconfig-2.8.0_1,1 fontsproto-2.1.1 freealut-1.1.0_2 freetype2-2.4.7 gamin-0.1.10_4 gdk-pixbuf-2.23.5_1 gettext-0.18.1.1 gio-fam-backend-2.28.8 glew-1.7.0 glib-2.28.8_2 glproto-1.4.14 gmake-3.82 gnome_subr-1.0 gobject-introspection-0.10.8 gpac-libgpac-0.4.5_4,1 gtk-2.24.6 gtk-update-icon-cache-2.24.6 hal-0.5.14_17 hicolor-icon-theme-0.12 ilmbase-1.0.1_1 inputproto-2.0.2 intltool-0.41.1 jasper-1.900.1_9 jbigkit-1.6 jpeg-8_3 kbproto-1.0.5 libGL-7.11 libGLU-7.4.4 libICE-1.0.7,1 libIDL-0.8.14_1 libSM-1.2.0,1 libX11-1.4.4,1 libXau-1.0.6 libXaw-1.0.9,1 libXcomposite-0.4.3,1 libXcursor-1.1.12 libXdamage-1.1.3 libXdmcp-1.1.0 libXext-1.3.0_1,1 libXfixes-5.0 libXfont-1.4.4,1 libXft-2.1.14 libXi-1.4.3,1 libXinerama-1.1.1,1 libXmu-1.1.0,1 libXp-1.0.1,1 libXpm-3.5.9 libXrandr-1.3.2 libXrender-0.9.6 libXt-1.1.1 libXv-1.0.6,1 libXvMC-1.0.6 libXxf86misc-1.0.3 libXxf86vm-1.1.1 libdrm-2.4.27 libevent-1.4.14b_2 libexecinfo-1.1_3 libffi-3.0.9 libfontenc-1.1.0 libgcrypt-1.5.0 libglut-7.4.4 libgpg-error-1.10 libiconv-1.13.1_1 libnotify-0.7.3_1 libogg-1.2.2,4 libpciaccess-0.12.1 libpthread-stubs-0.3_3 libsamplerate-0.1.8_2 libsndfile-1.0.25 libtheora-1.1.1_2 libtool-2.4_1 libvolume_id-0.81.1 libvorbis-1.3.2,3 libvpx-0.9.7 libxcb-1.7 libxkbfile-1.0.7 libxkbui-1.0.2_1 libxml2-2.7.8_1 libxslt-1.1.26_3 luit-1.1.0 m4-1.4.16,1 makedepend-1.0.3,1 mesa-demos-7.4.4 mkfontdir-1.0.6 mkfontscale-1.0.9 nspr-4.8.9 openal-soft-1.13 openbox-3.5.0 opencv-core-2.3.1_1 openjpeg-1.3_2 orc-0.4.14_1 p5-XML-Parser-2.41 pango-1.28.4 pciids-20111002 pcre-8.20 perl-5.12.4_2 pixman-0.24.0 pkg-config-0.25_1 png-1.4.8 policykit-0.9_6 polkit-0.99 portmaster-3.10 printproto-1.0.5 py27-libxml2-2.7.8_1 python27-2.7.2_3 python32-3.2.2_1 qt4-corelib-4.7.4 qt4-gui-4.7.4 qt4-network-4.7.4 qt4-opengl-4.7.4 qt4-script-4.7.4 randrproto-1.3.2 recordproto-1.14.1 renderproto-0.11.1 resourceproto-1.2.0 schroedinger-1.0.10 scrnsaverproto-1.2.1 sdl-1.2.14_2,2 seamonkey-2.4.1 shared-mime-info-0.90 stellarium-0.11.0 tiff-4.0.0_2 trapproto-3.4.3 videoproto-2.3.1 x264-0.116.2076 xcb-util-0.3.6_1 xcmiscproto-1.2.1 xdg-utils-1.0.2_5 xextproto-7.2.0 xeyes-1.1.1 xf86-input-keyboard-1.6.0 xf86-input-mouse-1.7.1 xf86-video-intel-2.16.0 xf86bigfontproto-1.2.0 xf86dgaproto-2.1 xf86driproto-2.1.1 xf86miscproto-0.9.3 xf86vidmodeproto-2.3.1 xineramaproto-1.2.1 xkbcomp-1.2.3 xkeyboard-config-2.4.1 xorg-fonts-truetype-7.5.1 xorg-macros-1.15.0 xorg-server-1.10.4_1,1 xproto-7.0.22 xterm-276 xtrans-1.2.6 xvid-1.3.2,1 zip-3.0 -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 15:25:53 2011 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 51992106566C for ; Fri, 11 Nov 2011 15:25:53 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB678FC0C for ; Fri, 11 Nov 2011 15:25:52 +0000 (UTC) Received: by iakl21 with SMTP id l21so3950553iak.13 for ; Fri, 11 Nov 2011 07:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=D24NuCEaI2a9Z8ul5063BG2aLtqG2bUpkmnGCwTV8Ps=; b=VBmqVEdEn8TIO3+6T60ookGXZFxiP7bvHWN81/ubYVAvX3yq0egYADNMlBrBqTxrM3 H6VGpk8qg7mXVrIyVp+SAIaAStODIEcVX2QdXvxs6Rhz82xgR6xP5BQA9ItA+1dZ3AyN d5Gkd+G65xudpr1PqBPPRSce1WczPfcDBIMBc= MIME-Version: 1.0 Received: by 10.231.65.209 with SMTP id k17mr2974068ibi.4.1321025152280; Fri, 11 Nov 2011 07:25:52 -0800 (PST) Received: by 10.231.34.140 with HTTP; Fri, 11 Nov 2011 07:25:51 -0800 (PST) In-Reply-To: <4EBD33A1.2070705@quip.cz> References: <2171368.58yxYs0Lbv@funbeast> <2185571.xNZoOVfxaV@funbeast> <4EBD33A1.2070705@quip.cz> Date: Fri, 11 Nov 2011 17:25:51 +0200 Message-ID: From: George Kontostanos To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Chuck Burns Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 15:25:53 -0000 On Fri, Nov 11, 2011 at 4:39 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > Chuck Burns wrote: >> >> On Friday, November 11, 2011 08:17:52 AM you wrote: >> -snip- >>> >>> My sentence is NOT about "Current" , but 9.0 RC1 . >>> Perhaps , you will NOT say , if a person is NOT knowledgeable , he shou= ld >>> NOT use 9.0 RC1 . >>> >> >> If you use a proper RC, then pkg_add will work until a new RC, and since >> there >> is no binary upgrade path for anything other than releases, you will nee= d >> to >> reinstall, with the newly released RC. > > You can use freebsd-update for RC upgrades too! > >> -snip- >>> >>> Up to now , my most disappointed situation is that , there is NO any >>> tendency to >>> lower required expertise level to use FreeBSD . >>> Such an approach is confining FreeBSD to a small number of elite users >>> =A0when compared to millions of Linux users let alone hundred millions = of >>> some other operating systems which they are approaching to billions whe= n >>> version users are summed in spite of paying money also . >> >> GhostBSD, PCBSD are two options for "lower expertise" and, as such, are >> billed >> as desktop versions of FreeBSD. >> >> FreeBSD itself (as well as the other BSDs) is a minimalistic OS, where y= ou >> can >> build your own system, making it either into a server, workstation, or >> even >> into a desktop system if you so desire. >> >> If you want something with point-n-click ease of use, go use one of the >> two >> desktop-oriented versions. >> >> Both GhostBSD, and PCBSD are just a desktop environment built on top of >> FreeBSD. =A0PCBSD even has a 9.0 RC out now as well, if you're into test= ing. >> >> PCBSD uses the kde environment, and GhostBSD uses the gnome 2.32 >> environment. >> If you want something else, feel free to create your own. There is nothi= ng >> in >> the BSD license that prevents you from doing that. >> >> Instead of complaining that SOMEONE ELSE should do something that YOU wa= nt >> done, why not just do it yourself. >> >> In other words, put up, or shut up. :) > > Really, this is not a proper worded answer to someone who just tried to > request some more friendliness to new users and increase our user base. > > It doesn't metter if there are some other "freebsd based" projects. FreeB= SD > it-self has a problem - fewer users =3D fewer manufacturers will support > FreeBSD (drivers). > > Miroslav Lachman > _______________________________________________ > 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= " > I agree 100%. The more people follow current the better releases we will have in the future. Sure current in not for the beginner, you will need to be able to compile world and kernel and produce debug symbols. That is expected. But maybe we should keep an open mind into ideas and not condemn them immediately. --=20 George Kontostanos aisecure.net From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 16:03:02 2011 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 316BC1065672 for ; Fri, 11 Nov 2011 16:03:02 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id B535D8FC18 for ; Fri, 11 Nov 2011 16:03:01 +0000 (UTC) Received: by eyd10 with SMTP id 10so4430640eyd.13 for ; Fri, 11 Nov 2011 08:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VUBaXyQ4+pL69orJk17piesg2dNaNCQhCvJmIToaRvI=; b=rTPou3OeLyo/eAywDKTmjVhK2jtoTFoL0ZdNpdk8Cj7LHsCoLvHrRFmWyihuhhzRVF 3X6szdzKystz2HeTJtQpFQExOsB0SwDhazu3lrVIaLCPmvDWltObJoQjfKiPzd4yKOHq C6uRvRjEQt1gTrpq0HDFcYvLPvrc8E650t2Qk= Received: by 10.14.15.7 with SMTP id e7mr1015164eee.37.1321027380528; Fri, 11 Nov 2011 08:03:00 -0800 (PST) Received: from [192.168.50.106] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id f36sm32812188eef.4.2011.11.11.08.02.59 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 08:02:59 -0800 (PST) Message-ID: <4EBD472F.4030204@gmail.com> Date: Fri, 11 Nov 2011 17:02:55 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <2171368.58yxYs0Lbv@funbeast> <2185571.xNZoOVfxaV@funbeast> <4EBD33A1.2070705@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 16:03:02 -0000 George Kontostanos schreef: > On Fri, Nov 11, 2011 at 4:39 PM, Miroslav Lachman<000.fbsd@quip.cz> wrote: >> Chuck Burns wrote: >>> On Friday, November 11, 2011 08:17:52 AM you wrote: >>> -snip- >>>> My sentence is NOT about "Current" , but 9.0 RC1 . >>>> Perhaps , you will NOT say , if a person is NOT knowledgeable , he should >>>> NOT use 9.0 RC1 . >>>> >>> If you use a proper RC, then pkg_add will work until a new RC, and since >>> there >>> is no binary upgrade path for anything other than releases, you will need >>> to >>> reinstall, with the newly released RC. >> You can use freebsd-update for RC upgrades too! >> >>> -snip- >>>> Up to now , my most disappointed situation is that , there is NO any >>>> tendency to >>>> lower required expertise level to use FreeBSD . >>>> Such an approach is confining FreeBSD to a small number of elite users >>>> when compared to millions of Linux users let alone hundred millions of >>>> some other operating systems which they are approaching to billions when >>>> version users are summed in spite of paying money also . >>> GhostBSD, PCBSD are two options for "lower expertise" and, as such, are >>> billed >>> as desktop versions of FreeBSD. >>> >>> FreeBSD itself (as well as the other BSDs) is a minimalistic OS, where you >>> can >>> build your own system, making it either into a server, workstation, or >>> even >>> into a desktop system if you so desire. >>> >>> If you want something with point-n-click ease of use, go use one of the >>> two >>> desktop-oriented versions. >>> >>> Both GhostBSD, and PCBSD are just a desktop environment built on top of >>> FreeBSD. PCBSD even has a 9.0 RC out now as well, if you're into testing. >>> >>> PCBSD uses the kde environment, and GhostBSD uses the gnome 2.32 >>> environment. >>> If you want something else, feel free to create your own. There is nothing >>> in >>> the BSD license that prevents you from doing that. >>> >>> Instead of complaining that SOMEONE ELSE should do something that YOU want >>> done, why not just do it yourself. >>> >>> In other words, put up, or shut up. :) >> Really, this is not a proper worded answer to someone who just tried to >> request some more friendliness to new users and increase our user base. >> >> It doesn't metter if there are some other "freebsd based" projects. FreeBSD >> it-self has a problem - fewer users = fewer manufacturers will support >> FreeBSD (drivers). >> >> Miroslav Lachman >> _______________________________________________ >> 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" >> > I agree 100%. The more people follow current the better releases we > will have in the future. Sure current in not for the beginner, you > will need to be able to compile world and kernel and produce debug > symbols. That is expected. > > But maybe we should keep an open mind into ideas and not condemn them > immediately. > If FreeBSD starts using numbers for HEAD/CURRENT, i think a lot of users would find them selves in a situation that they download version 10 in this case and that they are using a develepment version instead of a real release version. So FreeBSD will get more frustrated users, who need to download the latest release again and so on. Keeping the name more seperated from the normal numbering prevents this more or less. Gr Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 14:31:43 2011 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 405E3106566B; Fri, 11 Nov 2011 14:31:43 +0000 (UTC) (envelope-from kickbsd@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [IPv6:2a02:6b8:0:801::5]) by mx1.freebsd.org (Postfix) with ESMTP id B33968FC12; Fri, 11 Nov 2011 14:31:42 +0000 (UTC) Received: from web148.yandex.ru (web148.yandex.ru [95.108.131.163]) by forward15.mail.yandex.net (Yandex) with ESMTP id 2C4609E4174; Fri, 11 Nov 2011 18:31:41 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321021901; bh=LLNR6BAZ63aLsUrcMg7HEz3H/oQcY12fIB3+20QD6KU=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=aPjdx5hsq7dpC2XrhIg3X6tLjy8zg4MXmm5N9qADhR9RjwrAsSO5F6a8Q5JPRUwoW X2vTzyrQo3OvImZDjignLYEtQhxjYM63A5BQ8Vp6BbmGuGzZ0sJ6ZNLeH6vuD2JHGR Mgp4aU+6Rr3c5q5q36RHSz21n5R6te3eiQ7PctXs= Received: from localhost (localhost.localdomain [127.0.0.1]) by web148.yandex.ru (Yandex) with ESMTP id F300329D8073; Fri, 11 Nov 2011 18:31:40 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321021901; bh=LLNR6BAZ63aLsUrcMg7HEz3H/oQcY12fIB3+20QD6KU=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=aPjdx5hsq7dpC2XrhIg3X6tLjy8zg4MXmm5N9qADhR9RjwrAsSO5F6a8Q5JPRUwoW X2vTzyrQo3OvImZDjignLYEtQhxjYM63A5BQ8Vp6BbmGuGzZ0sJ6ZNLeH6vuD2JHGR Mgp4aU+6Rr3c5q5q36RHSz21n5R6te3eiQ7PctXs= X-Yandex-Spam: 1 Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by web148.yandex.ru with HTTP; Fri, 11 Nov 2011 18:31:40 +0400 From: Darren Baginski To: freebsd-fs@freebsd.org,freebsd-current@freebsd.org MIME-Version: 1.0 Message-Id: <598941321021900@web148.yandex.ru> Date: Fri, 11 Nov 2011 18:31:40 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Fri, 11 Nov 2011 16:18:49 +0000 Cc: Subject: Unable to boot from zfsroot 9.0-RC2 (while 9.0-RC1 boots fine) 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, 11 Nov 2011 14:31:43 -0000 Hi! I'm having troubles booting today's 9.0-RC2 from zfsroot, I'm getting 'unknown filesystem' error. But 9.0-RC1 from Tue Nov 8 2011 boots fine. Here is output with 9.0-RC1 kernel: # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zroot 5.97G 2.85G 3.11G 47% 1.00x ONLINE - # zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 2.85G 3.02G 2.85G legacy # cat /boot/loader.conf zfs_load="YES" vfs.root.mountfrom="zfs:zroot" Originally that box with installed with FreeBSD 8.x, but continuously updated up to today's version, so : VER FILESYSTEM --- ------------ 4 zroot VER POOL --- ------------ 15 zroot Any suggestions ? What could be the problem? From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 16:27:28 2011 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 34EC11065673 for ; Fri, 11 Nov 2011 16:27:28 +0000 (UTC) (envelope-from yerenkow@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 E3D8A8FC08 for ; Fri, 11 Nov 2011 16:27:27 +0000 (UTC) Received: by yenl2 with SMTP id l2so3292685yen.13 for ; Fri, 11 Nov 2011 08:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gTmefvHTl/FhP6HYwkaq+VT0dPcM1t9tJlPuz2XV0vk=; b=aOeBkBb9cI0xWnMb04+r8rN4YwX1D9C03f3XLXqPSS6l3xFQ0Dg7tcPgFBcVRmWrv4 3xNwEWobNLaY2cBUgmUQRCmFnq6szCeMXMFLtSzbqg52z+azoGiDX+8ISpgsVwJw/snX GhdzrwTS2hjrNb32n4nrVMeoxNpenwuhZb9p0= MIME-Version: 1.0 Received: by 10.101.139.24 with SMTP id r24mr5743290ann.11.1321028847187; Fri, 11 Nov 2011 08:27:27 -0800 (PST) Received: by 10.151.44.17 with HTTP; Fri, 11 Nov 2011 08:27:27 -0800 (PST) In-Reply-To: <4EBD472F.4030204@gmail.com> References: <2171368.58yxYs0Lbv@funbeast> <2185571.xNZoOVfxaV@funbeast> <4EBD33A1.2070705@quip.cz> <4EBD472F.4030204@gmail.com> Date: Fri, 11 Nov 2011 18:27:27 +0200 Message-ID: From: Alexander Yerenkow To: Johan Hendriks Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 16:27:28 -0000 > If FreeBSD starts using numbers for HEAD/CURRENT, i think a lot of users > would find them selves in a situation > that they download version 10 in this case and that they are using a > develepment version instead of a real release version. > Assuming there will be link from main page - probably yes. But if from official site they can get only RELEASE, and in some deep dark page link to current - they will not run into this. > > So FreeBSD will get more frustrated users, who need to download the latest > release again and so on. > Keeping the name more seperated from the normal numbering prevents this > more or less. > Hm, what's the problem to name development ISO's differently? Like, 10-CURRENT-UNSTABLE-*.iso VS 9-RELEASE.ISO So even very novice user will think twice before downloading. Is there any reason why ISOs can't be named differently from svn tag/branch? I don't see this. IMHO, this must have been done a lot of time ago. But, I may not know some constraints/restrictions/rules of development process, maybe HEAD is really necessary. I think this is more question to release engineering team than to current. > > Gr > Johan Hendriks > > > > > _______________________________________________ > 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" > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 17:29:52 2011 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 3F8E7106566B for ; Fri, 11 Nov 2011 17:29:52 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id D13058FC08 for ; Fri, 11 Nov 2011 17:29:51 +0000 (UTC) X-AuditID: 12074423-b7f266d0000008b8-e3-4ebd5b8e0e26 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id D2.13.02232.E8B5DBE4; Fri, 11 Nov 2011 12:29:50 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pABHTo4B011114; Fri, 11 Nov 2011 12:29:50 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pABHTnIR026832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Nov 2011 12:29:50 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pABHTmHR005621; Fri, 11 Nov 2011 12:29:48 -0500 (EST) Date: Fri, 11 Nov 2011 12:29:48 -0500 (EST) From: Benjamin Kaduk To: Mehmet Erol Sanliturk In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrdsXvdfPoO+XkcWcNx+YLPafTHJg 8pjxaT6Lx85Zd9kDmKK4bFJSczLLUov07RK4Mq7ffc9asJS7YuHV/cwNjNc4uhg5OSQETCQu HlzPCGGLSVy4t56ti5GLQ0hgH6PEqctHmCGcDYwSy/YfYgGpEhI4wCTx6lkqRKKBUWLzrUaw dhYBbYlJH9+ygthsAioSM99sZAOxRQSMJd42XgOzmQUMJV6uu8cOYgsLeEr0Hr4JVs8pECix 9NV/MJtXwF5i+ur/7BDLAiSebT4NtlhUQEdi9f4pLBA1ghInZz5hgZhpKXHuz3W2CYyCs5Ck ZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrppebWaKXmlK6iREUqOwuyjsY/xxUOsQo wMGoxMPL+We3nxBrYllxZe4hRkkOJiVR3j+he/2E+JLyUyozEosz4otKc1KLDzFKcDArifBO MQfK8aYkVlalFuXDpKQ5WJTEeWV2OvgJCaQnlqRmp6YWpBbBZGU4OJQkeK9HATUKFqWmp1ak ZeaUIKSZODhBhvMADQer4S0uSMwtzkyHyJ9iVJQS530CkhAASWSU5sH1whLJK0ZxoFeEea+A VPEAkxBc9yugwUxAg1kUwAaXJCKkpBoYpxzSDI3n4Zqe7SO0Usf3yiedlPBTG1T5Q9NrYrew M6v8+qB2quN91pwfZ9tXB4ld++Vwgn266O8LWXtu2Cv+nXLj0nSj/IeeYhwrn1a6WJsoJ1ju WNKv76S38HGR0YdLnv17ZW8ypHzgkS1U+sh/w0vz8r+GtJZ9PkvtmyzOHdsdqSNdyfhPiaU4 I9FQi7moOBEAQ6OqI/8CAAA= Cc: freebsd-current Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 17:29:52 -0000 On Fri, 11 Nov 2011, Mehmet Erol Sanliturk wrote: > Dear all , > > Instead of using Current and then renaming everything for a new version > number , > is it not possible to use the newest version number in place of Current > when it is branched . > > Such a change will prevent unnecessary renaming problems . > > > For everyone , it i very easy to understand that 10.0 is the latest , > therefore the current one . > > The current may be used as a symbolic link to the newest version number , > such as used by Debian . > > > For example , for FreeBSD 9.0 RC1 , the ports directory name was > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ > > > which is NOT available now , and > > > pkg_add -r * > > is giving error about directory not found . > > > This is preventing testing and / or using efforts . > > > I know , it is possible to rename local link names , but > everyone is not so much knowledgeable . I'm not sure I understand your proposal. In a month (er, two. well, maybe three) when 9.0 is released, do you propose that the svn HEAD be called: (a) 10.0 (b) 9-CURRENT (c) CURRENT (d) something else I do not realy care for either (a) or (b), since (a) would imply that the version is not changing, even as incompatible KBI/ABI changes are made. Likewise for (b), once the KBI/ABI changes, HEAD is decidedly no longer a form of '9'. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 18:18:09 2011 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 0A7E9106564A for ; Fri, 11 Nov 2011 18:18:09 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 90A458FC08 for ; Fri, 11 Nov 2011 18:18:08 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so4934792bkb.13 for ; Fri, 11 Nov 2011 10:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pH6XVCpNNveFMfTWhY0fCH/EjNUQPDyeWTxWg1QWuKs=; b=mRKxmAuZ6sRheixiM/x152MfcFzTS4+Az50kHQpVD8FfA8+/lDks55jcAtJ1Zsoij7 XXx0ybskW602kTNyVJ3VrHzHN9YQYnwJkcHd58P4tQYQmrT3+4HSI1PkPRvLLOQqGoTn 9CzPEXwvb2sQ5dfXhp9N1/AnUC25AOCPY73J4= MIME-Version: 1.0 Received: by 10.205.124.144 with SMTP id go16mr1494439bkc.119.1321034156141; Fri, 11 Nov 2011 09:55:56 -0800 (PST) Received: by 10.223.126.145 with HTTP; Fri, 11 Nov 2011 09:55:56 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Nov 2011 19:55:56 +0200 Message-ID: From: Vitaly Magerya To: Alexander Yerenkow Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: KMS testing, intel only 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, 11 Nov 2011 18:18:09 -0000 > Along with plain standard ones (plain world+kernel install of bare system) > I'm working on creating specific images. > Like with preset installed packages (kde-set, gnome-set, etc.), like with > some patches (area51/kde-wip/kms) etc. > So, I did not fully automated (yet) creating of this one image, but you > already can grab it to test: > > http://gits.kiev.ua/FreeBSD/FreeBSD-9-kms-i386-r227337-2011-11-10.img.xz This is very cool, Alexander, thanks a lot. May I suggest creating a bootable image to become the standard way of doing big calls for tests? Xorg team could get a lot more testers this way. For the record, my GMA 3150 card works flawlessly now (it only worked with VESA previously, but it was still unusable due to disproportional screen resolution). A big thank you goes to kib@ for the KMS work. Can't wait until this stuff is committed. From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 18:33:13 2011 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 395A6106564A for ; Fri, 11 Nov 2011 18:33:13 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id E92838FC14 for ; Fri, 11 Nov 2011 18:33:12 +0000 (UTC) Received: by qabj40 with SMTP id j40so4481069qab.13 for ; Fri, 11 Nov 2011 10:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ppKw4WcLsyMO7kpaFNEJvD6qesfr10GsJnB62gWx9OU=; b=F/LZCe8kia0vxItIcUfgq2t776acQyWXHamXqVTgjW27K+r/dGdPjW5RP2t3MWWkkA Q2CnHiwNaZdl08V8En804rqsgH3DY+nBgQeZHg3PuG5RjAmrAe89JKCtdcsWXmFzFqev LHPt6XNbu1aGOJzOYL3m53BQH4Oructk3iby4= MIME-Version: 1.0 Received: by 10.224.185.199 with SMTP id cp7mr9949100qab.68.1321036392012; Fri, 11 Nov 2011 10:33:12 -0800 (PST) Received: by 10.224.73.195 with HTTP; Fri, 11 Nov 2011 10:33:11 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Nov 2011 13:33:11 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 18:33:13 -0000 On Fri, Nov 11, 2011 at 12:29 PM, Benjamin Kaduk wrote: > On Fri, 11 Nov 2011, Mehmet Erol Sanliturk wrote: > > Dear all , >> >> Instead of using Current and then renaming everything for a new version >> number , >> is it not possible to use the newest version number in place of Current >> when it is branched . >> >> Such a change will prevent unnecessary renaming problems . >> >> >> For everyone , it i very easy to understand that 10.0 is the latest , >> therefore the current one . >> >> The current may be used as a symbolic link to the newest version number , >> such as used by Debian . >> >> >> For example , for FreeBSD 9.0 RC1 , the ports directory name was >> >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ >> >> >> which is NOT available now , and >> >> >> pkg_add -r * >> >> is giving error about directory not found . >> >> >> This is preventing testing and / or using efforts . >> >> >> I know , it is possible to rename local link names , but >> everyone is not so much knowledgeable . >> > > I'm not sure I understand your proposal. > In a month (er, two. well, maybe three) when 9.0 is released, do you > propose that the svn HEAD be called: > (a) 10.0 > (b) 9-CURRENT > (c) CURRENT > (d) something else > > I do not realy care for either (a) or (b), since (a) would imply that the > version is not changing, even as incompatible KBI/ABI changes are made. > Likewise for (b), once the KBI/ABI changes, HEAD is decidedly no longer a > form of '9'. > > -Ben Kaduk > During development of Version 9 , the name of directory was ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ During the 9.0 Release RC1 , the above name was used . Before releasing the 9.0 Release RC2 , the above has been changed . This change has broke the links in 9.0 Release RC1 . When we look at the ftp sites ( including mirrors ) all of them has changed . This naming structure is requiring re-structuring all of the directories over all ftp , and other sites . This is a wasted effort . Instead of doing this , a scheme like the following may be used : Instead of using /*-9-Current/ , use 10.0 for current . Assume our main directory is the following : ftp://ftp.freebsd.org/pub/FreeBSD/ As next directory , use 8.1 , 8.2 , 9.0 for current . ftp://ftp.freebsd.org/pub/FreeBSD/8.1/ ftp://ftp.freebsd.org/pub/FreeBSD/8.2/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/ All of the directories , for example , ... ports ... release ... snapshot ... whatever is related to 8.2 , 9.0 will be under 8.2 or 9.0 , in such a way that nowhere else a directory with name , for example , 9.0 will exist ... For example : ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/ports/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/packages/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/snapshot/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/release/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/stable/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/handbook/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/man/ .... Explain to the people that 9.0 is the "Development" branch , NOT for production use . A single sentence to learn . Another step may be to insert an explicit warning message into current motd file about "Development" status of 9.0 . When time comes to make a release of 9.0 , which a new development branch will be generated , take a copy of 9.0 , and rename this directory as 10.0 . By using suitable find/replace scripts , find all occurrences of 9.0 with strict match and replace them by 10.0 . After generating directory 10.0 , propagate it to mirrors . Please , notice that , NOTHING is changed for the 9.0 , and NOTHING is broken with respect to generation of a new branch , all over the world .... Then start to work on 10.0 ... Continue in that way . Apply the similar steps to 9.0 for 9.1 : Take a copy of 9.0 , rename it as 9.1 , ... Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 19:08:02 2011 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 0A4F0106566B for ; Fri, 11 Nov 2011 19:08:02 +0000 (UTC) (envelope-from luchesar.iliev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 844558FC0A for ; Fri, 11 Nov 2011 19:08:01 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so4988461bkb.13 for ; Fri, 11 Nov 2011 11:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :openpgp:content-type:content-transfer-encoding; bh=23TMMPFdWrNoeRnl6ZTIk3erThdzZFjJKudcQP2qcBg=; b=bXhf24fDzJKsw5h/3uEjCarYYJ3Ut9SWftSENWRf1tTAj4chbwGtbrVd1FFCtSmJBE huf7OJBRo1tYEm6TMOWptm05HkzXDCyrhmpYg/6/4pWEQZowK+1SZ9iP+V5bEcequQfi GYqvYyVrwZ4VX47+RcVradIopyqH2qcco0zhM= Received: by 10.204.9.216 with SMTP id m24mr9370437bkm.98.1321038480474; Fri, 11 Nov 2011 11:08:00 -0800 (PST) Received: from [79.124.93.41] ([79.124.93.41]) by mx.google.com with ESMTPS id o7sm2624311bkw.16.2011.11.11.11.07.58 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 11:07:59 -0800 (PST) Message-ID: <4EBD728D.3040206@gmail.com> Date: Fri, 11 Nov 2011 21:07:57 +0200 From: "Luchesar V. ILIEV" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=9A1FEEFF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 19:08:02 -0000 On 11/11/2011 20:33, Mehmet Erol Sanliturk wrote: > On Fri, Nov 11, 2011 at 12:29 PM, Benjamin Kaduk wrote: > >> On Fri, 11 Nov 2011, Mehmet Erol Sanliturk wrote: >> >> Dear all , >>> >>> Instead of using Current and then renaming everything for a new version >>> number , >>> is it not possible to use the newest version number in place of Current >>> when it is branched . >>> >>> Such a change will prevent unnecessary renaming problems . >>> >>> >>> For everyone , it i very easy to understand that 10.0 is the latest , >>> therefore the current one . >>> >>> The current may be used as a symbolic link to the newest version number , >>> such as used by Debian . >>> >>> >>> For example , for FreeBSD 9.0 RC1 , the ports directory name was >>> >>> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ >>> >>> >>> which is NOT available now , and >>> >>> >>> pkg_add -r * >>> >>> is giving error about directory not found . >>> >>> >>> This is preventing testing and / or using efforts . >>> >>> >>> I know , it is possible to rename local link names , but >>> everyone is not so much knowledgeable . >>> >> >> I'm not sure I understand your proposal. >> In a month (er, two. well, maybe three) when 9.0 is released, do you >> propose that the svn HEAD be called: >> (a) 10.0 >> (b) 9-CURRENT >> (c) CURRENT >> (d) something else >> >> I do not realy care for either (a) or (b), since (a) would imply that the >> version is not changing, even as incompatible KBI/ABI changes are made. >> Likewise for (b), once the KBI/ABI changes, HEAD is decidedly no longer a >> form of '9'. >> >> -Ben Kaduk >> > > > > > > During development of Version 9 , the name of directory was > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ > > During the 9.0 Release RC1 , the above name was used . > > Before releasing the 9.0 Release RC2 , the above has been changed . > > This change has broke the links in 9.0 Release RC1 . > > When we look at the ftp sites ( including mirrors ) all of them > has changed . > > This naming structure is requiring re-structuring all of the directories > over all ftp , and other sites . > > This is a wasted effort . > > Instead of doing this , a scheme like the following > may be used : > > > Instead of using /*-9-Current/ , use 10.0 for current . > > Assume our main directory is the following : > > ftp://ftp.freebsd.org/pub/FreeBSD/ > > As next directory , use 8.1 , 8.2 , 9.0 for current . > > > ftp://ftp.freebsd.org/pub/FreeBSD/8.1/ > ftp://ftp.freebsd.org/pub/FreeBSD/8.2/ > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/ > > All of the directories , for example , > ... ports > ... release > ... snapshot > ... whatever is related to 8.2 , 9.0 will be under 8.2 or 9.0 , > in such a way that nowhere else a directory with name , for example , > 9.0 will exist ... > > For example : > > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/ports/ > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/packages/ > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/snapshot/ > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/release/ > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/stable/ > > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/ > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/handbook/ > ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/man/ > > > > > .... > > > > Explain to the people that 9.0 is the "Development" branch , > NOT for production use . > > A single sentence to learn . > > Another step may be to insert an explicit > warning message into current motd file about "Development" status of 9.0 . > > > When time comes to make a release of 9.0 , which a new development > branch will be generated , > > take a copy of 9.0 , and rename this directory as 10.0 . > > By using suitable find/replace scripts , > > find all occurrences of 9.0 with strict match and replace them by 10.0 . > > > After generating directory 10.0 , propagate it to mirrors . > > Please , notice that , NOTHING is changed for the 9.0 , > and NOTHING is broken with respect to generation of a new branch , > all over the world .... > > > Then start to work on 10.0 ... > Continue in that way . > > Apply the similar steps to 9.0 for 9.1 : > > Take a copy of 9.0 , rename it as 9.1 , ... > > > Thank you very much . > > Mehmet Erol Sanliturk > _______________________________________________ > 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" Why do I have the feeling that this whole problem is simply a matter of r225757 not being MFC-ed to stable/9? http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/add/main.c?r1=222035&r2=225757 Cheers, Luchesar From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 19:44:35 2011 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 5E9C9106564A for ; Fri, 11 Nov 2011 19:44:35 +0000 (UTC) (envelope-from luchesar.iliev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DBD8A8FC12 for ; Fri, 11 Nov 2011 19:44:34 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5030241bkb.13 for ; Fri, 11 Nov 2011 11:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :openpgp:content-type:content-transfer-encoding; bh=pvxOhcoUw0t3yV3rlPoKhhjaD2dT+GSsDX5rQVHyFVU=; b=geuB0L+obTL/Kxe0HwwdBedwptXxZFQsVTvGrXnx+y5aPOs9sS+Dup7r8BlYOJr8I8 yL6QiAN8xnWa7jAqcJuDYYbokIdzRgFsqmyhivqh+zHuZ8El86YWYZLpFZTCk3k5AXu2 wg4ukBt1F2puk/+Bl1lfTPjt34EiYVId/MV14= Received: by 10.205.132.19 with SMTP id hs19mr1770813bkc.131.1321040673688; Fri, 11 Nov 2011 11:44:33 -0800 (PST) Received: from [79.124.93.41] ([79.124.93.41]) by mx.google.com with ESMTPS id x14sm12766071bkf.10.2011.11.11.11.44.31 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 11:44:32 -0800 (PST) Message-ID: <4EBD7B1F.4070906@gmail.com> Date: Fri, 11 Nov 2011 21:44:31 +0200 From: "Luchesar V. ILIEV" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current References: <4EBD728D.3040206@gmail.com> In-Reply-To: <4EBD728D.3040206@gmail.com> X-Enigmail-Version: undefined OpenPGP: id=9A1FEEFF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 19:44:35 -0000 On 11/11/2011 21:07, Luchesar V. ILIEV wrote: > On 11/11/2011 20:33, Mehmet Erol Sanliturk wrote: >> On Fri, Nov 11, 2011 at 12:29 PM, Benjamin Kaduk wrote: >> >>> On Fri, 11 Nov 2011, Mehmet Erol Sanliturk wrote: >>> >>> Dear all , >>>> >>>> Instead of using Current and then renaming everything for a new version >>>> number , >>>> is it not possible to use the newest version number in place of Current >>>> when it is branched . >>>> >>>> Such a change will prevent unnecessary renaming problems . >>>> >>>> >>>> For everyone , it i very easy to understand that 10.0 is the latest , >>>> therefore the current one . >>>> >>>> The current may be used as a symbolic link to the newest version number , >>>> such as used by Debian . >>>> >>>> >>>> For example , for FreeBSD 9.0 RC1 , the ports directory name was >>>> >>>> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ >>>> >>>> >>>> which is NOT available now , and >>>> >>>> >>>> pkg_add -r * >>>> >>>> is giving error about directory not found . >>>> >>>> >>>> This is preventing testing and / or using efforts . >>>> >>>> >>>> I know , it is possible to rename local link names , but >>>> everyone is not so much knowledgeable . >>>> >>> >>> I'm not sure I understand your proposal. >>> In a month (er, two. well, maybe three) when 9.0 is released, do you >>> propose that the svn HEAD be called: >>> (a) 10.0 >>> (b) 9-CURRENT >>> (c) CURRENT >>> (d) something else >>> >>> I do not realy care for either (a) or (b), since (a) would imply that the >>> version is not changing, even as incompatible KBI/ABI changes are made. >>> Likewise for (b), once the KBI/ABI changes, HEAD is decidedly no longer a >>> form of '9'. >>> >>> -Ben Kaduk >>> >> >> >> >> >> >> During development of Version 9 , the name of directory was >> >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ >> >> During the 9.0 Release RC1 , the above name was used . >> >> Before releasing the 9.0 Release RC2 , the above has been changed . >> >> This change has broke the links in 9.0 Release RC1 . >> >> When we look at the ftp sites ( including mirrors ) all of them >> has changed . >> >> This naming structure is requiring re-structuring all of the directories >> over all ftp , and other sites . >> >> This is a wasted effort . >> >> Instead of doing this , a scheme like the following >> may be used : >> >> >> Instead of using /*-9-Current/ , use 10.0 for current . >> >> Assume our main directory is the following : >> >> ftp://ftp.freebsd.org/pub/FreeBSD/ >> >> As next directory , use 8.1 , 8.2 , 9.0 for current . >> >> >> ftp://ftp.freebsd.org/pub/FreeBSD/8.1/ >> ftp://ftp.freebsd.org/pub/FreeBSD/8.2/ >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/ >> >> All of the directories , for example , >> ... ports >> ... release >> ... snapshot >> ... whatever is related to 8.2 , 9.0 will be under 8.2 or 9.0 , >> in such a way that nowhere else a directory with name , for example , >> 9.0 will exist ... >> >> For example : >> >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/ports/ >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/packages/ >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/snapshot/ >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/release/ >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/stable/ >> >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/ >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/handbook/ >> ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/man/ >> >> >> >> >> .... >> >> >> >> Explain to the people that 9.0 is the "Development" branch , >> NOT for production use . >> >> A single sentence to learn . >> >> Another step may be to insert an explicit >> warning message into current motd file about "Development" status of 9.0 . >> >> >> When time comes to make a release of 9.0 , which a new development >> branch will be generated , >> >> take a copy of 9.0 , and rename this directory as 10.0 . >> >> By using suitable find/replace scripts , >> >> find all occurrences of 9.0 with strict match and replace them by 10.0 . >> >> >> After generating directory 10.0 , propagate it to mirrors . >> >> Please , notice that , NOTHING is changed for the 9.0 , >> and NOTHING is broken with respect to generation of a new branch , >> all over the world .... >> >> >> Then start to work on 10.0 ... >> Continue in that way . >> >> Apply the similar steps to 9.0 for 9.1 : >> >> Take a copy of 9.0 , rename it as 9.1 , ... >> >> >> Thank you very much . >> >> Mehmet Erol Sanliturk >> _______________________________________________ >> 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" > > Why do I have the feeling that this whole problem is simply a matter of > r225757 not being MFC-ed to stable/9? > > http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/add/main.c?r1=222035&r2=225757 > > Cheers, > Luchesar I've filed a PR for this... http://www.freebsd.org/cgi/query-pr.cgi?pr=162490 Hopefully, I'm not getting it entirely wrong. :) Cheers, Luchesar P.S. The PR is not yet online. From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 20:49:35 2011 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 A29721065675 for ; Fri, 11 Nov 2011 20:49:35 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 03D9E8FC12 for ; Fri, 11 Nov 2011 20:49:33 +0000 (UTC) Received: from free.fr (unknown [82.235.65.2]) by smtp5-g21.free.fr (Postfix) with ESMTP id DD6EFD48111 for ; Fri, 11 Nov 2011 21:49:29 +0100 (CET) To: freebsd-current@freebsd.org From: rmgls@free.fr Date: Fri, 11 Nov 2011 21:48:03 +0100 Sender: root@free.fr Message-Id: <20111111204929.DD6EFD48111@smtp5-g21.free.fr> Subject: no sound on alc-889 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, 11 Nov 2011 20:49:35 -0000 Hello all, i try to unmute a box with a mcp79 ane alc-889. the sound is working on another os, and playback and recording are treated separately by os x, (10.7). i tried different combinations according to the snd_hda man page, but i cannot find a good one. Pleease, have you some hints? here is the config and pindump: hdac0: mem 0xd3480000-0xd3483fff irq 22 at device 8.0 on pci0 pci3: at device 0.0 (no driver attached) hdac0: HDA Codec #0: Realtek ALC885 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pins dump hdac0: Dumping AFG cad=0 nid=1 pins: hdac0: nid 20 0x012b4040 as 4 seq 0 Headphones Jack jack 11 loc 1 color Green misc 0 hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 hdac0: nid 21 0x018b3010 as 1 seq 0 Line-in Jack jack 11 loc 1 color Blue misc 0 hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 hdac0: nid 22 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: Caps: IN OUT HP Sense: 0x00000000 hdac0: nid 23 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: Caps: IN OUT HP Sense: 0x00000000 hdac0: nid 24 0x90100130 as 3 seq 0 Speaker Fixed jack 0 loc 16 color Unknown misc 1 hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 hdac0: nid 25 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 hdac0: nid 26 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 hdac0: nid 27 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 hdac0: nid 28 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: Caps: IN hdac0: nid 30 0x014be050 as 5 seq 0 SPDIF-out Jack jack 11 loc 1 color White misc 0 hdac0: Caps: OUT hdac0: nid 31 0x01cbe020 as 2 seq 0 SPDIF-in Jack jack 11 loc 1 color White misc 0 hdac0: Caps: IN hdac0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: GPIO: data=0x00000000 enable=0x00000000 direction=0x00000000 hdac0: wake=0x00000000 unsol=0x00000000 sticky=0x00000000 Thanks, in advance for your help. rmgls rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 22:11:02 2011 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 EA531106564A; Fri, 11 Nov 2011 22:11:02 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B6B808FC16; Fri, 11 Nov 2011 22:11:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pABMB2sU077330; Fri, 11 Nov 2011 22:11:02 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pABMB2pi077306; Fri, 11 Nov 2011 22:11:02 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Fri, 11 Nov 2011 23:10:58 +0100 From: Baptiste Daroussin To: John Baldwin Message-ID: <20111111221058.GA1911@azathoth.lan> References: <201107260803.47625.jhb@freebsd.org> <201107261544.51244.jhb@freebsd.org> <20110911203938.GA2913@azathoth.lan> <20110928222254.GM98977@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20110928222254.GM98977@azathoth.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: No disks usable on a P5NE MB (aka regession is r219737) 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, 11 Nov 2011 22:11:03 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 29, 2011 at 12:22:54AM +0200, Baptiste Daroussin wrote: > On Sun, Sep 11, 2011 at 10:39:38PM +0200, Baptiste Daroussin wrote: > > > > the result is: > > > > db> show intrcnt > > > > cpu0: timer 4510 > > > > irq256: hdac0 1 > > > > cpu3: timer 29 > > > > cpu1: timer 3036 > > > > cpu2: timer 31 > > > > db> > > > >=20 > > > > I did break at the mountfrom> prompt > > > > If I break before I only have the cpu0 and irq256 entries. > > >=20 > > > Hmmm, is there any way you can build a 9 kernel without sound support= (since=20 > > > that clutters up bootverbose) and capture a verbose dmesg, using a se= rial=20 > > > console or PXE booting to an NFS root of some sort? > > >=20 > > I can't pxe boot, but I can record the build on my camera: > > http://people.freebsd.org/~bapt/9-fail.avi (18MB) > >=20 > > (this is 9.0-BETA2 memstick) > >=20 > > Hope that could help > >=20 >=20 > Apparently this doesn't help, given that I have no way to netboot this bo= x, may > that be from pxe and that there is no serial console, what can I do more = to help > fixing this? >=20 > I would love to be able to run 9 on my box >=20 > regards, > Bapt After trying lots of different kernel it appears that the regression was introduce in r219737. I'm trying to figure out to solve this. If you have any clue tell me. regards, Bapt --envbJBWh7q8WU6mo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk69nXIACgkQ8kTtMUmk6EzDQQCeMPS51QsW6kHpkPSYXhlcsE9G /YUAn1zpI7Q/jE6kkGvnkc4Tsxs3bS5o =dtqn -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 22:16:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0F79A106566C for ; Fri, 11 Nov 2011 22:16:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 964B415009E; Fri, 11 Nov 2011 22:16:03 +0000 (UTC) Message-ID: <4EBD9EA3.90409@FreeBSD.org> Date: Fri, 11 Nov 2011 14:16:03 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Mehmet Erol Sanliturk References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 22:16:05 -0000 On 11/11/2011 04:29, Mehmet Erol Sanliturk wrote: > pkg_add -r * > > is giving error about directory not found . > > > This is preventing testing and / or using efforts . I see your perspective on this, but package support for HEAD (N-current) is always done on a "best effort" basis, and is incredibly likely to be broken during a new major branch release cycle no matter what. Also, because HEAD is a rapidly moving target the preferred way to deal with ports is to compile the ports, not to use packages at all. Or, to use packages when they exist, but compile everything else. The PACKAGESITE environment variable can help with that. Your point that "it should be easier" is well taken, I think moreso for the RCs than for HEAD. There has been some discussion about how to update the logic for pkg_add, but I'm not sure that symlinks are going to be the answer. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 22:23:37 2011 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 C93BF1065670 for ; Fri, 11 Nov 2011 22:23:37 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9502E8FC0A for ; Fri, 11 Nov 2011 22:23:37 +0000 (UTC) Received: by iakl21 with SMTP id l21so4475900iak.13 for ; Fri, 11 Nov 2011 14:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Si6kLYjPRrCMVJO7T4MLd83tGOJGShDrnTp2lUGHII4=; b=AoHjPPZYoWt3XTKQUH80vynNjS+mOlOENeqZGoZR1cSVkd5bFR2WIfzE5u446PRVEA Ymycpl7tMg2Cj0u5IsdDnJD99fiJrn5CTPAeJqyBZzduGGI04N8gOiuZDYjuGFLUQiL4 M7yakw0L1YiOfCV0LRMEr440pWd/yBlseN+B0= MIME-Version: 1.0 Received: by 10.50.170.105 with SMTP id al9mr14974336igc.28.1321050215644; Fri, 11 Nov 2011 14:23:35 -0800 (PST) Received: by 10.231.34.140 with HTTP; Fri, 11 Nov 2011 14:23:35 -0800 (PST) In-Reply-To: References: Date: Sat, 12 Nov 2011 00:23:35 +0200 Message-ID: From: George Kontostanos To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 22:23:37 -0000 On Fri, Nov 11, 2011 at 7:29 PM, Benjamin Kaduk wrote: > On Fri, 11 Nov 2011, Mehmet Erol Sanliturk wrote: > >> Dear all , >> >> Instead of using Current and then renaming everything =A0for a new versi= on >> number , >> is it not possible to use the newest version number in place of Current >> when it is branched . >> >> Such a change will prevent unnecessary renaming problems . >> >> >> For everyone , it i very easy to understand that 10.0 is the latest , >> therefore the current one . >> >> The current may be used as a symbolic link to the newest version number = , >> such as used by Debian . >> >> >> For example , for FreeBSD 9.0 RC1 , the ports directory name was >> >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ >> >> >> which is NOT available now , and >> >> >> pkg_add -r * >> >> is giving error about directory not found . >> >> >> This is preventing testing and / or using efforts . >> >> >> I know , it is possible to rename local link names , but >> everyone is not so much knowledgeable . > > I'm not sure I understand your proposal. > In a month (er, two. =A0well, maybe three) when 9.0 is released, do you > propose that the svn HEAD be called: > (a) 10.0 > (b) 9-CURRENT > (c) CURRENT > (d) something else > > I do not realy care for either (a) or (b), since (a) would imply that the > version is not changing, even as incompatible KBI/ABI changes are made. > Likewise for (b), once the KBI/ABI changes, HEAD is decidedly no longer a > form of '9'. > > -Ben Kaduk > _______________________________________________ > 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= " > I think he suggests a) 10 BTW I follow both stable and current lists. I have noticed that people still ask questions in current regarding 9-RC(*) problems. Maybe if it was clear that current is now 10 this would not happen. Cheers, --=20 George Kontostanos Aicom telecoms ltd http://www.barebsd.com From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 22:26:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9A6581065675 for ; Fri, 11 Nov 2011 22:26:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B2A701794E3; Fri, 11 Nov 2011 22:25:43 +0000 (UTC) Message-ID: <4EBDA0E7.4030707@FreeBSD.org> Date: Fri, 11 Nov 2011 14:25:43 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: George Kontostanos References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Benjamin Kaduk Subject: Re: Use of newest version number such as 10.0 instead of current 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, 11 Nov 2011 22:26:21 -0000 On 11/11/2011 14:23, George Kontostanos wrote: > BTW I follow both stable and current lists. I have noticed that people > still ask questions in current regarding 9-RC(*) problems. > Maybe if it was clear that current is now 10 this would not happen. Actually up until the actual release we encourage users to ask about the new branch on -current, for a variety of reasons. -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 22:59:12 2011 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 066651065672; Fri, 11 Nov 2011 22:59:12 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7618FC13; Fri, 11 Nov 2011 22:59:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pABMxB5x016818; Fri, 11 Nov 2011 22:59:11 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pABMxBnT016817; Fri, 11 Nov 2011 22:59:11 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Fri, 11 Nov 2011 23:59:07 +0100 From: Baptiste Daroussin To: John Baldwin Message-ID: <20111111225907.GA1993@azathoth.lan> References: <201107260803.47625.jhb@freebsd.org> <201107261544.51244.jhb@freebsd.org> <20110911203938.GA2913@azathoth.lan> <20110928222254.GM98977@azathoth.lan> <20111111221058.GA1911@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20111111221058.GA1911@azathoth.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: No disks usable on a P5NE MB (aka regession is r219737) 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, 11 Nov 2011 22:59:12 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 11, 2011 at 11:10:58PM +0100, Baptiste Daroussin wrote: > On Thu, Sep 29, 2011 at 12:22:54AM +0200, Baptiste Daroussin wrote: > > On Sun, Sep 11, 2011 at 10:39:38PM +0200, Baptiste Daroussin wrote: > > > > > the result is: > > > > > db> show intrcnt > > > > > cpu0: timer 4510 > > > > > irq256: hdac0 1 > > > > > cpu3: timer 29 > > > > > cpu1: timer 3036 > > > > > cpu2: timer 31 > > > > > db> > > > > >=20 > > > > > I did break at the mountfrom> prompt > > > > > If I break before I only have the cpu0 and irq256 entries. > > > >=20 > > > > Hmmm, is there any way you can build a 9 kernel without sound suppo= rt (since=20 > > > > that clutters up bootverbose) and capture a verbose dmesg, using a = serial=20 > > > > console or PXE booting to an NFS root of some sort? > > > >=20 > > > I can't pxe boot, but I can record the build on my camera: > > > http://people.freebsd.org/~bapt/9-fail.avi (18MB) > > >=20 > > > (this is 9.0-BETA2 memstick) > > >=20 > > > Hope that could help > > >=20 > >=20 > > Apparently this doesn't help, given that I have no way to netboot this = box, may > > that be from pxe and that there is no serial console, what can I do mor= e to help > > fixing this? > >=20 > > I would love to be able to run 9 on my box > >=20 > > regards, > > Bapt >=20 > After trying lots of different kernel it appears that the regression was > introduce in r219737. I'm trying to figure out to solve this. >=20 > If you have any clue tell me. >=20 > regards, > Bapt With the help of cognet, I workaround this and have been able to boot both = 9 and 10 remove that block : http://people.freebsd.org/~bapt/workaround-to-boot-p5ne.diff regards, Bapt --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk69qLsACgkQ8kTtMUmk6ExQ+gCcCE1ZPV/ti5Ly6TxPCBz2uhGX Qs0AmwUcosarRojCYdaUk48ikmlrbvQL =exxr -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 01:36:36 2011 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 522F61065674 for ; Sat, 12 Nov 2011 01:36:36 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 854F28FC15 for ; Sat, 12 Nov 2011 01:36:35 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3SgLLV452vzGMVW for ; Sat, 12 Nov 2011 02:36:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:organization:user-agent:date:date:subject:subject :from:from:received:received:received:vbr-info; s=jakla2; t= 1321061792; x=1323653793; bh=5wI4ioi+I1WHgsC0GH4AGMd2AfSCOcxIGLi JtP8wSjQ=; b=SJYNe7aioUqnTGIPToxw/PES+Nllk3vY+GuaFDEDc7SVMKFZAmF 4Wwi7jInPbgw0PLTmFhUiYAtwfUzvBQwtiEOU8856m8DUIJIfgL5losZDr1vuLfL moXffuC32cBYhPDRBoSgwsgfqa+wLzg1YbFbgG1T6eOSaPnCrxBQv7e4= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id gq6bQwUE_u_J for ; Sat, 12 Nov 2011 02:36:32 +0100 (CET) Received: from rozamunda.ijs.si (unknown [IPv6:2001:1470:ff80:0:225:90ff:fe11:b090]) by mail.ijs.si (Postfix) with ESMTP for ; Sat, 12 Nov 2011 02:36:32 +0100 (CET) Received: from sleepy.ijs.si (upc.si.94.140.92.23.dc.cable.static.telemach.net [94.140.92.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rozamunda.ijs.si (Postfix) with ESMTPSA id 7071E211571 for ; Sat, 12 Nov 2011 02:36:32 +0100 (CET) From: Mark Martinec To: freebsd-current@freebsd.org Date: Sat, 12 Nov 2011 02:36:31 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC2; KDE/4.7.2; amd64; ; ) Organization: J. Stefan Institute MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201111120236.31359.Mark.Martinec+freebsd@ijs.si> Subject: Upgrading 8.2 to 9.0-rc2: missing directories at 'make installkernel' 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, 12 Nov 2011 01:36:36 -0000 When upgrading a FreeBSD 8.2 (amd64) to today's csup (tag=RELENG_9, i.e. 9.0-RC2), the standard procedure got itself into trouble: rm -rf /usr/obj make buildworld make buildkernel KERNCONF=xxx make installkernel KERNCONF=xxx (the xxx is mostly a plain vanilla 'include GENERIC' with pf altq and GEOM_ELI added). The 'make installkernel' phase was failing on missing directories. Creating these manually and repeating the make installkernel eventually lead to a successful installation. The missing directories that needed to be created manually were: /usr/include/clang (and possibly /usr/include/clang/3.0 ) /usr/include/gcc (and possibly /usr/include/gcc/4.2 ) /libexec/resolvconf /usr/share/doc/llvm /usr/share/locale/la_LN.ISO8859-13/LC_COLLATE [...] Actually the /usr/share/locale was a mess, missing several files, so I ended up replacing this directory by what has been built in the 'make buildworld' phase under /usr/obj. Just wanted to point out a possible problem others may encounter. Mark From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 09:26:18 2011 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 AA4F3106566B for ; Sat, 12 Nov 2011 09:26:18 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 391D98FC14 for ; Sat, 12 Nov 2011 09:26:18 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 68ACD90E; Sat, 12 Nov 2011 10:26:16 +0100 (CET) Date: Sat, 12 Nov 2011 10:25:23 +0100 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20111112092523.GA2327@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org Subject: Are there any users of accelerated asymmetric cryptography? 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, 12 Nov 2011 09:26:18 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'm in the process of rewriting large parts of the opencrypto framework and was wondering if there are any users that actually make use of asymmetric cryptography. From what I see only ubsec(4) driver supports it and from what I remember those cards are hard to find. If there are no users of this functionality I plan to remove support for asym crypto from the opencrypto framework. It is just too hard to maintain this without test hardware and also quite pointless if nobody uses it. If some users can be found and they really need it, we have two options: 1. Keep asym crypto around, but whoever steps up have to be ready to test patches. 2. Use alternative way of accessing it (eg. via direct ioctl to ubsec device), at least until we start to support more cards. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6+O4IACgkQForvXbEpPzRC6ACg0lhaejPpVuAe1s2Z6LbujGzR zwoAnidSNUWQYnBslVP8hIYnnahNRiUF =kIKG -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 10:34:27 2011 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 8368C106566B; Sat, 12 Nov 2011 10:34:27 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 06A6D8FC16; Sat, 12 Nov 2011 10:34:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pACAMgZA075766; Sat, 12 Nov 2011 14:22:42 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pACAMfAC075765; Sat, 12 Nov 2011 14:22:42 +0400 (MSK) (envelope-from ache) Date: Sat, 12 Nov 2011 14:22:41 +0400 From: Andrey Chernov To: David Schultz , current@freebsd.org, secteam@freebsd.org Message-ID: <20111112102241.GA75396@vniz.net> Mail-Followup-To: Andrey Chernov , David Schultz , current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080916201932.GA59781@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Is fork() hook ever possible? 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, 12 Nov 2011 10:34:27 -0000 On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > secteam@ already agreed to the idea of solving the fork problem as > in OpenBSD over a month ago. On Wed, Sep 17, 2008 at 12:50:25PM +0400, Andrey Chernov wrote: > I agree with your patch (BTW you can remove unneded #define RANDOMDEV). The question remains: why you don't commit this patch all that 3 years, having secteam@ and mine agreements too? > --- /usr/ob/src/lib/libc/crypt/arc4random.c 2008-06-03 20:50:23.000000000 -0400 > +++ arc4random.c 2008-08-16 15:14:59.000000000 -0400 > @@ -34,21 +34,22 @@ > * RC4 is a registered trademark of RSA Laboratories. > */ > > +#include > +__FBSDID("$FreeBSD: head/lib/libc/gen/arc4random.c 181261 2008-08-03 20:15:22Z ache $"); > + > +#include "namespace.h" > #include > #include > #include > #include > +#include > #include > #include > #include > #include > -#include "thread_private.h" > > -#ifdef __GNUC__ > -#define inline __inline > -#else /* !__GNUC__ */ > -#define inline > -#endif /* !__GNUC__ */ > +#include "libc_private.h" > +#include "un-namespace.h" > > struct arc4_stream { > u_int8_t i; > @@ -56,6 +57,21 @@ > u_int8_t s[256]; > }; > > +static pthread_mutex_t arc4random_mtx = PTHREAD_MUTEX_INITIALIZER; > + > +#define RANDOMDEV "/dev/urandom" > +#define _ARC4_LOCK() \ > + do { \ > + if (__isthreaded) \ > + _pthread_mutex_lock(&arc4random_mtx); \ > + } while (0) > + > +#define _ARC4_UNLOCK() \ > + do { \ > + if (__isthreaded) \ > + _pthread_mutex_unlock(&arc4random_mtx); \ > + } while (0) > + > static int rs_initialized; > static struct arc4_stream rs; > static pid_t arc4_stir_pid; > @@ -114,9 +130,9 @@ > > /* > * Discard early keystream, as per recommendations in: > - * http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps > + * "(Not So) Random Shuffles of RC4" by Ilya Mironov. > */ > - for (i = 0; i < 256; i++) > + for (i = 0; i < 1024; i++) > (void)arc4_getbyte(); > arc4_count = 1600000; > } > @@ -135,6 +151,7 @@ > return (rs.s[(si + sj) & 0xff]); > } > > +#if 0 > u_int8_t > __arc4_getbyte(void) > { > @@ -147,6 +164,7 @@ > _ARC4_UNLOCK(); > return val; > } > +#endif > > static inline u_int32_t > arc4_getword(void) -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 10:47:46 2011 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 C0DFF1065670; Sat, 12 Nov 2011 10:47:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DFE528FC14; Sat, 12 Nov 2011 10:47:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA04918; Sat, 12 Nov 2011 12:47:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPB7f-000LmC-1R; Sat, 12 Nov 2011 12:47:43 +0200 Message-ID: <4EBE4ECC.4060007@FreeBSD.org> Date: Sat, 12 Nov 2011 12:47:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: FreeBSD current , Alan Cox X-Enigmail-Version: undefined Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: problem with 1GB pages? 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, 12 Nov 2011 10:47:46 -0000 Introduction. I have an AMD-based system with a Fam10h CPU (with 1GB pages support), the system chipset contains an integrated graphics device (that uses a region of the main memory as a graphics memory). The chipset supports memory hoisting to compensate for the PCI memory window and the graphics aperture both of which are located below 4GB. The latest OS version installed on this system is 9-CURRENT from the middle of September (r225560), architecture is amd64. Until recently the system had 4GB of RAM installed and I had no problems with it whatsoever. Recently though I have added another 4GB of RAM to the system. Before booting to FreeBSD I tested the memory with multiple passes of memtest86 and memetest86+, no errors were detected by those. However with FreeBSD I immediately started getting "flaky memory" symptoms like multiple internal compiler errors during compilation of non-trivially sized projects (world, libreoffice). I re-run memory tests which again revealed nothing and then started playing with various VM subsystem and memory related knobs in FreeBSD. I recalled that a long while ago there were some problems with 1GB pages and so their use used to be disabled. On a hunch I disabled 1GB pages again: @@ -471,7 +471,7 @@ create_pagetables(vm_paddr_t *firstaddr) ndmpdp = 4; DMPDPphys = allocpages(firstaddr, NDMPML4E); ndm1g = 0; - if ((amd_feature & AMDID_PAGE1GB) != 0) + if (0 && (amd_feature & AMDID_PAGE1GB) != 0) ndm1g = ptoa(Maxmem) >> PDPSHIFT; if (ndm1g < ndmpdp) DMPDphys = allocpages(firstaddr, ndmpdp - ndm1g); And the flakiness went away. Not sure what kind of useful information I should provide with this report. Here's couple of things that I think could be of use. - memcontrol list output http://people.freebsd.org/~avg/8gb%2b512mb.memcontrol.list.txt - BIOS memory map SMAP type=01 base=0000000000000000 end=000000000009f800 len=000000000009f800 SMAP type=02 base=00000000000f0000 end=0000000000100000 len=0000000000010000 SMAP type=02 base=00000000fec00000 end=0000000100000000 len=0000000001400000 SMAP type=02 base=00000000e0000000 end=00000000f0000000 len=0000000010000000 SMAP type=02 base=000000000009f800 end=00000000000a0000 len=0000000000000800 SMAP type=02 base=00000000afdf0000 end=00000000afe00000 len=0000000000010000 SMAP type=01 base=0000000000100000 end=00000000afde0000 len=00000000afce0000 SMAP type=03 base=00000000afde3000 end=00000000afdf0000 len=000000000000d000 SMAP type=04 base=00000000afde0000 end=00000000afde3000 len=0000000000003000 SMAP type=01 base=0000000100000000 end=0000000230000000 len=0000000130000000 - dmesg snippet CPU: AMD Athlon(tm) II X2 250 Processor (3013.78-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 7617662976 (7264 MB) - Top Of Memory MSR MSR 0xc001001a: 0x00000000 0xd0000000 - Top Of Memory 2 MSR MSR 0xc001001d: 0x00000002 0x30000000 - System configuration MSR MSR 0xc0010010: 0x00000000 0x00760600 Please let me know if you have any ideas or requests for additional information or testing. Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 10:55:42 2011 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 88CFE106566B for ; Sat, 12 Nov 2011 10:55:42 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 46F9A8FC0A for ; Sat, 12 Nov 2011 10:55:42 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 6B0CF119C75; Sat, 12 Nov 2011 04:55:41 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1321095341; bh=ZAh4W6dFedrziNzefn8jhv/QIO+Kwx4ih3bENZZhS74=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=DynGVa3PkTvCEPuFkB16K+xYIqcWlEhFjom8o+B4t5pinpymU/NLX2aH8XlhBJoVE bW+pLXbqS23sIdxkw7iHlzufj/0mGZSjGKoVo49AG3trZ036ykb9O0DFWFD1L+g3Yj ST1dnhMTV8ynyREPMyZ3ASuIO/fv4LV0Owk+UuaA= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 654B7119C6C; Sat, 12 Nov 2011 04:55:41 -0600 (CST) Date: Sat, 12 Nov 2011 04:55:41 -0600 (CST) From: Dan The Man To: Kurt Touet In-Reply-To: Message-ID: References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2338054437-460234558-1321095341=:65294" Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: samba+zfs 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, 12 Nov 2011 10:55:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2338054437-460234558-1321095341=:65294 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Well been running a week now and problems again. 3 3 terrabyte drives are @85% with compression enabled, i have to wonder if that is part of the problem. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com On Wed, 9 Nov 2011, Kurt Touet wrote: > On Wed, Nov 9, 2011 at 1:07 AM, Daniel O'Connor wrote: >> >> On 09/11/2011, at 17:32, Garrett Cooper wrote >>>> dd's of large files (spooled backups going to tape) to /dev/null are as slow as Samba. >>> >>>    - Dedupe? >> >> Nope. >> >>>    - Compression? >> >> On the mail spool & ports, but not on the tape spool. >> >>>    - How much RAM? >> >> 8GB. >> >>>    - What debug options do you have enabled in the kernel? >> >> It is 8.2-GENERIC so.. no WITNESS (for example) >> >>>    I've been noticing a slowdown in some respects with NFS/SMB, but I >>> suspected it was because I have an re(4) based NIC. ZFS has also wired >>> down a lot of my system memory for the L2ARC… >> >> >> re isn't great but I wouldn't expect it to slow down over time.. Unless bounce buffers got used more and more or something. >> >> I have an em0 card in this system - but in any case it is slow locally (i.e. dd a large file with 64k block size). >> >> -- >> Daniel O'Connor software and network engineer >> for Genesis Software - http://www.gsoft.com.au >> "The nice thing about standards is that there >> are so many of them to choose from." >>  -- Andrew Tanenbaum >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> >> > > Right now (while experience slow writes via samba+zfs) this is general > read speed off a 4 x 1.5TB sata2 raidz1: > > # dd if=test.file of=/dev/null > 13753502+1 records in > 13753502+1 records out > 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) > > That's not in the same ball park of slow writes, but it is below what > I expect for reads. > > My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb > mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 > 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for > 7 days > > The above file read was stored before the 2 x 2tb mirror addition, so > it was a solely read off the sata2 mobo ports. Reading off of > something more recent (and split amongst both raidz1 and mirror > vdevs): > > # dd if=test2.file of=/dev/null > 9154715+1 records in > 9154715+1 records out > 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) > > This is, again, seems slower than usual, but not as terrible as the > write speeds that I've been seeing via samba. > --2338054437-460234558-1321095341=:65294-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 11:26:44 2011 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 4A9C91065673 for ; Sat, 12 Nov 2011 11:26:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C65B78FC12 for ; Sat, 12 Nov 2011 11:26:43 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5757542bkb.13 for ; Sat, 12 Nov 2011 03:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=BtcID5jUuF25594DQQpTWeFFUIyjoibqRr3wQlIOFNo=; b=g3c+8i95p5NCfUN5sl5GgqFyyVUpF7I3Nf2kA2gqNuI6C47rPr1MGuEGT/a1cqK0C/ YfWKL3z6xC9iGROYWmZpRIO0d3uPXjIkujm24/01YAeoOa8TnLnDpPK9z/1orXkMDHRv QztveyTQXEzv2Zgu912Rt1J+XdsJOjlPEpFio= Received: by 10.205.123.3 with SMTP id gi3mr4151140bkc.112.1321097202548; Sat, 12 Nov 2011 03:26:42 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id o7sm7451738bkw.16.2011.11.12.03.26.40 (version=SSLv3 cipher=OTHER); Sat, 12 Nov 2011 03:26:41 -0800 (PST) Sender: Alexander Motin Message-ID: <4EBE57F3.4090102@FreeBSD.org> Date: Sat, 12 Nov 2011 13:26:43 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: rmgls@free.fr References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: current Subject: Re: no sound on alc-889 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, 12 Nov 2011 11:26:44 -0000 On 11.11.2011 22:48, rmgls@free.fr wrote: > i try to unmute a box with a mcp79 ane alc-889. > > the sound is working on another os, and playback > and recording are treated separately by os x, (10.7). > > i tried different combinations according to the snd_hda man page, > but i cannot find a good one. > > Pleease, have you some hints? > > here is the config and pindump: > > hdac0: mem 0xd3480000-0xd3483fff irq 22 at device 8.0 on pci0 > > pci3: at device 0.0 (no driver attached) > hdac0: HDA Codec #0: Realtek ALC885 > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac0 > pcm2: at cad 0 nid 1 on hdac0 > pins dump > hdac0: Dumping AFG cad=0 nid=1 pins: > hdac0: nid 20 0x012b4040 as 4 seq 0 Headphones Jack jack 11 loc 1 color Green misc 0 > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > hdac0: nid 21 0x018b3010 as 1 seq 0 Line-in Jack jack 11 loc 1 color Blue misc 0 > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > hdac0: nid 22 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > hdac0: Caps: IN OUT HP Sense: 0x00000000 > hdac0: nid 23 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > hdac0: Caps: IN OUT HP Sense: 0x00000000 > hdac0: nid 24 0x90100130 as 3 seq 0 Speaker Fixed jack 0 loc 16 color Unknown misc 1 > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > hdac0: nid 25 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > hdac0: nid 26 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > hdac0: nid 27 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > hdac0: nid 28 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > hdac0: Caps: IN > hdac0: nid 30 0x014be050 as 5 seq 0 SPDIF-out Jack jack 11 loc 1 color White misc 0 > hdac0: Caps: OUT > hdac0: nid 31 0x01cbe020 as 2 seq 0 SPDIF-in Jack jack 11 loc 1 color White misc 0 > hdac0: Caps: IN > hdac0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 > hdac0: GPIO: data=0x00000000 enable=0x00000000 direction=0x00000000 > hdac0: wake=0x00000000 unsol=0x00000000 sticky=0x00000000 > > Thanks, in advance for your help. Could you describe what exactly doesn't work? Do you have sound from speaker or headphones output? In your case headphones are on separate device pcm2/dsp2, but it can be reconfigured for automatic playback redirection with such hint: hint.hdac.0.cad0.nid20.config="as=3 seq=15" -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 12:05:10 2011 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 39449106567F; Sat, 12 Nov 2011 12:05:10 +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 E11358FC08; Sat, 12 Nov 2011 12:05:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACC58aA001686; Sat, 12 Nov 2011 07:05:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACC58ap001682; Sat, 12 Nov 2011 12:05:08 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 12:05:08 GMT Message-Id: <201111121205.pACC58ap001682@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 arm/arm 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, 12 Nov 2011 12:05:10 -0000 TB --- 2011-11-12 11:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 11:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-12 11:20:00 - cleaning the object tree TB --- 2011-11-12 11:20:29 - cvsupping the source tree TB --- 2011-11-12 11:20:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-12 11:21:00 - building world TB --- 2011-11-12 11:21:00 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 11:21:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 11:21:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 11:21:00 - SRCCONF=/dev/null TB --- 2011-11-12 11:21:00 - TARGET=arm TB --- 2011-11-12 11:21:00 - TARGET_ARCH=arm TB --- 2011-11-12 11:21:00 - TZ=UTC TB --- 2011-11-12 11:21:00 - __MAKE_CONF=/dev/null TB --- 2011-11-12 11:21:00 - cd /src TB --- 2011-11-12 11:21:00 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 11:21:00 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 12:05:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 12:05:08 - ERROR: failed to build world TB --- 2011-11-12 12:05:08 - 1894.68 user 600.02 system 2707.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 12:40:14 2011 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 BD4B2106566C for ; Sat, 12 Nov 2011 12:40:14 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 869728FC0A for ; Sat, 12 Nov 2011 12:40:14 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 5E8A710256E; Sat, 12 Nov 2011 13:40:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <598941321021900@web148.yandex.ru> Date: Sat, 12 Nov 2011 13:40:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <598941321021900@web148.yandex.ru> To: Darren Baginski X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current Current Subject: Re: Unable to boot from zfsroot 9.0-RC2 (while 9.0-RC1 boots fine) 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, 12 Nov 2011 12:40:14 -0000 Am 11.11.2011 um 15:31 schrieb Darren Baginski: > I'm having troubles booting today's 9.0-RC2 from zfsroot, I'm getting = 'unknown filesystem' error. > But 9.0-RC1 from Tue Nov 8 2011 boots fine. ... > Any suggestions ? What could be the problem? See the recent thread "ZFS: invalid zap_type=3D134218628". It appears = there's some fixes that need to be MFCed; one user installed -current = zfsboot and zfsloader, and was able to boot successfully. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 13:11:24 2011 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 701BF106564A; Sat, 12 Nov 2011 13:11: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 220438FC0A; Sat, 12 Nov 2011 13:11:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACDBNbv064807; Sat, 12 Nov 2011 08:11:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACDBNZD064777; Sat, 12 Nov 2011 13:11:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 13:11:23 GMT Message-Id: <201111121311.pACDBNZD064777@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: Sat, 12 Nov 2011 13:11:24 -0000 TB --- 2011-11-12 11:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 11:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-12 11:20:00 - cleaning the object tree TB --- 2011-11-12 11:20:25 - cvsupping the source tree TB --- 2011-11-12 11:20:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-12 11:21:00 - building world TB --- 2011-11-12 11:21:00 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 11:21:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 11:21:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 11:21:00 - SRCCONF=/dev/null TB --- 2011-11-12 11:21:00 - TARGET=pc98 TB --- 2011-11-12 11:21:00 - TARGET_ARCH=i386 TB --- 2011-11-12 11:21:00 - TZ=UTC TB --- 2011-11-12 11:21:00 - __MAKE_CONF=/dev/null TB --- 2011-11-12 11:21:00 - cd /src TB --- 2011-11-12 11:21:00 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 11:21:00 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 13:11:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 13:11:22 - ERROR: failed to build world TB --- 2011-11-12 13:11:22 - 5385.24 user 917.37 system 6681.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 13:17:05 2011 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 522F91065672; Sat, 12 Nov 2011 13:17:05 +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 0460D8FC1D; Sat, 12 Nov 2011 13:17:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACDH3YX017841; Sat, 12 Nov 2011 08:17:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACDH3C8017837; Sat, 12 Nov 2011 13:17:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 13:17:03 GMT Message-Id: <201111121317.pACDH3C8017837@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/i386 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, 12 Nov 2011 13:17:05 -0000 TB --- 2011-11-12 11:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 11:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-12 11:20:00 - cleaning the object tree TB --- 2011-11-12 11:20:48 - cvsupping the source tree TB --- 2011-11-12 11:20:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-12 11:26:13 - building world TB --- 2011-11-12 11:26:13 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 11:26:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 11:26:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 11:26:13 - SRCCONF=/dev/null TB --- 2011-11-12 11:26:13 - TARGET=i386 TB --- 2011-11-12 11:26:13 - TARGET_ARCH=i386 TB --- 2011-11-12 11:26:13 - TZ=UTC TB --- 2011-11-12 11:26:13 - __MAKE_CONF=/dev/null TB --- 2011-11-12 11:26:13 - cd /src TB --- 2011-11-12 11:26:13 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 11:26:14 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 13:17:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 13:17:03 - ERROR: failed to build world TB --- 2011-11-12 13:17:03 - 5394.73 user 901.66 system 7023.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 13:43:39 2011 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 5B4551065673; Sat, 12 Nov 2011 13:43:39 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 53C068FC12; Sat, 12 Nov 2011 13:43:36 +0000 (UTC) Received: from free.fr (unknown [82.235.65.2]) by smtp5-g21.free.fr (Postfix) with ESMTP id D6004D481A3; Sat, 12 Nov 2011 14:43:32 +0100 (CET) To: Alexander Motin From: Raoul Date: Sat, 12 Nov 2011 15:42:06 +0100 Sender: root@free.fr Message-Id: <20111112134332.D6004D481A3@smtp5-g21.free.fr> Cc: current Subject: Re: no sound on alc-889 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, 12 Nov 2011 13:43:39 -0000 On Sat, 12 Nov 2011 13:26:43 +0200 Alexander Motin wroe: > On 11.11.2011 22:48, rmgls@free.fr wrote: > > i try to unmute a box with a mcp79 ane alc-889. > > > > the sound is working on another os, and playback > > and recording are treated separately by os x, (10.7). > > > > i tried different combinations according to the snd_hda man page, > > but i cannot find a good one. > > > > Pleease, have you some hints? > > > > here is the config and pindump: > > > > hdac0: mem 0xd3480000-0xd3483fff irq 22 at device 8.0 on pci0 > > > > pci3: at device 0.0 (no driver attached) > > hdac0: HDA Codec #0: Realtek ALC885 > > pcm0: at cad 0 nid 1 on hdac0 > > pcm1: at cad 0 nid 1 on hdac0 > > pcm2: at cad 0 nid 1 on hdac0 > > pins dump > > hdac0: Dumping AFG cad=0 nid=1 pins: > > hdac0: nid 20 0x012b4040 as 4 seq 0 Headphones Jack jack 11 loc 1 color Green misc 0 > > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > > hdac0: nid 21 0x018b3010 as 1 seq 0 Line-in Jack jack 11 loc 1 color Blue misc 0 > > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > > hdac0: nid 22 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > > hdac0: Caps: IN OUT HP Sense: 0x00000000 > > hdac0: nid 23 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > > hdac0: Caps: IN OUT HP Sense: 0x00000000 > > hdac0: nid 24 0x90100130 as 3 seq 0 Speaker Fixed jack 0 loc 16 color Unknown misc 1 > > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > > hdac0: nid 25 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > > hdac0: nid 26 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > > hdac0: nid 27 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > > hdac0: Caps: IN OUT HP VREF Sense: 0x00000000 > > hdac0: nid 28 0x400000f0 as 15 seq 0 Line-out None jack 0 loc 0 color Unknown misc 0 [DISABLED] > > hdac0: Caps: IN > > hdac0: nid 30 0x014be050 as 5 seq 0 SPDIF-out Jack jack 11 loc 1 color White misc 0 > > hdac0: Caps: OUT > > hdac0: nid 31 0x01cbe020 as 2 seq 0 SPDIF-in Jack jack 11 loc 1 color White misc 0 > > hdac0: Caps: IN > > hdac0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 > > hdac0: GPIO: data=0x00000000 enable=0x00000000 direction=0x00000000 > > hdac0: wake=0x00000000 unsol=0x00000000 sticky=0x00000000 > > > > Thanks, in advance for your help. > Could you describe what exactly doesn't work? Do you have sound from > speaker or headphones output? In your case headphones are on separate > device pcm2/dsp2, but it can be reconfigured for automatic playback > redirection with such hint: > hint.hdac.0.cad0.nid20.config="as=3 seq=15" Hi Alexander in fact no sound nor internal hp, nor from line out/(digital output). with your hint, the only change is, pcm2 disappeared. and stillno sound at all. some pecisions: hardware: macmini (intel core duo) built on 6-2009 with: line in line out/phone. i observe this behavior on a macpro and even on a macbook air too: i mean no sound at all. with an external amplification i can hear very low signal: (perhaps a crosstalk)? i can not say anything about input as the output is not working. in other hand, The snd_hda man page does not say the meaning of the association numbers 1-14, there is only 0 -> disabled, and 15 -> unassociated??? can you tell me what they represent, and if you have time, add some words on the man page? many thanks for your help. Raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 13:59:20 2011 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 8FE81106566B; Sat, 12 Nov 2011 13:59:20 +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 421638FC0C; Sat, 12 Nov 2011 13:59:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACDxJLf073758; Sat, 12 Nov 2011 08:59:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACDxJ6N073650; Sat, 12 Nov 2011 13:59:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 13:59:19 GMT Message-Id: <201111121359.pACDxJ6N073650@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 mips/mips 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, 12 Nov 2011 13:59:20 -0000 TB --- 2011-11-12 13:11:23 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 13:11:23 - starting HEAD tinderbox run for mips/mips TB --- 2011-11-12 13:11:23 - cleaning the object tree TB --- 2011-11-12 13:11:32 - cvsupping the source tree TB --- 2011-11-12 13:11:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-11-12 13:11:45 - building world TB --- 2011-11-12 13:11:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 13:11:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 13:11:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 13:11:45 - SRCCONF=/dev/null TB --- 2011-11-12 13:11:45 - TARGET=mips TB --- 2011-11-12 13:11:45 - TARGET_ARCH=mips TB --- 2011-11-12 13:11:45 - TZ=UTC TB --- 2011-11-12 13:11:45 - __MAKE_CONF=/dev/null TB --- 2011-11-12 13:11:45 - cd /src TB --- 2011-11-12 13:11:45 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 13:11:46 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O -pipe -G0 -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O -pipe -G0 -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 13:59:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 13:59:19 - ERROR: failed to build world TB --- 2011-11-12 13:59:19 - 2007.28 user 578.16 system 2875.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 15:00:23 2011 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 53A09106564A; Sat, 12 Nov 2011 15:00:23 +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 7EABF8FC16; Sat, 12 Nov 2011 15:00:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACF09pV085902; Sat, 12 Nov 2011 10:00:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACF09Yb085870; Sat, 12 Nov 2011 15:00:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 15:00:09 GMT Message-Id: <201111121500.pACF09Yb085870@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, 12 Nov 2011 15:00:23 -0000 TB --- 2011-11-12 13:17:04 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 13:17:04 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-12 13:17:04 - cleaning the object tree TB --- 2011-11-12 13:17:16 - cvsupping the source tree TB --- 2011-11-12 13:17:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-12 13:17:29 - building world TB --- 2011-11-12 13:17:29 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 13:17:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 13:17:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 13:17:29 - SRCCONF=/dev/null TB --- 2011-11-12 13:17:29 - TARGET=powerpc TB --- 2011-11-12 13:17:29 - TARGET_ARCH=powerpc TB --- 2011-11-12 13:17:29 - TZ=UTC TB --- 2011-11-12 13:17:29 - __MAKE_CONF=/dev/null TB --- 2011-11-12 13:17:29 - cd /src TB --- 2011-11-12 13:17:29 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 13:17:30 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 15:00:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 15:00:09 - ERROR: failed to build world TB --- 2011-11-12 15:00:09 - 4958.41 user 859.10 system 6184.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 15:56:32 2011 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 528E0106566B; Sat, 12 Nov 2011 15:56:32 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 191228FC0A; Sat, 12 Nov 2011 15:56:31 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pACFfaEl021589; Sat, 12 Nov 2011 10:41:36 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pACFfZN5021588; Sat, 12 Nov 2011 10:41:35 -0500 (EST) (envelope-from das@freebsd.org) Date: Sat, 12 Nov 2011 10:41:35 -0500 From: David Schultz To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org Message-ID: <20111112154135.GA21512@zim.MIT.EDU> Mail-Followup-To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111112102241.GA75396@vniz.net> Cc: Subject: Re: Is fork() hook ever possible? 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, 12 Nov 2011 15:56:32 -0000 On Sat, Nov 12, 2011, Andrey Chernov wrote: > On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > > secteam@ already agreed to the idea of solving the fork problem as > > in OpenBSD over a month ago. > > On Wed, Sep 17, 2008 at 12:50:25PM +0400, Andrey Chernov wrote: > > I agree with your patch (BTW you can remove unneded #define RANDOMDEV). > > The question remains: why you don't commit this patch all that 3 > years, having secteam@ and mine agreements too? Sorry, but in the three years that have intervened, my brain has paged out the relevant context. As I recall, there were issues with some of your changes to arc4random() and I proposed tracking OpenBSD's implementation more closely. If everyone's in agreement on that, please go ahead and commit the changes. On a related note, I recall that the biggest issue is that getpid() overhead now dominates the cost of arc4random(). The title of this thread suggests a simple solution! From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 16:07:07 2011 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 756A1106566B for ; Sat, 12 Nov 2011 16:07:07 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id EEF908FC0A for ; Sat, 12 Nov 2011 16:07:06 +0000 (UTC) Received: from [2a01:e35:2439:2440:290:f5ff:fe9d:b78c] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPG6i-000MwT-9u for freebsd-current@FreeBSD.org; Sat, 12 Nov 2011 17:07:06 +0100 Message-ID: <4EBE99A7.90500@FreeBSD.org> Date: Sat, 12 Nov 2011 17:07:03 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: undefined Content-Type: multipart/mixed; boundary="------------060601050805060900010805" Cc: Subject: [Call for reviews] Support domain-search option in dhclient(8) 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, 12 Nov 2011 16:07:07 -0000 This is a multi-part message in MIME format. --------------060601050805060900010805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Attached is a patch that adds support for "domain-search" option (#119) as defined in RFC 3397[1]. This allows a DHCP server to publish a list of domain names that should be used to search for non-fully qualified domain names. There's already a PR opened about this: http://www.freebsd.org/cgi/query-pr.cgi?pr=151940 With this patch applied and a DHCP server configured to publish this option, dhclient(8) will add a line similar to the following one: search example.org. foobar.com. In the example, this indicates that the name "www" should be resolved first as "www.example.org", then as "www.foobar.com". I prepared a regression test to be added to tools/regression (not included). However, I'm not knowledgeable enough to anticipate all security-related issues. I would appreciate a review especially with this in mind :) Thank you! [1] http://www.faqs.org/rfcs/rfc3397.html - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6+macACgkQa+xGJsFYOlMRBACghVQ62JSyt8/yGOsV9jE661W/ PRoAoMsZnSYLfVSzCqZhxbukrbP4bI4q =qEZg -----END PGP SIGNATURE----- --------------060601050805060900010805 Content-Type: text/plain; name="dhclient-domain-search-a.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dhclient-domain-search-a.patch" Index: sbin/dhclient/dhcp.h =================================================================== --- sbin/dhclient/dhcp.h (revision 227467) +++ sbin/dhclient/dhcp.h (working copy) @@ -169,6 +169,7 @@ #define DHO_STREETTALK_SERVER 75 #define DHO_STREETTALK_DA_SERVER 76 #define DHO_DHCP_USER_CLASS_ID 77 +#define DHO_DOMAIN_SEARCH 119 #define DHO_CLASSLESS_ROUTES 121 #define DHO_END 255 Index: sbin/dhclient/dhclient.c =================================================================== --- sbin/dhclient/dhclient.c (revision 227467) +++ sbin/dhclient/dhclient.c (working copy) @@ -2453,6 +2453,7 @@ case DHO_DHCP_CLIENT_IDENTIFIER: case DHO_BOOTFILE_NAME: case DHO_DHCP_USER_CLASS_ID: + case DHO_DOMAIN_SEARCH: case DHO_END: return (1); case DHO_CLASSLESS_ROUTES: Index: sbin/dhclient/tables.c =================================================================== --- sbin/dhclient/tables.c (revision 227467) +++ sbin/dhclient/tables.c (working copy) @@ -184,7 +184,7 @@ { "option-116", "X", &dhcp_universe, 116 }, { "option-117", "X", &dhcp_universe, 117 }, { "option-118", "X", &dhcp_universe, 118 }, - { "option-119", "X", &dhcp_universe, 119 }, + { "domain-search", "t", &dhcp_universe, 119 }, { "option-120", "X", &dhcp_universe, 120 }, { "classless-routes", "BA", &dhcp_universe, 121 }, { "option-122", "X", &dhcp_universe, 122 }, @@ -400,12 +400,13 @@ DHO_IRC_SERVER, DHO_STREETTALK_SERVER, DHO_STREETTALK_DA_SERVER, + DHO_DOMAIN_SEARCH, /* Presently-undefined options... */ 62, 63, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, - 118, 119, 120, 122, 123, 124, 125, 126, 127, 128, 129, 130, + 118, 120, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, Index: sbin/dhclient/clparse.c =================================================================== --- sbin/dhclient/clparse.c (revision 227467) +++ sbin/dhclient/clparse.c (working copy) @@ -100,6 +100,8 @@ DHO_DOMAIN_NAME_SERVERS; top_level_config.requested_options [top_level_config.requested_option_count++] = DHO_HOST_NAME; + top_level_config.requested_options + [top_level_config.requested_option_count++] = DHO_DOMAIN_SEARCH; if ((cfile = fopen(path_dhclient_conf, "r")) != NULL) { do { Index: sbin/dhclient/options.c =================================================================== --- sbin/dhclient/options.c (revision 227467) +++ sbin/dhclient/options.c (working copy) @@ -55,6 +55,10 @@ void parse_option_buffer(struct packet *, unsigned char *, int); int store_options(unsigned char *, int, struct tree_cache **, unsigned char *, int, int, int, int); +void expand_domain_search(struct packet *packet); +int find_search_domain_name_len(struct option_data *option, int *offset); +void expand_search_domain_name(struct option_data *option, int *offset, + unsigned char **domain_search); /* @@ -94,6 +98,11 @@ (unsigned char *)packet->raw->sname, sizeof(packet->raw->sname)); } + + /* Expand DHCP Domain Search option. */ + if (packet->options_valid) { + expand_domain_search(packet); + } } /* @@ -194,6 +203,163 @@ } /* + * Expand DHCP Domain Search option. The value of this option is + * encoded like DNS' list of labels. See: + * RFC 3397 + * RFC 1035 + */ +void +expand_domain_search(struct packet *packet) +{ + int offset, expanded_len; + struct option_data *option; + unsigned char *domain_search, *cursor; + + if (packet->options[DHO_DOMAIN_SEARCH].data == NULL) + return; + + option = &packet->options[DHO_DOMAIN_SEARCH]; + + /* Compute final expanded length. */ + expanded_len = 0; + offset = 0; + while (offset < option->len) { + /* We add 1 for the space between domain names. */ + expanded_len += + find_search_domain_name_len(option, &offset) + 1; + } + if (expanded_len > 0) + /* Remove 1 for the superfluous trailing space. */ + --expanded_len; + + domain_search = malloc(expanded_len + 1); + if (domain_search == NULL) + error("Can't allocate storage for expanded domain-search\n"); + + offset = 0; + cursor = domain_search; + while (offset < option->len) { + expand_search_domain_name(option, &offset, &cursor); + cursor[0] = ' '; + cursor++; + } + domain_search[expanded_len] = '\0'; + + free(option->data); + option->len = expanded_len; + option->data = domain_search; +} + +int +find_search_domain_name_len(struct option_data *option, int *offset) +{ + int domain_name_len, i, label_len, pointer, pointed_len; + + domain_name_len = 0; + + i = *offset; + while (i < option->len) { + label_len = option->data[i]; + if (label_len == 0) { + /* + * A zero-length label marks the end of this + * domain name. + */ + *offset = i + 1; + return (domain_name_len); + } else if (label_len & 0xC0) { + /* This is a pointer to another list of labels. */ + if (i + 1 >= option->len) { + /* The pointer is truncated. */ + error("Truncated pointer in DHCP Domain " + "Search option."); + } + + pointer = ((label_len & ~(0xC0)) << 8) + + option->data[i + 1]; + if (pointer >= *offset) { + /* + * The pointer must indicates a prior + * occurance. + */ + error("Invalid forward pointer in DHCP Domain " + "Search option compression."); + } + + pointed_len = find_search_domain_name_len(option, + &pointer); + domain_name_len += pointed_len; + + *offset = i + 2; + return (domain_name_len); + } + + if (i + label_len >= option->len) { + error("Truncated label in DHCP Domain Search option."); + } + + /* + * Update the domain name length with the length of the + * current label, plus a trailing dot ('.'). + */ + domain_name_len += label_len + 1; + + /* Move cursor. */ + i += label_len + 1; + } + + error("Truncated DHCP Domain Search option."); + + return (0); +} + +void +expand_search_domain_name(struct option_data *option, int *offset, + unsigned char **domain_search) +{ + int i, label_len, pointer; + unsigned char *cursor; + + /* + * This is the same loop than the function above + * (find_search_domain_name_len). Therefore, we remove checks, + * they're already done. Here, we just make the copy. + */ + i = *offset; + cursor = *domain_search; + while (i < option->len) { + label_len = option->data[i]; + if (label_len == 0) { + /* + * A zero-length label marks the end of this + * domain name. + */ + *offset = i + 1; + *domain_search = cursor; + return; + } else if (label_len & 0xC0) { + /* This is a pointer to another list of labels. */ + pointer = ((label_len & ~(0xC0)) << 8) + + option->data[i + 1]; + + expand_search_domain_name(option, &pointer, &cursor); + + *offset = i + 2; + *domain_search = cursor; + return; + } + + /* Copy the label found. */ + memcpy(cursor, option->data + i + 1, label_len); + cursor[label_len] = '.'; + + /* Move cursor. */ + i += label_len + 1; + cursor += label_len + 1; + } +} + +/* * cons options into a big buffer, and then split them out into the * three separate buffers if needed. This allows us to cons up a set of * vendor options using the same routine. --------------060601050805060900010805-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 16:56:31 2011 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 EFAC11065673; Sat, 12 Nov 2011 16:56:30 +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 A94238FC0A; Sat, 12 Nov 2011 16:56:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACGuTCh002618; Sat, 12 Nov 2011 11:56:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACGuT4B002617; Sat, 12 Nov 2011 16:56:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 16:56:29 GMT Message-Id: <201111121656.pACGuT4B002617@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 arm/arm 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, 12 Nov 2011 16:56:31 -0000 TB --- 2011-11-12 16:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 16:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-12 16:10:00 - cleaning the object tree TB --- 2011-11-12 16:10:17 - cvsupping the source tree TB --- 2011-11-12 16:10:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-12 16:10:32 - building world TB --- 2011-11-12 16:10:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 16:10:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 16:10:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 16:10:32 - SRCCONF=/dev/null TB --- 2011-11-12 16:10:32 - TARGET=arm TB --- 2011-11-12 16:10:32 - TARGET_ARCH=arm TB --- 2011-11-12 16:10:32 - TZ=UTC TB --- 2011-11-12 16:10:32 - __MAKE_CONF=/dev/null TB --- 2011-11-12 16:10:32 - cd /src TB --- 2011-11-12 16:10:32 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 16:10:33 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 16:56:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 16:56:29 - ERROR: failed to build world TB --- 2011-11-12 16:56:29 - 1971.11 user 602.91 system 2788.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 17:15:33 2011 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 E6113106566C; Sat, 12 Nov 2011 17:15:33 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5228FC13; Sat, 12 Nov 2011 17:15:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pACHFVXA083776; Sat, 12 Nov 2011 21:15:31 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pACHFVax083775; Sat, 12 Nov 2011 21:15:31 +0400 (MSK) (envelope-from ache) Date: Sat, 12 Nov 2011 21:15:31 +0400 From: Andrey Chernov To: current@freebsd.org, secteam@freebsd.org Message-ID: <20111112171531.GA83419@vniz.net> Mail-Followup-To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org, das@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111112154135.GA21512@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: das@freebsd.org Subject: Re: Is fork() hook ever possible? 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, 12 Nov 2011 17:15:34 -0000 On Sat, Nov 12, 2011 at 10:41:35AM -0500, David Schultz wrote: > On Sat, Nov 12, 2011, Andrey Chernov wrote: > > On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > > > secteam@ already agreed to the idea of solving the fork problem as > > > in OpenBSD over a month ago. > > > > On Wed, Sep 17, 2008 at 12:50:25PM +0400, Andrey Chernov wrote: > > > I agree with your patch (BTW you can remove unneded #define RANDOMDEV). > > > > The question remains: why you don't commit this patch all that 3 > > years, having secteam@ and mine agreements too? > > Sorry, but in the three years that have intervened, my brain has > paged out the relevant context. As I recall, there were issues > with some of your changes to arc4random() and I proposed tracking > OpenBSD's implementation more closely. I can't say for secteam@ side (it was you who said that they agree), but personally me still agree with your proposal and still see security problem in our current implementation, like the same-generated tmp names after fork in son and parent. > If everyone's in agreement on that, please go ahead and commit the changes. I can't... It seems I reach dead end talking to our @secteam. In few words, they: 1) Explicitly disallow my commits in all 'random' areas until their review. 2) They never do that review (I must to mention again that 3 years passed since they promise it). Being particular, I suggest them to use your patch at the end. Nothing happens. Hope you'll get more luck with them committing it by yourself. > On a related note, I recall that the biggest issue is that > getpid() overhead now dominates the cost of arc4random(). > The title of this thread suggests a simple solution! I initially thinking about making fork hook which will change arc4random reinit variable. You express just opposite opinion those times: On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > If getpid() really winds up being a serious problem, we can solve > it in a principled way, e.g., by having the kernel fault in a > read-only page containing the current process pid, and having > libc's getpid() read it. I know Windows has a facility like this > that they use for a number of things, and ISTR that Linux recently > introduced one, too. The bottom line is that we shouldn't solve > the problem with hacks in arc4random(), and we shouldn't try to > solve it at all until it's proven to be a real problem. I run some tests but can't come to conclusion, is overhead is significant or not for real life tasks (which usually don't call arc4random() very often in the loop). -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 17:55:17 2011 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 241631065674 for ; Sat, 12 Nov 2011 17:55:17 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id D9F658FC0A for ; Sat, 12 Nov 2011 17:55:16 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RPHnR-000O97-Aa; Sat, 12 Nov 2011 18:55:17 +0100 Date: Sat, 12 Nov 2011 18:55:17 +0100 From: Kurt Jaeger To: Alexander Yerenkow Message-ID: <20111112175517.GG68080@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: KMS testing, intel only 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, 12 Nov 2011 17:55:17 -0000 Hi! > Before I begin, I appreciate any help/comments/criticism. Please, don't > hesitate to support this topic. Comment: This is briliant! Thank you very much! I tested it on an Lenovo ThinkPad X121e, which has Intel GMA: vgapci0@pci0:0:2:0: class=0x030000 card=0x21ed17aa chip=0x01168086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xd0000000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xc0000000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0x4000, size 64, enabled xdpyinfo says: screen #0: dimensions: 1366x768 pixels (361x203 millimeters) which did not work with the normal xorg before. Very nice! > After you boot, login with root. > First, you can try just launch > ./runx.sh Everything works fine. stellarium is very nice 8-) -- pi@opsec.eu +49 171 3101372 9 years to go ! From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 18:06:37 2011 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 EF3E21065670; Sat, 12 Nov 2011 18:06: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 A34138FC13; Sat, 12 Nov 2011 18:06:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACI6Zin077906; Sat, 12 Nov 2011 13:06:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACI6Z6U077891; Sat, 12 Nov 2011 18:06:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 18:06:35 GMT Message-Id: <201111121806.pACI6Z6U077891@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/i386 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, 12 Nov 2011 18:06:37 -0000 TB --- 2011-11-12 16:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 16:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-12 16:10:00 - cleaning the object tree TB --- 2011-11-12 16:10:17 - cvsupping the source tree TB --- 2011-11-12 16:10:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-12 16:10:32 - building world TB --- 2011-11-12 16:10:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 16:10:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 16:10:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 16:10:32 - SRCCONF=/dev/null TB --- 2011-11-12 16:10:32 - TARGET=i386 TB --- 2011-11-12 16:10:32 - TARGET_ARCH=i386 TB --- 2011-11-12 16:10:32 - TZ=UTC TB --- 2011-11-12 16:10:32 - __MAKE_CONF=/dev/null TB --- 2011-11-12 16:10:32 - cd /src TB --- 2011-11-12 16:10:32 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 16:10:33 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 18:06:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 18:06:35 - ERROR: failed to build world TB --- 2011-11-12 18:06:35 - 5682.21 user 937.89 system 6994.54 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 18:06:38 2011 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 76E9A106564A; Sat, 12 Nov 2011 18:06:38 +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 31DFB8FC15; Sat, 12 Nov 2011 18:06:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACI6afc077993; Sat, 12 Nov 2011 13:06:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACI6aGN077990; Sat, 12 Nov 2011 18:06:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 18:06:36 GMT Message-Id: <201111121806.pACI6aGN077990@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: Sat, 12 Nov 2011 18:06:38 -0000 TB --- 2011-11-12 16:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 16:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-12 16:10:00 - cleaning the object tree TB --- 2011-11-12 16:10:17 - cvsupping the source tree TB --- 2011-11-12 16:10:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-12 16:10:32 - building world TB --- 2011-11-12 16:10:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 16:10:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 16:10:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 16:10:32 - SRCCONF=/dev/null TB --- 2011-11-12 16:10:32 - TARGET=pc98 TB --- 2011-11-12 16:10:32 - TARGET_ARCH=i386 TB --- 2011-11-12 16:10:32 - TZ=UTC TB --- 2011-11-12 16:10:32 - __MAKE_CONF=/dev/null TB --- 2011-11-12 16:10:32 - cd /src TB --- 2011-11-12 16:10:32 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 16:10:33 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 18:06:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 18:06:36 - ERROR: failed to build world TB --- 2011-11-12 18:06:36 - 5681.89 user 954.62 system 6995.85 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 18:57:19 2011 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 053BF1065673; Sat, 12 Nov 2011 18:57:19 +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 B4B248FC0A; Sat, 12 Nov 2011 18:57:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACIvH68077635; Sat, 12 Nov 2011 13:57:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACIvHP3077599; Sat, 12 Nov 2011 18:57:17 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 18:57:17 GMT Message-Id: <201111121857.pACIvHP3077599@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 mips/mips 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, 12 Nov 2011 18:57:19 -0000 TB --- 2011-11-12 18:06:36 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 18:06:36 - starting HEAD tinderbox run for mips/mips TB --- 2011-11-12 18:06:36 - cleaning the object tree TB --- 2011-11-12 18:06:45 - cvsupping the source tree TB --- 2011-11-12 18:06:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-11-12 18:07:31 - building world TB --- 2011-11-12 18:07:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 18:07:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 18:07:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 18:07:31 - SRCCONF=/dev/null TB --- 2011-11-12 18:07:31 - TARGET=mips TB --- 2011-11-12 18:07:31 - TARGET_ARCH=mips TB --- 2011-11-12 18:07:31 - TZ=UTC TB --- 2011-11-12 18:07:31 - __MAKE_CONF=/dev/null TB --- 2011-11-12 18:07:31 - cd /src TB --- 2011-11-12 18:07:31 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 18:07:32 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O -pipe -G0 -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O -pipe -G0 -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 18:57:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 18:57:17 - ERROR: failed to build world TB --- 2011-11-12 18:57:17 - 2146.34 user 601.64 system 3041.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 19:57:03 2011 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 1EBB1106564A; Sat, 12 Nov 2011 19:57:03 +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 C61068FC0A; Sat, 12 Nov 2011 19:57:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pACJv1lp064789; Sat, 12 Nov 2011 14:57:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pACJv18v064747; Sat, 12 Nov 2011 19:57:01 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Nov 2011 19:57:01 GMT Message-Id: <201111121957.pACJv18v064747@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, 12 Nov 2011 19:57:03 -0000 TB --- 2011-11-12 18:06:36 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 18:06:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-12 18:06:36 - cleaning the object tree TB --- 2011-11-12 18:06:46 - cvsupping the source tree TB --- 2011-11-12 18:06:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-12 18:07:31 - building world TB --- 2011-11-12 18:07:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 18:07:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 18:07:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 18:07:31 - SRCCONF=/dev/null TB --- 2011-11-12 18:07:31 - TARGET=powerpc TB --- 2011-11-12 18:07:31 - TARGET_ARCH=powerpc TB --- 2011-11-12 18:07:31 - TZ=UTC TB --- 2011-11-12 18:07:31 - __MAKE_CONF=/dev/null TB --- 2011-11-12 18:07:31 - cd /src TB --- 2011-11-12 18:07:31 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 18:07:32 UTC 2011 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/mountver/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/mountver/../../misc/subr.c -o subr.So building shared library geom_mountver.so gzip -cn /src/sbin/geom/class/mountver/gmountver.8 > gmountver.8.gz ===> sbin/geom/class/multipath (all) cc -fpic -DPIC -O2 -pipe -I/src/sbin/geom/class/multipath/../../../../sys -I/src/sbin/geom/class/multipath/../.. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/geom/class/multipath/geom_multipath.c -o geom_multipath.So cc1: warnings being treated as errors /src/sbin/geom/class/multipath/geom_multipath.c: In function 'mp_label': /src/sbin/geom/class/multipath/geom_multipath.c:243: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/sbin/geom/class/multipath. *** Error code 1 Stop in /src/sbin/geom/class. *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-12 19:57:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-12 19:57:01 - ERROR: failed to build world TB --- 2011-11-12 19:57:01 - 5313.04 user 906.64 system 6624.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 20:02:09 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id ACFCC106567A; Sat, 12 Nov 2011 20:02:09 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9AC0E162E4F; Sat, 12 Nov 2011 20:01:50 +0000 (UTC) Message-ID: <4EBED0A5.5070308@FreeBSD.org> Date: Sun, 13 Nov 2011 00:01:41 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= References: <4EBE99A7.90500@FreeBSD.org> In-Reply-To: <4EBE99A7.90500@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE876C3E72FB118AE8A16683C" Cc: freebsd-current@FreeBSD.org Subject: Re: [Call for reviews] Support domain-search option in dhclient(8) 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, 12 Nov 2011 20:02:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE876C3E72FB118AE8A16683C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12.11.2011 20:07, Jean-S=C3=A9bastien P=C3=A9dron wrote: > Attached is a patch that adds support for "domain-search" option > (#119) as defined in RFC 3397[1]. This allows a DHCP server to publish > a list of domain names that should be used to search for non-fully > qualified domain names. >=20 > There's already a PR opened about this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D151940 >=20 > With this patch applied and a DHCP server configured to publish this > option, dhclient(8) will add a line similar to the following one: > search example.org. foobar.com. >=20 > In the example, this indicates that the name "www" should be resolved > first as "www.example.org", then as "www.foobar.com". >=20 > I prepared a regression test to be added to tools/regression (not > included). However, I'm not knowledgeable enough to anticipate all > security-related issues. I would appreciate a review especially with > this in mind :) Hi, I have several questions after a quick view of your patch: 1. AFAIR, our dhclient was doing changes in the system configuration via dhclient-script, but i don't see that your changes touched it. 2. Your code handles compressed options. It's good. But it seems you don't check names correctness. There were some checks for "domain-name" option, probably you can use them. 3. Also it would be good to update man pages :) --=20 WBR, Andrey V. Elsukov --------------enigE876C3E72FB118AE8A16683C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOvtCqAAoJEAHF6gQQyKF6cvYH/3yQjZQO9UdMmBchPal3t80c qhco1LTTtNIcwA019PzoJh614S5ytLRsWVGjLOJJbDS35w+AoPPmTX4iFlulF8bi Iy4VPGiowaOAavazppGMAzR7TSFY4xqjk2H8Feh5UBJe6MXyksggrscF0yaOvIlt wggqXM3TsEZhL6GNHIZobdVPNdYDg+GGDeO2707fANEPsO8mVz8FAY5IEKEs3jXU w+lLjmI6t5kX6byhY1XGF+BKudBzs4TGiQzWPBSseV1LAoy0VFIoJmMB4pN8Cnjh jflUxBi/dvM7hfwMyZxZff35xuD2CeM7tO6dxkUx5eOx0kLXUNYe2kqHMILd2S4= =mRTL -----END PGP SIGNATURE----- --------------enigE876C3E72FB118AE8A16683C-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 20:11:34 2011 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 CF6C31065677 for ; Sat, 12 Nov 2011 20:11:34 +0000 (UTC) (envelope-from yerenkow@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 909AC8FC08 for ; Sat, 12 Nov 2011 20:11:34 +0000 (UTC) Received: by yenl11 with SMTP id l11so55604yen.13 for ; Sat, 12 Nov 2011 12:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sU531PE7xcFyuhXdSF4m6hy/jl01W77Bsmt05mJqfwc=; b=Ku6JuFClxU0lUNz4ZH7WdUCCyVZFPts83NjVnLI9bq7GTw3CZzh2IBs+iWGlp0PCLg jjT6k/n3iLMSo2EA6tGFZDYXdM/0Nc6EK0eQF+/i0Qjvle+4W3lsllbQHaLyFIjEAR5I Fj0jel6zskWGWTyvQir1GQL9SW5TIvW6vSEv0= MIME-Version: 1.0 Received: by 10.236.80.98 with SMTP id j62mr4922029yhe.39.1321128693809; Sat, 12 Nov 2011 12:11:33 -0800 (PST) Received: by 10.151.44.17 with HTTP; Sat, 12 Nov 2011 12:11:33 -0800 (PST) In-Reply-To: References: Date: Sat, 12 Nov 2011 22:11:33 +0200 Message-ID: From: Alexander Yerenkow To: Davide Italiano Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: KMS testing, intel only 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, 12 Nov 2011 20:11:34 -0000 >Thanks. Do you think you'll provide amd64 version of that img as well? I'm working currently on fully automatizing this process, and it mostly done. But, I got now FreeBSD-9-kms-i386-r227450-2011-11-12.img and... it seems not seeing none of my two intel cards. :( Well, or I did broke something, or some commit did broke everything, can't say yet. I'm going build now amd64 version as well, will see if it will work. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 20:16:38 2011 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 323161065686 for ; Sat, 12 Nov 2011 20:16:38 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD71D8FC12 for ; Sat, 12 Nov 2011 20:16:37 +0000 (UTC) Received: by vws11 with SMTP id 11so6235400vws.13 for ; Sat, 12 Nov 2011 12:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Me/4Q+dIUCYXiC2kcmUY8Pc6hXiyLMjfglIxMaFlKsI=; b=KjeEg7uARMbBZrFJ0yrblqRNOufTfDhNDuvym0RrV+/8FTY3dh7E87t85EbEoryMtk VDhvocDtJINWmns+osZrXbMLHbzet+np50rJilUdwSGAxDrivdaluj+dqA1ghrbBqqmY yYhOtFakcy/Y1wuIl1QPWxsctcvLp+TUM/pMo= MIME-Version: 1.0 Received: by 10.52.23.115 with SMTP id l19mr25808298vdf.51.1321127390408; Sat, 12 Nov 2011 11:49:50 -0800 (PST) Received: by 10.52.156.135 with HTTP; Sat, 12 Nov 2011 11:49:50 -0800 (PST) In-Reply-To: References: Date: Sat, 12 Nov 2011 20:49:50 +0100 Message-ID: From: Davide Italiano To: Alexander Yerenkow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: KMS testing, intel only 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, 12 Nov 2011 20:16:38 -0000 On Fri, Nov 11, 2011 at 4:14 PM, Alexander Yerenkow wr= ote: > Hello all. > Before I begin, I appreciate any help/comments/criticism. Please, don't > hesitate to support this topic. > > Some time ago I've announced new project - of creating rolling images of > FreeBSD from SVN. > Along with plain standard ones (plain world+kernel install of bare system= ) > I'm working on creating specific images. > Like with preset installed packages (kde-set, gnome-set, etc.), like with > some patches (area51/kde-wip/kms) etc. > So, I did not fully automated (yet) creating of this one image, but you > already can grab it to test: > > http://gits.kiev.ua/FreeBSD/FreeBSD-9-kms-i386-r227337-2011-11-10.img.xz > > I'm sure you find filename fully descriptive :) > What can be done with this image (after unpacking): > dd if=3Dthis.img of=3Dyour-usb bs=3D64M > and simply boot from your usb. > > After you boot, login with root. > First, you can try just launch > ./runx.sh > It will use /root/xorg.conf, create few log files (probably useful ones) = in > /root and launch two xterms and openbox for WM. > How you can test graphics: > 1. glxgears/glxinfo - it's not a benchmar, as you may know :) > 2. blender - extensive graphics usage > 3. stellarium - also =A0extensive graphics usage > 4. seamonkey (which starts for about 2-3 minutes in absence of internet) = - > can be used to immediately send feedback and/or log files. > > Please, note that switching to tty not working; after you finish with > playing KMS you simply shutdown system. > If you had some troubles, you always can reboot and edit /root/xorg.conf > before launch X. Before each X start copy of xorg are creating, so you ca= n > make some tests and find difference between files, not worrying for > backuping/storing configs. > > Misc notes: > there is a script exist: > /root/addpackage.sh > to make life easier if you want to test some other software (remotely > installs packages, e.g. ./ =A0addpackage.sh =A0firefox will get you firef= ox. > maybe.) > Also, on image about 1G free space, so you can install something even big= , > to try it. > Also, on image pretty fresh ports tree present, with applied xorg-dev > patch, you can play with ports too. > > Full package list: > OpenEXR-1.6.1_3 > aalib-1.4.r5_6 > atk-2.0.1 > autoconf-2.68 > autoconf-wrapper-20101119 > automake-1.11.1 > automake-wrapper-20101119 > bigreqsproto-1.1.1 > bison-2.4.3,1 > bitstream-vera-1.10_5 > blender-2.60 > ca_root_nss-3.12.11_1 > cairo-1.10.2_2,1 > compositeproto-0.4.2 > consolekit-0.4.3 > cups-client-1.5.0 > damageproto-1.2.1 > dbus-1.4.14_1 > dbus-glib-0.94 > desktop-file-utils-0.18 > dmidecode-2.11 > dri-7.11,2 > dri2proto-2.6 > eggdbus-0.6_1 > encodings-1.0.4,1 > evieext-1.1.1 > expat-2.0.1_2 > ffmpeg-0.7.6,1 > fftw3-3.3_1 > fixesproto-5.0 > flac-1.2.1_2 > flex-2.5.35_4 > font-bh-ttf-1.0.3 > font-misc-ethiopic-1.0.3 > font-misc-meltho-1.0.3 > font-util-1.2.0 > fontconfig-2.8.0_1,1 > fontsproto-2.1.1 > freealut-1.1.0_2 > freetype2-2.4.7 > gamin-0.1.10_4 > gdk-pixbuf-2.23.5_1 > gettext-0.18.1.1 > gio-fam-backend-2.28.8 > glew-1.7.0 > glib-2.28.8_2 > glproto-1.4.14 > gmake-3.82 > gnome_subr-1.0 > gobject-introspection-0.10.8 > gpac-libgpac-0.4.5_4,1 > gtk-2.24.6 > gtk-update-icon-cache-2.24.6 > hal-0.5.14_17 > hicolor-icon-theme-0.12 > ilmbase-1.0.1_1 > inputproto-2.0.2 > intltool-0.41.1 > jasper-1.900.1_9 > jbigkit-1.6 > jpeg-8_3 > kbproto-1.0.5 > libGL-7.11 > libGLU-7.4.4 > libICE-1.0.7,1 > libIDL-0.8.14_1 > libSM-1.2.0,1 > libX11-1.4.4,1 > libXau-1.0.6 > libXaw-1.0.9,1 > libXcomposite-0.4.3,1 > libXcursor-1.1.12 > libXdamage-1.1.3 > libXdmcp-1.1.0 > libXext-1.3.0_1,1 > libXfixes-5.0 > libXfont-1.4.4,1 > libXft-2.1.14 > libXi-1.4.3,1 > libXinerama-1.1.1,1 > libXmu-1.1.0,1 > libXp-1.0.1,1 > libXpm-3.5.9 > libXrandr-1.3.2 > libXrender-0.9.6 > libXt-1.1.1 > libXv-1.0.6,1 > libXvMC-1.0.6 > libXxf86misc-1.0.3 > libXxf86vm-1.1.1 > libdrm-2.4.27 > libevent-1.4.14b_2 > libexecinfo-1.1_3 > libffi-3.0.9 > libfontenc-1.1.0 > libgcrypt-1.5.0 > libglut-7.4.4 > libgpg-error-1.10 > libiconv-1.13.1_1 > libnotify-0.7.3_1 > libogg-1.2.2,4 > libpciaccess-0.12.1 > libpthread-stubs-0.3_3 > libsamplerate-0.1.8_2 > libsndfile-1.0.25 > libtheora-1.1.1_2 > libtool-2.4_1 > libvolume_id-0.81.1 > libvorbis-1.3.2,3 > libvpx-0.9.7 > libxcb-1.7 > libxkbfile-1.0.7 > libxkbui-1.0.2_1 > libxml2-2.7.8_1 > libxslt-1.1.26_3 > luit-1.1.0 > m4-1.4.16,1 > makedepend-1.0.3,1 > mesa-demos-7.4.4 > mkfontdir-1.0.6 > mkfontscale-1.0.9 > nspr-4.8.9 > openal-soft-1.13 > openbox-3.5.0 > opencv-core-2.3.1_1 > openjpeg-1.3_2 > orc-0.4.14_1 > p5-XML-Parser-2.41 > pango-1.28.4 > pciids-20111002 > pcre-8.20 > perl-5.12.4_2 > pixman-0.24.0 > pkg-config-0.25_1 > png-1.4.8 > policykit-0.9_6 > polkit-0.99 > portmaster-3.10 > printproto-1.0.5 > py27-libxml2-2.7.8_1 > python27-2.7.2_3 > python32-3.2.2_1 > qt4-corelib-4.7.4 > qt4-gui-4.7.4 > qt4-network-4.7.4 > qt4-opengl-4.7.4 > qt4-script-4.7.4 > randrproto-1.3.2 > recordproto-1.14.1 > renderproto-0.11.1 > resourceproto-1.2.0 > schroedinger-1.0.10 > scrnsaverproto-1.2.1 > sdl-1.2.14_2,2 > seamonkey-2.4.1 > shared-mime-info-0.90 > stellarium-0.11.0 > tiff-4.0.0_2 > trapproto-3.4.3 > videoproto-2.3.1 > x264-0.116.2076 > xcb-util-0.3.6_1 > xcmiscproto-1.2.1 > xdg-utils-1.0.2_5 > xextproto-7.2.0 > xeyes-1.1.1 > xf86-input-keyboard-1.6.0 > xf86-input-mouse-1.7.1 > xf86-video-intel-2.16.0 > xf86bigfontproto-1.2.0 > xf86dgaproto-2.1 > xf86driproto-2.1.1 > xf86miscproto-0.9.3 > xf86vidmodeproto-2.3.1 > xineramaproto-1.2.1 > xkbcomp-1.2.3 > xkeyboard-config-2.4.1 > xorg-fonts-truetype-7.5.1 > xorg-macros-1.15.0 > xorg-server-1.10.4_1,1 > xproto-7.0.22 > xterm-276 > xtrans-1.2.6 > xvid-1.3.2,1 > zip-3.0 > > > -- > Regards, > Alexander Yerenkow > _______________________________________________ > 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= " > Thanks. Do you think you'll provide amd64 version of that img as well? Davide