From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 00:49:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A9C5522 for ; Sun, 7 Jul 2013 00:49:28 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1922A1B19 for ; Sun, 7 Jul 2013 00:49:28 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id ef5so4286232obb.15 for ; Sat, 06 Jul 2013 17:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=R8WxyX+gZghjHuBpDMhGo+YquLlg775NW31I8q1D3Xk=; b=hgSRZ0SuwaixFnVWe3Y+7y8hN3hJHE0qGuiQ1+TUWvnmIwpARokU4saZ3+ejMJNVlq uTrpwB55dhHv4OyEdVCOrSHRKOl+ohKdz3jx7jRb7uprUDQmcWi5tEv9o/D7gLkIoZ+u g5c5d7UyF3C3zj976Cw9v2MWyk+dKhCNyxsFxhfCJnd5lfRgYL8Wwc463hCybO0X9PQE Aa9m3zSMqk82ZtGxMe78zVu17ozFOw5NXg7UFsOhLc5lpe5DKOictGp1jhB/6/9nUt6O DdEB4n0qeOo9/lz8RTaTNRqlyAON2/qCLeTQX0J82jy+Uq4FlE3zArLNWn5SZA3adYhB 7SQQ== MIME-Version: 1.0 X-Received: by 10.182.50.200 with SMTP id e8mr16438826obo.35.1373158167531; Sat, 06 Jul 2013 17:49:27 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Sat, 6 Jul 2013 17:49:27 -0700 (PDT) In-Reply-To: <51D86927.5090907@d2ux.net> References: <51D86927.5090907@d2ux.net> Date: Sat, 6 Jul 2013 17:49:27 -0700 X-Google-Sender-Auth: 0Ih8f_A8LBRFlJX5lYLHJx0fjtA Message-ID: Subject: Re: ACPI Lenovo X121e (Model 3045-79G, i3, HD3000) Suspend and LCD Brightness From: Kevin Oberman To: Matthias Petermann Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 00:49:28 -0000 On Sat, Jul 6, 2013 at 11:59 AM, Matthias Petermann wrote: > Hello, > > on a Lenovo X121e (Model 3045-79G, i3, HD3000) I try FreeBSD since 9.1. > Wifi, LAN, Audio, USB peripherials and Video (with KMS patch) just working > fine. Anyway, there are some open items: > > * LCD brightness control doesn't work > * Suspend to RAM (S3) doesn't restore video after resume > > That's why I upgraded my system to 10.0-CURRENT and looked in more detail > at it: > > root@thinkpad:/usr/home/**mpeterma # uname -a > FreeBSD thinkpad.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r252853: Sat > Jul 6 02:01:48 CEST 2013 root@thinkpad.local:/usr/obj/**usr/src/sys/GENERIC > amd64 > > # LCD Brightness > > First, on LCD brightness: The X121e is expected to increase/decrease LCD > brightness by Fn+F9/Fn+F8. This is not working right now. So I tried the > following: > > ## Attempts > > ### acpi_video / sysctl hw.acpi.video.lcd0.brightness > > This is what is working on most of the other laptops I tried it. > > root@thinkpad:/usr/home/**mpeterma # kldload acpi_video > acpi_video0: on vgapci0 > root@thinkpad:/usr/home/**mpeterma # sysctl -a |grep bright > hw.acpi.video.lcd0.brightness: 35 > root@thinkpad:/usr/home/**mpeterma # sysctl > hw.acpi.video.lcd0.brightness=**100 > hw.acpi.video.lcd0.brightness: 35 -> 100 > > Result: LCD brightness doesn't change after sysctl call, Fn+F9/Fn+F8 not > working. > > ### acpi_ibm / sysctl dev.acpi_ibm.0.lcd_brightness > > This is what worked on some older Thinkpads. > > root@thinkpad:/usr/home/**mpeterma # kldload acpi_ibm > acpi_ibm0: on acpi0 > root@thinkpad:/usr/home/**mpeterma # sysctl -a | grep bright > hw.acpi.video.lcd0.brightness: 90 > dev.acpi_ibm.0.lcd_brightness: 7 > root@thinkpad:/usr/home/**mpeterma # > root@thinkpad:/usr/home/**mpeterma # sysctl > dev.acpi_ibm.0.lcd_brightness=**1 > dev.acpi_ibm.0.lcd_brightness: 7 -> 1 > > Result: LCD brightness doesn't change after sysctl, Fn+F9/Fn+F8 still not > working. > > ### Activate sysctl dev.acpi_ibm.0.events > > root@thinkpad:/usr/home/**mpeterma # sysctl -a | grep > dev.acpi_ibm.0.availmask > dev.acpi_ibm.0.availmask: 67733756 > root@thinkpad:/usr/home/**mpeterma # sysctl dev.acpi_ibm.0.events=1 > dev.acpi_ibm.0.events: 0 -> 1 > root@thinkpad:/usr/home/**mpeterma # sysctl > dev.acpi_ibm.0.handlerevents='**0x03 0x04 0x10 0x11' > > Result: Fn+F9/Fn+F8 still not working. > > ### Direct ACPI calls with acpi_call > > root@thinkpad:/usr/home/**mpeterma # cd /usr/ports/sysutils/acpi_call/ > root@thinkpad:/usr/ports/**sysutils/acpi_call # make install clean > root@thinkpad:/usr/ports/**sysutils/acpi_call # kldload acpi_call > > root@thinkpad:/usr/ports/**sysutils/acpi_call # acpi_call -p '\VBRU' > root@thinkpad:/usr/ports/**sysutils/acpi_call # acpi_call -p '\VBRD' > > Result: on each acpi_call, \VBRU increases and \VBRD decreases LCD > brightness by one step. > Fn+F9/Fn+F8 still not working. > > ## Summary > > Direct ACPI calls are sufficient as workaround. I would like to support a > real solution. What are the next steps to find out what is wrong here? I > think a solution for this problem will help not just X121e users but any > user of more recent thinkpads. I saw similiar postings for X230 and X220. > > # Suspend to RAM > > The following observations I made without the i915 KMS module loaded (in > console mode). > > ## Attempts > > ### Supported Sleep states as reported by sysctl > > root@thinkpad:/usr/home/**mpeterma # sysctl -a |grep supported > hw.acpi.supported_sleep_state: S3 S4 S5 > > ### S3, hw.acpi.reset_video=0 > > root@thinkpad:/usr/home/**mpeterma # sysctl hw.acpi.reset_video=0 > hw.acpi.reset_video: 0 -> 0 > root@thinkpad:/usr/home/**mpeterma # acpiconf -s 3 > > Result: System suspends, no video after resume, black screen > > ### S3, hw.acpi.reset_video=1 > > root@thinkpad:/usr/home/**mpeterma # sysctl hw.acpi.reset_video=1 > hw.acpi.reset_video: 0 -> 1 > root@thinkpad:/usr/home/**mpeterma # acpiconf -s 3 > > Result: system reboots immediately > > ## Adding more debug output > > In ACPI Debugging guide it is recommended to recompile the ACPI module > with additional debug mode. > Anyway, when I try so, I get a warning: > > root@thinkpad:/home/mpeterma # cd /sys/modules/acpi/acpi > root@thinkpad:/sys/modules/**acpi/acpi # make clean > make: "/usr/src/sys/modules/acpi/**acpi/Makefile" line 4: "The ACPI > module is deprecated, set FORCE_BUILD to force it" > root@thinkpad:/sys/modules/**acpi/acpi # > > Is this still the way to go, or doesn't the guide reflect the state of > FreeBSD 10? > > # Detail information to X121e > > I uploaded the following details regarding the X121e: > > * dmesg > * ACPI ASL > * Sysctl ACPI keys > > to: *https://d2ux.org/owncloud/**public.php?service=files&t=** > 7022f90cea5e48da7fa65806c0d660**91* > > > Any help is welcome. Please let me know when I can provide more details / > testing. > > Kind regards, > Matthias > Can't help with suspend/resume, but I can point you to the brightness solution. This is probably the same issue that impacts most recent Lenovo laptops. If so, there is a fix in the thread titled "Fixing X220 Video The Right Way" on this (acpi@) mailing list with the patch by jhb on Feb. 28, but be usre to a followup message on using the fix posted on June 14. It' a tricky issue with getting a string with quoted characters parsed correctly. There have been a number of discussions on ThinkPad suspend/resume, but I have not seen a reliable fix. (I can't resume mine at this time, though it suspends fine :-) -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 02:40:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD48938C for ; Sun, 7 Jul 2013 02:40:06 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 7C14D1D1E for ; Sun, 7 Jul 2013 02:40:06 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id f4so4890941oah.21 for ; Sat, 06 Jul 2013 19:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KT1vdeYApNJUBfaYksGKco0qu2TaHHDw9Vrngo5ceVE=; b=WaeqrqW2fthtUR5p+8EAmciebJngI+xI/Abl7xnx/yAsORFX16uM1Q3b3pjrivAkwl /WxMREUXPbMWCETuL4TqjqGk9UnOJ9FYI+56fbryWgL+TOaJco/npAEExHMtEUPyw6Yu QxrE/EmtUcr/qaJnmI9DmjSSI6OeRT0ik2WpmHVlek22x4r2DUrUN9KYJwYONAozFR0k ViwV6sIrK2dqj+eUtDk9VHo3WkyfyCile7Fwm1hq/STCB78rVH0skmLpkqVOY2DuqF1Z BIwl4i6QA+0q563RbE4R5rNkIBorgUN+HrO7jxts3QfsTRCZicSA0/L+QX/e5tAvPN4r M8MA== MIME-Version: 1.0 X-Received: by 10.182.237.107 with SMTP id vb11mr16472927obc.84.1373164806062; Sat, 06 Jul 2013 19:40:06 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Sat, 6 Jul 2013 19:40:06 -0700 (PDT) In-Reply-To: <20130706081402.313c9e00@X220.ovitrap.com> References: <20130706081402.313c9e00@X220.ovitrap.com> Date: Sat, 6 Jul 2013 22:40:06 -0400 Message-ID: Subject: Re: Crashes with current on X220 From: Super Bisquit To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 02:40:06 -0000 Look in the mailing list for "Fixing X220 Video the right way." On Fri, Jul 5, 2013 at 8:14 PM, Erich Dollansky wrote: > Hi, > > I updated my rock solid FreeBSD 10 installation from what was current > this January to > > FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: > Wed Jul 3 08:45:23 CIT 2013 > root@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 > > I have since then frequent crashes. Nothing is seen on the screen. The > mouse does not move, the caps lock key does not switch the light. I have > restarted the machine last evening without doing anything else. No X, > just plain FreeBSD before logging on. The machine might has done a > fsck. The machine was frozen this morning. > > Does anybody else has this experience too? > > Erich > _______________________________________________ > 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 Sun Jul 7 04:20:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B597EFBC for ; Sun, 7 Jul 2013 04:20:44 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 8B43A1030 for ; Sun, 7 Jul 2013 04:20:44 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kx10so3313154pab.13 for ; Sat, 06 Jul 2013 21:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=hWROV1iOTJ/hJJST1WoHKdG/SphoWoh4sBD5K6TNZ+E=; b=HHA8FFLLeBhzW5qg7bzMh040DMY/wiax9ZIYglmqyBolFvVLnSfRy5pOOnJyN86Jdn 5PTZrURhc7DKogRcQBZxRaOphRQaG72CdGpof7pdHL1XQjKFndQ0b7Eqh80p318oh+8S Cm4g5lc/JKNQ3IL3AWc6gn0GI5X3OLD/0A2mdOutwNsEFHnlGFrf7RFDoqU9d+KI74Og HfJt9ReVO5n7s6OT72Osx7/EpWdE0h8u9ApaF7ZQihAvNW5WPH9oyxuWlrHGIRwUZCCx niARxwQe2kEDxPTDcZccUK6y/cjcWeotbpaeBL5joQKIdEbAABhI93OjCref8FTWXpEE S8gg== X-Received: by 10.66.142.5 with SMTP id rs5mr10056754pab.168.1373170843170; Sat, 06 Jul 2013 21:20:43 -0700 (PDT) Received: from flatline.sfrsys.com (c-67-161-25-189.hsd1.ca.comcast.net. [67.161.25.189]) by mx.google.com with ESMTPSA id aj3sm16433354pad.8.2013.07.06.21.20.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 21:20:42 -0700 (PDT) Message-ID: <51D8EC73.6080100@gmail.com> Date: Sat, 06 Jul 2013 21:20:03 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Super Bisquit Subject: Re: Crashes with current on X220 References: <20130706081402.313c9e00@X220.ovitrap.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Erich Dollansky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 04:20:44 -0000 On 07/06/13 19:40, Super Bisquit wrote: > Look in the mailing list for "Fixing X220 Video the right way." > Did I miss something? I'm not sure it's related at all...? Matt From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 04:50:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9D7A843 for ; Sun, 7 Jul 2013 04:50:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id A12FD10DA for ; Sun, 7 Jul 2013 04:50:21 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id 2so1765986qea.7 for ; Sat, 06 Jul 2013 21:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IWnk+8mQzcZzXFg7+w+mJ2HzKWRkzKu+H9Q0JDzTNng=; b=VPsq5bGBt9Wx/yrsMLTQZhXuiBCXFKeEwSfRa382mL1yBR0hbCjQMeGRXPCZbdMNCi f50mIkFzIeolQ42Oo0Kf1VxYXdW2Cl89ChzJQtFK7625yk5A6UAjQwN2Y3UyKAbLsAxj Hu3BTMwVC/P24DtZWZdI3eKaKVUFmprN+GQk1o+TBA3rhstXN9dSPS0BKkczcIDXib2H O6/Pr9TG6C8FIBuWcszDgYLc11LXnQG21ijHZS39GZL9HOesQji/1/bB4iaDLXnFdHj3 Vlfrjgn7Hy90bVoA4RV4IlSrKtbddxGMRCUfe+7mWLnMSE+Hq5rxK0Ncfd1k6c2rMgZu aeFQ== MIME-Version: 1.0 X-Received: by 10.49.107.201 with SMTP id he9mr10719106qeb.74.1373172621032; Sat, 06 Jul 2013 21:50:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Sat, 6 Jul 2013 21:50:20 -0700 (PDT) In-Reply-To: <20130706081402.313c9e00@X220.ovitrap.com> References: <20130706081402.313c9e00@X220.ovitrap.com> Date: Sat, 6 Jul 2013 21:50:20 -0700 X-Google-Sender-Auth: tqLXC2ljNZ1Ppmvo7lPbrnIb3d4 Message-ID: Subject: Re: Crashes with current on X220 From: Adrian Chadd To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 04:50:21 -0000 Hi, Can you try installing some 10-amd64 snapshots between then and now, and see roughly when it was introduced? There's been a lot of ACPI changes over the last 6 months. It wouldn't surprise me to find one or more of those messed things up. -adrian On 5 July 2013 17:14, Erich Dollansky wrote: > Hi, > > I updated my rock solid FreeBSD 10 installation from what was current > this January to > > FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: > Wed Jul 3 08:45:23 CIT 2013 > root@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 > > I have since then frequent crashes. Nothing is seen on the screen. The > mouse does not move, the caps lock key does not switch the light. I have > restarted the machine last evening without doing anything else. No X, > just plain FreeBSD before logging on. The machine might has done a > fsck. The machine was frozen this morning. > > Does anybody else has this experience too? > > Erich > _______________________________________________ > 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 Sun Jul 7 08:11:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90BD99C1 for ; Sun, 7 Jul 2013 08:11:41 +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 382D218D8 for ; Sun, 7 Jul 2013 08:11:40 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Uvk4D-001LAd-SV>; Sun, 07 Jul 2013 10:11:33 +0200 Received: from g226181082.adsl.alicedsl.de ([92.226.181.82] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Uvk4D-0032b6-NV>; Sun, 07 Jul 2013 10:11:33 +0200 Date: Sun, 7 Jul 2013 10:11:28 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: libc++: std::isinf() returns "int", is supposed to return boolvec_t Message-ID: <20130707101128.03579a41@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6zPmX=ldJTx0gtKU3Woks2_"; protocol="application/pgp-signature" X-Originating-IP: 92.226.181.82 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 08:11:41 -0000 --Sig_/6zPmX=ldJTx0gtKU3Woks2_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello. I try to compile a package of C++ software for FreeBSD with CLANG which uses clang++. I have to use -stdlib=3Dlibc++ -std=3Dc++11. I receive the following error and after consulting developers of the code I was informed that libc++ routine "std::isinf()" should return boolvec_t, but it returns obviously int. Well, I'm not an expert, I take this for true and I'm inclinded to ask here whether there is a bug I discover in the code I'm supposed to compile or whether this is a bug in the FreeBSD's libc++ implementation used. The fault is as follows: [...] /usr/bin/clang++ -Xclang -ffake-address-space-map -std=3Dc++11 -fno-exceptions -emit-llvm -ffp-contract=3Doff -stdlib=3Dlibc++ -c -target amd64-portbld-freebsd10.0 -o acosh.cc.bc ../vecmathlib/pocl/acosh.cc -include ../../../include/x86_64/types.h In file included from ../vecmathlib/pocl/acosh.cc:3: In file included from ../vecmathlib/pocl/pocl-compat.h:8: In file included from ../vecmathlib/pocl/../vecmathlib.h:89: ../vecmathlib/pocl/../vec_sse_d= ouble1.h:451:38: error: conversion from 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous boolvec_t isinf() const { return std::isinf(v); } size>^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: size>candidate constructor boolvec(bvector_t x): v(x) {} ^ ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate constructor boolvec(bool a): v(a) {} ^ ../vecmathlib/pocl/../vec_sse_double1.h:461:14: error: conversion from 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous return std::isnan(v); ^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: candidate constructor boolvec(bvector_t x): v(x) {} ^ ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate constructor boolvec(bool a): v(a) {} ^ In file included from ../vecmathlib/pocl/acos.cc:3: In file included from ../vecmathlib/pocl/pocl-compat.h:8: In file included from ../vecmathlib/pocl/../vecmathlib.h:89: ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error: conversion from 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous boolvec_t isinf() const { return std::isinf(v); } ^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: candidate constructor boolvec(bvector_t x): v(x) {} ^ ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate constructor boolvec(bool a): v(a) {} ^ ../vecmathlib/pocl/../vec_sse_double1.h:461:14: error: conversion from 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous return std::isnan(v); ^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: candidate constructor boolvec(bvector_t x): v(x) {} ^ ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate constructor boolvec(bool a): v(a) {} Regards, Oliver --Sig_/6zPmX=ldJTx0gtKU3Woks2_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJR2SK1AAoJEOgBcD7A/5N8jNsIANJ+7Jkk9/Vt8Ir5DliEaQQT cS2IcGTHGKA6+rtaQpqGy/lxJg3y8EYDfrCndLb21hctgbGUdfn4MRExu1iX5Kzt megavBE5riakGRBnj+iOs7ElR/eaBPz76/f7v8vLkjSZHJCqvZg8JBKEXSiWP4xq zKgfrr8NtWJw+el7q1TQ8DQdW0GUTbBSWpBrJ+D/uJvIPU4Wr2a8bLjmuM7lY8ls mY3m9SW9G/oO5GuF7qeTXc64Y73aQcnEZ2sMljQ35sF8EZe64JB/rDipKDnl3Yc/ OuymGfn7ootI/Kq7QxnWAzsuTAXtfyWH1KugfTDD4/vs07TvW9sJe/p5r+gNpsE= =3qwG -----END PGP SIGNATURE----- --Sig_/6zPmX=ldJTx0gtKU3Woks2_-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 08:22:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6A37D50 for ; Sun, 7 Jul 2013 08:22:43 +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 509331961 for ; Sun, 7 Jul 2013 08:22:42 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UvkEz-001O6X-KM>; Sun, 07 Jul 2013 10:22:41 +0200 Received: from g226181082.adsl.alicedsl.de ([92.226.181.82] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UvkEz-0033Hx-FB>; Sun, 07 Jul 2013 10:22:41 +0200 Date: Sun, 7 Jul 2013 10:22:40 +0200 From: "O. Hartmann" To: freebsd-current@freebsd.org Subject: Re: libc++: std::isinf() returns "int", is supposed to return boolvec_t Message-ID: <20130707102240.782e7db2@thor.walstatt.dyndns.org> In-Reply-To: <20130707101128.03579a41@thor.walstatt.dyndns.org> References: <20130707101128.03579a41@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/hIlUzN8C0llAFw1y2ykpaJJ"; protocol="application/pgp-signature" X-Originating-IP: 92.226.181.82 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 08:22:43 -0000 --Sig_/hIlUzN8C0llAFw1y2ykpaJJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 7 Jul 2013 10:11:28 +0200 "O. Hartmann" wrote: >=20 > Hello. >=20 > I try to compile a package of C++ software for FreeBSD with CLANG > which uses clang++. I have to use -stdlib=3Dlibc++ -std=3Dc++11. >=20 > I receive the following error and after consulting developers of the > code I was informed that libc++ routine "std::isinf()" should return > boolvec_t, but it returns obviously int. >=20 > Well, I'm not an expert, I take this for true and I'm inclinded to ask > here whether there is a bug I discover in the code I'm supposed to > compile or whether this is a bug in the FreeBSD's libc++ > implementation used. >=20 > The fault is as follows: >=20 > [...] >=20 > /usr/bin/clang++ -Xclang -ffake-address-space-map -std=3Dc++11 > -fno-exceptions -emit-llvm -ffp-contract=3Doff -stdlib=3Dlibc++ -c > -target amd64-portbld-freebsd10.0 -o > acosh.cc.bc ../vecmathlib/pocl/acosh.cc > -include ../../../include/x86_64/types.h In file included > from ../vecmathlib/pocl/acosh.cc:3: In file included > from ../vecmathlib/pocl/pocl-compat.h:8: In file included > from ../vecmathlib/pocl/../vecmathlib.h:89: ../vecmathlib/pocl/../vec_sse= _double1.h:451:38: > error: conversion from 'int' to 'boolvec_t' (aka 'boolvec size>') is ambiguous boolvec_t isinf() const { return std::isinf(v); } > size>^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: > size>candidate constructor boolvec(bvector_t x): v(x) {} > ^ > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate > constructor boolvec(bool a): v(a) {} > ^ > ../vecmathlib/pocl/../vec_sse_double1.h:461:14: error: conversion from > 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous return > std::isnan(v); ^~~~~~~~~~~~~ > ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: candidate > constructor boolvec(bvector_t x): v(x) {} > ^ > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate > constructor boolvec(bool a): v(a) {} > ^ > In file included from ../vecmathlib/pocl/acos.cc:3: > In file included from ../vecmathlib/pocl/pocl-compat.h:8: > In file included from ../vecmathlib/pocl/../vecmathlib.h:89: > ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error: conversion from > 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous > boolvec_t isinf() const { return std::isinf(v); } ^~~~~~~~~~~~~ > ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: candidate > constructor boolvec(bvector_t x): v(x) {} > ^ > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate > constructor boolvec(bool a): v(a) {} > ^ > ../vecmathlib/pocl/../vec_sse_double1.h:461:14: error: conversion from > 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous return > std::isnan(v); ^~~~~~~~~~~~~ > ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: candidate > constructor boolvec(bvector_t x): v(x) {} > ^ > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate > constructor boolvec(bool a): v(a) {} >=20 >=20 > Regards, >=20 > Oliver Sorry for the confusion. Well, C++11 standard says isnan() and fellows return bool, but somehow, it returns int - as I suspect. One of the codelines producing the error is (taken from POCLrc6: vec_sse_double1.h): [...] boolvec_t isfinite() const { return std::isfinite(v); } boolvec_t isinf() const { return std::isinf(v); } boolvec_t isnan() const { // This is wrong: // return _mm_ucomineq_sd(from_double(v), from_double(v)); // This works: // char r; // __asm__("ucomisd %[v],%[v]; setp %[r]": [r]"=3Dq"(r): [v]"x"(v)); // return boolvec_t::scalar_t(r); // This works as well: return std::isnan(v); } [...] --Sig_/hIlUzN8C0llAFw1y2ykpaJJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJR2SVRAAoJEOgBcD7A/5N8sMMIANy2yCizTpuqqMKcy9MXYOQe txjavLsqJ0y/sLA4HQevqA2lyJwsMRCHtL873r0gKvSoVLEJZujaEVrvstmsdR2T f0B6wvxiFGvR1Qz2coV6SZ8LsKjTgK2c6wDEkc1PQqt6Qbx/7EJO1tF/NxqgDcW0 84xeygv2LtLqE6z98x7fcFZogAjtd2eK2OGAUz2cB4mt41rWomUFCTznR9Llb7JS Ejx+F88/HQqXMKWxTNW1Fjghytm5MzwL75qtn6j39iXQ0d38V/+NtVrcdCRKH2tO FwTZQxGQNLc30S7OD14T4UK/yMOBLr/KfrrPjErjUoG2RMYx7QiaTlcispb1N84= =wsNS -----END PGP SIGNATURE----- --Sig_/hIlUzN8C0llAFw1y2ykpaJJ-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 11:00:02 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F05CD2; Sun, 7 Jul 2013 11:00:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id EB9CF1FBB; Sun, 7 Jul 2013 11:00:01 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 243FF6148; Sun, 7 Jul 2013 07:00:01 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=AuHqp8oTXP3TjLlQsP/a4XlZR567bLGUVyS7f9XIlEGi6yA+Oa9EFJuscXbL8Y7Zt bzhSq+uMbtstRO/hWUonFngHx+jUIdd31BLdUQvyi8SOd5GGZm2jyIRmSTFUq3x Message-ID: <51D94A2F.30401@protected-networks.net> Date: Sun, 07 Jul 2013 06:59:59 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130626 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@FreeBSD.org Subject: SVN r252892: videodev2.h update breaks gcc compilation X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netchild@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 11:00:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The recent linux header update triggers the following error: In file included from /usr/src/sys/compat/linux/linux_ioctl.c:91: /usr/src/sys/contrib/v4l/videodev2.h:430: warning: declaration does not declare anything /usr/src/sys/contrib/v4l/videodev2.h:460: warning: declaration does not declare anything /usr/src/sys/contrib/v4l/videodev2.h:837: warning: declaration does not declare anything /usr/src/sys/contrib/v4l/videodev2.h:930: warning: declaration does not declare anything /usr/src/sys/contrib/v4l/videodev2.h:1478: warning: declaration does not declare anything /usr/src/sys/contrib/v4l/videodev2.h:1600: warning: declaration does not declare anything /usr/src/sys/contrib/v4l/videodev2.h:1651: warning: declaration does not declare anything *** [linux_ioctl.o] Error code 1 imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlHZSi8ACgkQQv9rrgRC1JJ6FgCgygPHfqLe1MxRRBMvLMemxLX2 4DsAn2HSstnq/gKUAbVYMaYK0MwB03hF =UcYn -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 18:34:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52E957C7 for ; Sun, 7 Jul 2013 18:34:40 +0000 (UTC) (envelope-from demonking@hotmail.de) Received: from dub0-omc2-s6.dub0.hotmail.com (dub0-omc2-s6.dub0.hotmail.com [157.55.1.145]) by mx1.freebsd.org (Postfix) with ESMTP id D17991F5C for ; Sun, 7 Jul 2013 18:34:39 +0000 (UTC) Received: from DUB121-W20 ([157.55.1.136]) by dub0-omc2-s6.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Jul 2013 11:33:31 -0700 X-TMN: [xr5Y2ix+CdZ6NDqSSvWqpIBwKcg+uuQ8] X-Originating-Email: [demonking@hotmail.de] Message-ID: From: Denis D To: "freebsd-current@freebsd.org" Subject: Date: Sun, 7 Jul 2013 20:33:32 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2013 18:33:31.0872 (UTC) FILETIME=[7B65DE00:01CE7B40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 18:34:40 -0000 Hello Community=2C I hope someone could help me with this problem. The last days I have tried = to find a solution=2C but haven't found one. The watchdog timeout happens=2C when I'm going to download something or cop= y a file on my FTP server. When I start the transfer of the file=2C I wait = a moment and then my down-/upload freezes at something around 500[ ]KB. Aft= er waiting a little while or press a key like "return"=2C it comes to the i= nterrupt storm. interrupt storm detected on "irq51:"=3B throttling interrupt source Here is some information about my system: ifconfig msk0 msk0: flags=3D8843 metric 0= mtu 1500 options=3Dc009b ether bc:ae:c5:5a:ef:ec inet 192.168.2.3= 0 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=3D29 media: Ethernet autoselect (100baseTX ) status: active pciconf -lv mskc0@pci0:3:0:0: class=3D0x020000 card=3D0x84391043 chip=3D0x438111ab rev= =3D0x11 hdr=3D0x00 vendor =3D 'Marvell Technology Group Ltd.' dev= ice =3D 'Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AV= B]' class =3D network subclass =3D ethernet vmstat -i interrupt total rateirq1: atkbd0 = 916 2irq16: hdac1 97 = 0irq17: ehci0 ehci1+ 8729 21irq18: ohci0 ohci1* = 67 0irq19: ahci1 2883 = 7irq25: hdac0 4 0irq51: mskc0 = 90 0irq256: hpet0:t0 30332 = 75Total 43118 107 loader.conf hw.msk.msi_disable=3D1hw.pci.enable_msi=3D0hw.pci.enable_msix=3D0rc.confCod= e:hostname=3D"FreeBSD.local.domain"keymap=3D"german.iso.acc.kbd"ifconfig_ms= k0=3D"DHCP" sshd_enable=3D"YES"moused_enable=3D"YES"powerd_enable=3D"YES"# Set dumpdev = to "AUTO" to enable crash dumps=2C "NO" to disabledumpdev=3D"AUTO" I have also tried to change ifconfig_msk0=3D"DHCP" to ifconfig_msk0=3D"SYNC= DHCP" but nothing changed. If nothing helps=2C I will buy a new network card.=20 = From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 19:59:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C4404FF5 for ; Sun, 7 Jul 2013 19:59:51 +0000 (UTC) (envelope-from demonking@hotmail.de) Received: from dub0-omc2-s16.dub0.hotmail.com (dub0-omc2-s16.dub0.hotmail.com [157.55.1.155]) by mx1.freebsd.org (Postfix) with ESMTP id 09EAE1278 for ; Sun, 7 Jul 2013 19:59:50 +0000 (UTC) Received: from DUB121-W23 ([157.55.1.137]) by dub0-omc2-s16.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Jul 2013 12:58:44 -0700 X-TMN: [uq0+3a7iB4royWJJNZ7KyDvMYnj2zjGW] X-Originating-Email: [demonking@hotmail.de] Message-ID: From: Denis D To: "freebsd-current@freebsd.org" Subject: msk0 watchdog timeout and interrupt storm Date: Sun, 7 Jul 2013 21:58:43 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2013 19:58:44.0440 (UTC) FILETIME=[62B9D580:01CE7B4C] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 19:59:51 -0000 Hello Community=2C I hope someone could help me with this problem. The last days I have tried = to find a solution=2C but haven't found one. The watchdog timeout happens=2C when I'm going to download something or cop= y a file on my FTP server. When I start the transfer of the file=2C I wait = a moment and then my down-/upload freezes at something around 500[ ]KB. Aft= er waiting a little while or press a key like "return"=2C it comes to the i= nterrupt storm. interrupt storm detected on "irq51:"=3B throttling interrupt source Here is some information about my system: ifconfig msk0 msk0: flags=3D8843 metric 0= mtu 1500 options=3Dc009b ether bc:ae:c5:5a:ef:ec inet 192.168.2.3= 0 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=3D29 media: Ethernet autoselect (100baseTX ) status: active pciconf -lv mskc0@pci0:3:0:0: class=3D0x020000 card=3D0x84391043 chip=3D0x438111ab rev= =3D0x11 hdr=3D0x00 vendor =3D 'Marvell Technology Group Ltd.' device =3D 'Y= ukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB]' class =3D = network subclass =3D ethernet vmstat -i interrupt total rateirq1: atkbd0 916 2irq16: hdac1 97 0irq17: ehci0 ehci1+ = 8729 21irq18: ohci0 ohci1* 67 0irq19: ahci1 2883 7irq25: hdac0 4 0irq51: ms= kc0 90 0irq256: hpet0:t0 30332 75Total 43118 107 loader.conf hw.msk.msi_disable=3D1hw.pci.enable_msi=3D0hw.pci.enable_msix=3D0rc.confCod= e:hostname=3D"FreeBSD.local.domain"keymap=3D"german.iso.acc.kbd"ifconfig_ms= k0=3D"DHCP" sshd_enable=3D"YES"moused_enable=3D"YES"powerd_enable=3D"YES"# Set dumpdev = to "AUTO" to enable crash dumps=2C "NO" to disabledumpdev=3D"AUTO" I have also tried to change ifconfig_msk0=3D"DHCP" to ifconfig_msk0=3D"SYNC= DHCP" but nothing changed. If nothing helps=2C I will buy a new network card.=20 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe=2C send any mail to "freebsd-current-unsubscribe@freebsd.org= " Too many newsletters? You can unsubscribe or better yet=2C schedule automat= ic cleanup.ActionsDenis D8:33 PMTo: freebsd-current@freebsd.orgtrying to fi= x my format =3B) Hello Community=2CI hope someone could help me with this problem. The last = days I have tried to find a solution=2C but haven't found one.The watchdog = timeout happens=2C when I'm going to download something or copy a file on m= y FTP server. When I start the transfer of the file=2C I wait a moment and = then my down-/upload freezes at something around 500 KB. After waiting a li= ttle while or press a key like "return"=2C it comes to the interrupt storm.= interrupt storm detected on "irq51:"=3B throttling interrupt sourceHere is = some information about my system:ifconfig msk0msk0: flags=3D8843 metric 0 mtu 1500 options=3Dc009b ether bc:ae:c5:5a:ef:ec inet 192.168.2.30 netmask 0xffffff00 broadcast 192.168.2.255=20 nd6 options=3D29 media: Ethernet autoselect (100baseTX ) status: activepciconf -lvmskc0@pci0:3:0:0: class=3D0x020000 card=3D0x84391= 043 chip=3D0x438111ab rev=3D0x11 hdr=3D0x00 vendor =3D 'Marvell Technology Group Ltd.' device =3D 'Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller = with AVB]' class =3D network subclass =3D ethernetvmstat -iinterrupt tota= l rate irq1: atkbd0 916 2 irq16: hdac1 97 0 irq17: ehci0 ehci1+ 8729 21 irq18: ohci0 ohci1* 67 0 irq19: ahci1 2883 7 irq25: hdac0 4 0 irq51: mskc0 90 0 irq256: hpet0:t0 30332 75 Total 43118 107loader.confhw.msk.msi_di= sable=3D1 hw.pci.enable_msi=3D0 hw.pci.enable_msix=3D0 rc.conf hostname=3D"FreeBSD.local.domain" keymap=3D"german.iso.acc.kbd" ifconfig_msk0=3D"DHCP"sshd_enable=3D"YES" moused_enable=3D"YES" powerd_enable=3D"YES" # Set dumpdev to "AUTO" to enable crash dumps=2C "NO" to disable dumpdev=3D"AUTO"I have also tried to change ifconfig_msk0=3D"DHCP" to ifcon= fig_msk0=3D"SYNCDHCP" but nothing changed.If nothing helps=2C I will buy a = new network card.=20 = From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 20:05:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78A87399; Sun, 7 Jul 2013 20:05:54 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0341A12D7; Sun, 7 Jul 2013 20:05:53 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r67K5jme083838; Mon, 8 Jul 2013 00:05:45 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r67K5iqw083837; Mon, 8 Jul 2013 00:05:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 8 Jul 2013 00:05:44 +0400 From: Gleb Smirnoff To: Steve Kargl Subject: Re: buildkernel is broken Message-ID: <20130707200544.GE67810@glebius.int.ru> References: <20130703003535.GA69779@troutmask.apl.washington.edu> <20130703004650.GA69868@troutmask.apl.washington.edu> <20130703034516.GA70409@troutmask.apl.washington.edu> <20130705130338.GD67810@FreeBSD.org> <20130705153206.GA85816@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130705153206.GA85816@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Jonathan Anderson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 20:05:54 -0000 On Fri, Jul 05, 2013 at 08:32:06AM -0700, Steve Kargl wrote: S> On Fri, Jul 05, 2013 at 05:03:38PM +0400, Gleb Smirnoff wrote: S> > On Tue, Jul 02, 2013 at 08:45:16PM -0700, Steve Kargl wrote: S> > S> On Tue, Jul 02, 2013 at 10:51:57PM -0230, Jonathan Anderson wrote: S> > S> > On Tuesday, 2 July 2013 at 22:16, Steve Kargl wrote: S> > S> > > It seems that S> > S> > > S> > S> > > # Enable FreeBSD7 compatibility syscalls S> > S> > > options COMPAT_FREEBSD7 S> > S> > > S> > S> > > is required in a kernel config file. If it is mandatory to S> > S> > > have this option on FreeBSD 10, it may be appropriate to S> > S> > > expand the comment to S> > S> > > S> > S> > > S> > S> > > # Enable FreeBSD7 compatibility syscalls S> > S> > > # This option is MANDATORY. Do not remove. S> > S> > > options COMPAT_FREEBSD7 S> > S> > S> > S> > So... a non-optional option? S> > S> S> > S> Yes, it appears to be that way. S> > S> > Not really. It is required only if you also got COMPAT_43, the S> > pre-FreeBSD compat option. S> > S> S> So, it's essentially non-optional as the comment above COMPAT_43 S> is S> S> # S> # Implement system calls compatible with 4.3BSD and older versions of S> # FreeBSD. You probably do NOT want to remove this as much current code S> # still relies on the 4.3 emulation. S> S> Is "do NOT want to remove" too strong of a statement? Where did you find this statement? I remember it, but haven't seen it for long time. Can't find it in modern GENERIC. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 20:11:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2BF0681 for ; Sun, 7 Jul 2013 20:11:50 +0000 (UTC) (envelope-from demonking@hotmail.de) Received: from dub0-omc2-s11.dub0.hotmail.com (dub0-omc2-s11.dub0.hotmail.com [157.55.1.150]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1C8132C for ; Sun, 7 Jul 2013 20:11:50 +0000 (UTC) Received: from DUB121-W14 ([157.55.1.136]) by dub0-omc2-s11.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Jul 2013 13:10:41 -0700 X-TMN: [cXbh509gBZ7/9J+QG5jo6TB9QEZguV51] X-Originating-Email: [demonking@hotmail.de] Message-ID: From: Denis D To: "freebsd-current@freebsd.org" Subject: msk0 watchdog timeout and interrupt storm Date: Sun, 7 Jul 2013 22:10:42 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2013 20:10:41.0897 (UTC) FILETIME=[0E5D1590:01CE7B4E] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 20:11:50 -0000 Hello Community=2CI hope someone could help me with this problem. The last = days I have tried to find a solution=2C but haven't found one.The watchdog = timeout happens=2C when I'm going to download something or copy a file on m= y FTP server. When I start the transfer of the file=2C I wait a moment and = then my down-/upload freezes at something around 500 KB. After waiting a li= ttle while or press a key like "return"=2C it comes to the interrupt storm. interrupt storm detected on "irq51:"=3B throttling interrupt source. Here is some information about my system: ifconfig msk0msk0: flags=3D8843 metric 0 mtu 1500 options=3Dc009b ether bc:ae:c5:5a:ef:ec inet 192.168.2.30 netmask 0xffffff00 broadcast 192.168.2.255=20 nd6 options=3D29 media: Ethernet autoselect (100baseTX ) status: active pciconf -lv mskc0@pci0:3:0:0: class=3D0x020000 card=3D0x84391043 chip=3D0x438111ab rev= =3D0x11 hdr=3D0x00 vendor =3D 'Marvell Technology Group Ltd.' device =3D 'Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB= ]' class =3D network subclass =3D ethernetvmstat -iinterrupt total rate irq1: atkbd0 916 2 irq16: hdac1 97 0 irq17: ehci0 ehci1+ 8729 21 irq18: ohci0 ohci1* 67 0 irq19: ahci1 2883 7 irq25: hdac0 4 0 irq51: mskc0 90 0 irq256: hpet0:t0 30332 75 Total 43118 107 My loader.conf: hw.msk.msi_disable=3D1 hw.pci.enable_msi=3D0 hw.pci.enable_msix=3D0 My rc.conf hostname=3D"FreeBSD.local.domain" keymap=3D"german.iso.acc.kbd" ifconfig_msk0=3D"DHCP"sshd_enable=3D"YES" moused_enable=3D"YES" powerd_enable=3D"YES" # Set dumpdev to "AUTO" to enable crash dumps=2C "NO" to disable dumpdev=3D"AUTO" I have also tried to change ifconfig_msk0=3D"DHCP" to ifconfig_msk0=3D"SYNC= DHCP" but nothing changed.If nothing helps=2C I will buy a new network card= .=20 P.S: Can someone delete my other 2 posts? The format of them was horrible a= nd the another one has no subject :( = From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 21:51:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C0D6FA9 for ; Sun, 7 Jul 2013 21:51:10 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) by mx1.freebsd.org (Postfix) with ESMTP id 4243E1809 for ; Sun, 7 Jul 2013 21:51:09 +0000 (UTC) Received: from localhost ([109.223.132.80]) by mwinf5d15 with ME id xZr11l0061kE5tp03Zr1he; Sun, 07 Jul 2013 23:51:02 +0200 Message-ID: <51D9E2C5.2020704@orange.fr> Date: Sun, 07 Jul 2013 23:51:01 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130624 Thunderbird/17.0.7 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: buildkernel is broken References: <20130703003535.GA69779@troutmask.apl.washington.edu> <20130703004650.GA69868@troutmask.apl.washington.edu> <20130703034516.GA70409@troutmask.apl.washington.edu> <20130705130338.GD67810@FreeBSD.org> <20130705153206.GA85816@troutmask.apl.washington.edu> <20130707200544.GE67810@glebius.int.ru> In-Reply-To: <20130707200544.GE67810@glebius.int.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 21:51:10 -0000 On 07/07/2013 22:05, Gleb Smirnoff wrote: > On Fri, Jul 05, 2013 at 08:32:06AM -0700, Steve Kargl wrote: > S> On Fri, Jul 05, 2013 at 05:03:38PM +0400, Gleb Smirnoff wrote: > S> > On Tue, Jul 02, 2013 at 08:45:16PM -0700, Steve Kargl wrote: > S> > S> On Tue, Jul 02, 2013 at 10:51:57PM -0230, Jonathan Anderson wrote: > S> > S> > On Tuesday, 2 July 2013 at 22:16, Steve Kargl wrote: > S> > S> > > It seems that > S> > S> > > > S> > S> > > # Enable FreeBSD7 compatibility syscalls > S> > S> > > options COMPAT_FREEBSD7 > S> > S> > > > S> > S> > > is required in a kernel config file. If it is mandatory to > S> > S> > > have this option on FreeBSD 10, it may be appropriate to > S> > S> > > expand the comment to > S> > S> > > > S> > S> > > > S> > S> > > # Enable FreeBSD7 compatibility syscalls > S> > S> > > # This option is MANDATORY. Do not remove. > S> > S> > > options COMPAT_FREEBSD7 > S> > S> > > S> > S> > So... a non-optional option? > S> > S> > S> > S> Yes, it appears to be that way. > S> > > S> > Not really. It is required only if you also got COMPAT_43, the > S> > pre-FreeBSD compat option. > S> > > S> > S> So, it's essentially non-optional as the comment above COMPAT_43 > S> is > S> > S> # > S> # Implement system calls compatible with 4.3BSD and older versions of > S> # FreeBSD. You probably do NOT want to remove this as much current code > S> # still relies on the 4.3 emulation. > S> > S> Is "do NOT want to remove" too strong of a statement? > > Where did you find this statement? I remember it, but haven't seen > it for long time. Can't find it in modern GENERIC. > Try and read sys/conf/NOTES CBu From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 21:54:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58C90207 for ; Sun, 7 Jul 2013 21:54:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 211201842 for ; Sun, 7 Jul 2013 21:54:36 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=ME3lrcP4jFDzpPiCSQywCMKJiHtpRWeRXBDIYmR1BZg= c=1 sm=2 a=ctSXsGKhotwA:10 a=FKkrIqjQGGEA:10 a=E_vty8hfdtYA:10 a=IkcTkHD0fZMA:10 a=PkUQXC3DXfztPcc2ilwA:9 a=QEXdDO2ut3YA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAGPi2VGDaFve/2dsb2JhbABahAWDCL1YgR90gk2BCwINGQJfiCKYRY58kD+BJo4Rgw6BHAOhc4cogy0ggWw X-IronPort-AV: E=Sophos;i="4.87,1015,1363147200"; d="scan'208";a="38674580" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 07 Jul 2013 17:54:30 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 78226B3F4A for ; Sun, 7 Jul 2013 17:54:30 -0400 (EDT) Date: Sun, 7 Jul 2013 17:54:30 -0400 (EDT) From: Rick Macklem To: freebsd-current Message-ID: <1377697099.2894084.1373234070477.JavaMail.root@uoguelph.ca> Subject: Should I do a __FreeBSD_version bump for a kgssapi module kernel api change? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 21:54:37 -0000 Hi, I have a commit to add support for host-based (Kerberos would call these "service") principal initiator credentials to the kgssapi and krpc. It requires an additional call into the kgssapi, which means a change to the kernel api used to communicate with the kgssapi module (not used by anything else). What I am not sure of is whether or not this change requires a bump to __FreeBSD_version? (I think it would be possible to crash if the kernel is updated, but the kgssapi module is not.) Btw, I do not plan on MFCing this patch, so the above only applies to head/current. Thanks in advance for any help with this, rick From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 22:24:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E9A9E63 for ; Sun, 7 Jul 2013 22:24:48 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F3651195D for ; Sun, 7 Jul 2013 22:24:47 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 48EAC1A3C1A for ; Sun, 7 Jul 2013 15:24:47 -0700 (PDT) Message-ID: <51D9EAAE.7060605@mu.org> Date: Sun, 07 Jul 2013 15:24:46 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Should I do a __FreeBSD_version bump for a kgssapi module kernel api change? References: <1377697099.2894084.1373234070477.JavaMail.root@uoguelph.ca> In-Reply-To: <1377697099.2894084.1373234070477.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 22:24:48 -0000 On 7/7/13 2:54 PM, Rick Macklem wrote: > Hi, > > I have a commit to add support for host-based (Kerberos would call > these "service") principal initiator credentials to the kgssapi and > krpc. > > It requires an additional call into the kgssapi, which means a change > to the kernel api used to communicate with the kgssapi module (not used > by anything else). > > What I am not sure of is whether or not this change requires a bump to > __FreeBSD_version? (I think it would be possible to crash if the kernel > is updated, but the kgssapi module is not.) > > Btw, I do not plan on MFCing this patch, so the above only applies to > head/current. > > Thanks in advance for any help with this, rick > _______________________________________________ > 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" > Typically just bump it when in question. This sounds like a good time to do so. -- Alfred Perlstein VP Software Engineering, iXsystems From owner-freebsd-current@FreeBSD.ORG Sun Jul 7 22:32:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42C287ED; Sun, 7 Jul 2013 22:32:51 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2175319E1; Sun, 7 Jul 2013 22:32:50 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 412F923F845; Sun, 7 Jul 2013 18:32:50 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us 412F923F845 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 7 Jul 2013 18:32:47 -0400 From: Glen Barber To: Rick Macklem Subject: Re: Should I do a __FreeBSD_version bump for a kgssapi module kernel api change? Message-ID: <20130707223247.GE28252@glenbarber.us> References: <1377697099.2894084.1373234070477.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VUDLurXRWRKrGuMn" Content-Disposition: inline In-Reply-To: <1377697099.2894084.1373234070477.JavaMail.root@uoguelph.ca> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jul 2013 22:32:51 -0000 --VUDLurXRWRKrGuMn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 07, 2013 at 05:54:30PM -0400, Rick Macklem wrote: > Hi, >=20 > I have a commit to add support for host-based (Kerberos would call > these "service") principal initiator credentials to the kgssapi and > krpc. >=20 > It requires an additional call into the kgssapi, which means a change > to the kernel api used to communicate with the kgssapi module (not used > by anything else). >=20 > What I am not sure of is whether or not this change requires a bump to > __FreeBSD_version? (I think it would be possible to crash if the kernel > is updated, but the kgssapi module is not.) >=20 Yes please. It would also be helpful to document in the freebsd-versions section of doc/head/en_US.ISO8859-1/books/porters-handbook/book.xml . Glen --VUDLurXRWRKrGuMn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR2eyPAAoJEFJPDDeguUajDdMH/RWE6X3i/hIyi/nTpYehIbto J0nWuun98qy8VvpL20HmH+nebbcngicNxgUct3/sIj/T0AI7QgkHdWPTOK/LNdCJ dsbbNKxmAaVm/2Q3BpLUYIJXS+lJK2BKHivgQbxEieXB+DJEEYa6fTSzbsitoSKN iwbs0Nvt3il9A2Uc1hxOzLYqJaKGh6qfbQc88f/8LJcVAFpaeG0ugt4ZooHTOHMS ocwnG1pqvaJ0tWKixxiEn2CUQ/tqvTsSqqyaN/tB8262XsJJZm15GsZWp5S9G6IX LTuSClxixtjwM7N2+ycd8TWFDanlsZS2hygbOFkinGwHga8O/b/AfEx9dVc4/0A= =MAoI -----END PGP SIGNATURE----- --VUDLurXRWRKrGuMn-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 00:29:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4B94E26 for ; Mon, 8 Jul 2013 00:29:01 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id A76001D41 for ; Mon, 8 Jul 2013 00:29:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=70q0lKtDGOUy+zth0JzDkPxTXcfRpshnhH4oHRznXI8=; b=TqJoAOToAsKpR9XTjKN8HelA0e2CYOOuJ22Rt8B2v7yD689NclppojMwDEm1MkMJ3vwaocrdZ2DgO/PDG4XopGntWQpQ7JB6YQgL+egdXuCyN7k25LaAR+fTrJnTR2/xKsSwgQbPrsqV/QfuOczRd8UgCyXyBCpb/XsYFk5xoL4=; Received: from [39.210.114.110] (port=10816 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UvzK0-0038qr-Ci; Sun, 07 Jul 2013 18:28:54 -0600 Date: Mon, 8 Jul 2013 08:28:46 +0800 From: Erich Dollansky To: matt Subject: Re: Crashes with current on X220 Message-ID: <20130708082846.564815dc@X220.ovitrap.com> In-Reply-To: <51D8EC73.6080100@gmail.com> References: <20130706081402.313c9e00@X220.ovitrap.com> <51D8EC73.6080100@gmail.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Super Bisquit , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 00:29:01 -0000 Hi, On Sat, 06 Jul 2013 21:20:03 -0700 matt wrote: > On 07/06/13 19:40, Super Bisquit wrote: > > Look in the mailing list for "Fixing X220 Video the right way." > > > > Did I miss something? I'm not sure it's related at all...? you are right. But it did not crash anymore since this FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: Wed Jul 3 08:45:23 CIT 2013 root@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 There is a new problem, but it is minor and I will report only after testing with todays release. Erich > > > Matt > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 00:34:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B7F5FE0; Mon, 8 Jul 2013 00:34:00 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 537C61D70; Mon, 8 Jul 2013 00:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=XbtUfW8LVFV1mNPZD/yutdNvH66QUFv/ZOH4ryIj0hY=; b=ySDV0eQnQ0iMCE/o8qv6Hv/B/P5spyDa49ELNUgnuhDTQDoAuQw6AyYWHDEkxMkyNcMgpntINmNI2EtiOFb5lNdDByImuZjTIkx2EokxuMmQOjVdiikHv31F5galc5JYYSzH+SwGO1NBEoLts9yZn8igQ+XirdgB1PkRmz34gpc=; Received: from [39.210.114.110] (port=56225 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UvzOu-003AWZ-M4; Sun, 07 Jul 2013 18:33:59 -0600 Date: Mon, 8 Jul 2013 08:33:49 +0800 From: Erich Dollansky To: Adrian Chadd Subject: Re: Crashes with current on X220 Message-ID: <20130708083349.254f2ca0@X220.ovitrap.com> In-Reply-To: References: <20130706081402.313c9e00@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 00:34:00 -0000 Hi, On Sat, 6 Jul 2013 21:50:20 -0700 Adrian Chadd wrote: > Can you try installing some 10-amd64 snapshots between then and now, > and see roughly when it was introduced? I tried to upgrade my machine since March with the same result. But .. > > There's been a lot of ACPI changes over the last 6 months. It wouldn't > surprise me to find one or more of those messed things up. > ... I installed this FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: Wed Jul 3 08:45:23 CIT 2013 root@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 and the machine runs for nearly 2 days including X without these problems. With other words, you fixed it without knowing. Erich > > > -adrian > > On 5 July 2013 17:14, Erich Dollansky wrote: > > Hi, > > > > I updated my rock solid FreeBSD 10 installation from what was > > current this January to > > > > FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 > > r252491M: Wed Jul 3 08:45:23 CIT 2013 > > root@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 > > > > I have since then frequent crashes. Nothing is seen on the screen. > > The mouse does not move, the caps lock key does not switch the > > light. I have restarted the machine last evening without doing > > anything else. No X, just plain FreeBSD before logging on. The > > machine might has done a fsck. The machine was frozen this morning. > > > > Does anybody else has this experience too? > > > > Erich > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 04:12:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C20A979E; Mon, 8 Jul 2013 04:12:59 +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 9A56916B9; Mon, 8 Jul 2013 04:12:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r683iKsN060154; Sun, 7 Jul 2013 23:44:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r683iKln060151; Mon, 8 Jul 2013 03:44:20 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Jul 2013 03:44:20 GMT Message-Id: <201307080344.r683iKln060151@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 04:12:59 -0000 TB --- 2013-07-08 00:40:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-08 00:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-08 00:40:20 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-08 00:40:20 - cleaning the object tree TB --- 2013-07-08 00:40:20 - /usr/local/bin/svn stat /src TB --- 2013-07-08 00:40:25 - At svn revision 253014 TB --- 2013-07-08 00:40:26 - building world TB --- 2013-07-08 00:40:26 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 00:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 00:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 00:40:26 - SRCCONF=/dev/null TB --- 2013-07-08 00:40:26 - TARGET=arm TB --- 2013-07-08 00:40:26 - TARGET_ARCH=armv6 TB --- 2013-07-08 00:40:26 - TZ=UTC TB --- 2013-07-08 00:40:26 - __MAKE_CONF=/dev/null TB --- 2013-07-08 00:40:26 - cd /src TB --- 2013-07-08 00:40:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 8 00:40:33 UTC 2013 >>> 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 Mon Jul 8 03:41:44 UTC 2013 TB --- 2013-07-08 03:41:44 - generating LINT kernel config TB --- 2013-07-08 03:41:44 - cd /src/sys/arm/conf TB --- 2013-07-08 03:41:44 - /usr/bin/make -B LINT TB --- 2013-07-08 03:41:44 - cd /src/sys/arm/conf TB --- 2013-07-08 03:41:44 - /usr/sbin/config -m LINT TB --- 2013-07-08 03:41:44 - skipping LINT kernel TB --- 2013-07-08 03:41:44 - cd /src/sys/arm/conf TB --- 2013-07-08 03:41:44 - /usr/sbin/config -m AC100 TB --- 2013-07-08 03:41:45 - building AC100 kernel TB --- 2013-07-08 03:41:45 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 03:41:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 03:41:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 03:41:45 - SRCCONF=/dev/null TB --- 2013-07-08 03:41:45 - TARGET=arm TB --- 2013-07-08 03:41:45 - TARGET_ARCH=armv6 TB --- 2013-07-08 03:41:45 - TZ=UTC TB --- 2013-07-08 03:41:45 - __MAKE_CONF=/dev/null TB --- 2013-07-08 03:41:45 - cd /src TB --- 2013-07-08 03:41:45 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Mon Jul 8 03:41:45 UTC 2013 >>> 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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -ffreestanding -Werror /src/sys/arm/arm/pmap-v6.c /src/sys/arm/arm/pmap-v6.c:3339:28: error: more '%' conversions than data arguments [-Werror,-Wformat] "va %x pte %x in %s", va, *ptep)); ~^ /src/sys/sys/systm.h:83:17: note: expanded from macro 'KASSERT' kassert_panic msg; \ ^ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-08 03:44:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-08 03:44:20 - ERROR: failed to build AC100 kernel TB --- 2013-07-08 03:44:20 - 8904.93 user 1541.20 system 11039.36 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 06:56:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA29BC01 for ; Mon, 8 Jul 2013 06:56:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 87A281BC0 for ; Mon, 8 Jul 2013 06:56:15 +0000 (UTC) Received: from outgoing.leidinger.net (p57A39D80.dip0.t-ipconnect.de [87.163.157.128]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1B35384408D for ; Mon, 8 Jul 2013 08:55:57 +0200 (CEST) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id 6A602154E for ; Mon, 8 Jul 2013 08:55:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1373266554; bh=SLMKZ5W054WZt+62PgJ0xUgc9FdBvAwVSlOZB7ZV0Sg=; h=Date:From:To:Subject:In-Reply-To:References; b=IDwYHjZQRZF/KYHPMbLfzOQTmg/dfc4qmmohBq4R1ruB/xHpZZr1cRSvgyBNDtKqg DoV0BDjmUyAaBjvQCFvtlNK47iNJnWWmrvvg6f6VOOddIvJNpK438ZwX3SqW/0G+b8 F8yR30IT6K0WMCnV67znh4H+AopWw4mMJhxYOYK7cEr6YPEhqyU+wt36pOQBCx8ops A67t1txXAGNhpteosUSXUJAAaaTdztiOXKg7bOHu3acG78rX9K9xxlluraXj52SY68 oriq6BDQVU0BguQFiE8M4h347qLm9PbVdmmGKy9B34OQNISD1XcJEucXyM855zIsZr 4QHbNRnZh+DzQ== Date: Mon, 8 Jul 2013 08:55:54 +0200 From: Alexander Leidinger To: current@FreeBSD.org Subject: Re: SVN r252892: videodev2.h update breaks gcc compilation Message-ID: <20130708085554.0000063d@unknown> In-Reply-To: <51D94A2F.30401@protected-networks.net> References: <51D94A2F.30401@protected-networks.net> X-Mailer: Claws Mail 3.9.1-2-g66aa06 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1B35384408D.AF9EB X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.147, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.04, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01, URIBL_BLOCKED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1373871357.43214@LcW8PKkXy2Q57lTNEvndSQ X-EBL-Spam-Status: No X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 06:56:16 -0000 On Sun, 07 Jul 2013 06:59:59 -0400 Michael Butler wrote: > The recent linux header update triggers the following error: > > In file included from /usr/src/sys/compat/linux/linux_ioctl.c:91: > /usr/src/sys/contrib/v4l/videodev2.h:430: warning: declaration does > not declare anything Does someone know what this is supposed to result in? I would assume as the unions are unnamed and no variable is declared inside the struct with it, that the size of the struct is the same as not having those unions inside the structs. If this is correct I would assume the correct fix would be to #if-0 them out. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 07:18:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3DC95FD3 for ; Mon, 8 Jul 2013 07:18:13 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id A11B41C86 for ; Mon, 8 Jul 2013 07:18:10 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r687I9ud086605; Mon, 8 Jul 2013 11:18:09 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r687I9GK086604; Mon, 8 Jul 2013 11:18:09 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 8 Jul 2013 11:18:09 +0400 From: Gleb Smirnoff To: Claude Buisson Subject: Re: buildkernel is broken Message-ID: <20130708071809.GF67810@glebius.int.ru> References: <20130703003535.GA69779@troutmask.apl.washington.edu> <20130703004650.GA69868@troutmask.apl.washington.edu> <20130703034516.GA70409@troutmask.apl.washington.edu> <20130705130338.GD67810@FreeBSD.org> <20130705153206.GA85816@troutmask.apl.washington.edu> <20130707200544.GE67810@glebius.int.ru> <51D9E2C5.2020704@orange.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <51D9E2C5.2020704@orange.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 07:18:13 -0000 On Sun, Jul 07, 2013 at 11:51:01PM +0200, Claude Buisson wrote: C> On 07/07/2013 22:05, Gleb Smirnoff wrote: C> > On Fri, Jul 05, 2013 at 08:32:06AM -0700, Steve Kargl wrote: C> > S> On Fri, Jul 05, 2013 at 05:03:38PM +0400, Gleb Smirnoff wrote: C> > S> > On Tue, Jul 02, 2013 at 08:45:16PM -0700, Steve Kargl wrote: C> > S> > S> On Tue, Jul 02, 2013 at 10:51:57PM -0230, Jonathan Anderson wrote: C> > S> > S> > On Tuesday, 2 July 2013 at 22:16, Steve Kargl wrote: C> > S> > S> > > It seems that C> > S> > S> > > C> > S> > S> > > # Enable FreeBSD7 compatibility syscalls C> > S> > S> > > options COMPAT_FREEBSD7 C> > S> > S> > > C> > S> > S> > > is required in a kernel config file. If it is mandatory to C> > S> > S> > > have this option on FreeBSD 10, it may be appropriate to C> > S> > S> > > expand the comment to C> > S> > S> > > C> > S> > S> > > C> > S> > S> > > # Enable FreeBSD7 compatibility syscalls C> > S> > S> > > # This option is MANDATORY. Do not remove. C> > S> > S> > > options COMPAT_FREEBSD7 C> > S> > S> > C> > S> > S> > So... a non-optional option? C> > S> > S> C> > S> > S> Yes, it appears to be that way. C> > S> > C> > S> > Not really. It is required only if you also got COMPAT_43, the C> > S> > pre-FreeBSD compat option. C> > S> > C> > S> C> > S> So, it's essentially non-optional as the comment above COMPAT_43 C> > S> is C> > S> C> > S> # C> > S> # Implement system calls compatible with 4.3BSD and older versions of C> > S> # FreeBSD. You probably do NOT want to remove this as much current code C> > S> # still relies on the 4.3 emulation. C> > S> C> > S> Is "do NOT want to remove" too strong of a statement? C> > C> > Where did you find this statement? I remember it, but haven't seen C> > it for long time. Can't find it in modern GENERIC. C> > C> C> Try and read sys/conf/NOTES I think, the statement is outdated today. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 07:22:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 99F431FD for ; Mon, 8 Jul 2013 07:22:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 03BE31CB9 for ; Mon, 8 Jul 2013 07:22:33 +0000 (UTC) Received: (qmail 61171 invoked from network); 8 Jul 2013 08:13:43 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jul 2013 08:13:43 -0000 Message-ID: <51DA68B8.6070201@freebsd.org> Date: Mon, 08 Jul 2013 09:22:32 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Improved SYN Cookies: Looking for testers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 07:22:34 -0000 We have a SYN cookie implementation for quite some time now but it has some limitations with current realities for window scaling and SACK encoding the in the few available bits. This patch updates and improves SYN cookies mainly by: a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN (initial sequence number) without the use of timestamp bits. b) switching to the very fast and cryptographically strong SipHash-2-4 hash MAC algorithm to protect the SYN cookie against forgery. The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). Please find it here for testing: http://people.freebsd.org/~andre/syncookie-20130708.diff Please enable TCP logdebug to see connection status reporting by the changes. Detailed discussion: The purpose of SYN cookies is to encode all necessary session state in the 32 bits of our initial sequence number to avoid storing any information locally in memory. This is especially important when under heavy spoofed SYN attacks where we would either run out of memory or the syncache would fill with bogus connection attempts swamping out legitimate connections. The 32 bits of the ISN are a very limited space because we also have to store a cryptographically strong enough hash MAC in it to prevent spoofing of valid SYN cookies. The result is that 24 bits have to be dedicated to the MAC hash and only 8 bits remain available for the session state. The common parameters used on TCP sessions have changed quite a bit since SYN cookies very invented some 17 years ago. Today we a lot more bandwidth making the use window scaling almost mandatory. Also SACK has become standard as it makes recovering from packet loss much more efficient. The original SYN cookies method only stored an indexed MSS values in the cookie. This obviously isn't sufficient anymore and breaks in the presence of WSCALE. WSCALE information is only exchanged during SYN and SYN-ACK. If we can't keep track of it then we severely under- estimate the available send or receive window compounded with the fact that with large window scaling the window size information on the TCP segment header would be even lower numerically. A number of years back I extended SYN cookies to store the additional state in the TCP timestamp fields, if available on a connection. It has been adapted by Linux as well. While timestamps are common among the BSD, Linux and other *nix systems Windows never enabled them by default and thus are not present for the vast majority of clients seen on the Internet. The new improvement in this patch moves all necessary information into the ISN again removing the need for timestamps. Both the MSS and send WSCALE are stored in 3 bit indexed form together with a single bit for SACK. While we can't represent all possible MSS and WSCALE values, both are 16 bit fields in the TCP header, in only 3 bits each this, it turns out, isn't actually necessary. The MSS depends on the MTU of the path and with the dominance of ethernet the main value seen is around 1460 bytes. Encapsulations for DSL lines and some other overheads reduce it by a few more bytes for many connections seen. Based on large traffic surveys I've selected the most common values that perfectly, or with only a small down rounding difference, represent essentially 99.99% of all connections seen in real life. Rounding down to the next lower value isn't a problem as we only would send slightly more packets for the same amount of data. The send WSCALE is bit more tricky as rounding down would let us under- estimate the available send space available towards the remote host. Again it turns out that a small number of values dominates all connections and is thus carefully selected again. The receive WSCALE isn't encoded at all but recalculated based on the local receive socket buffer size when a valid SYN cookie returns. The socket buffer size most likely didn't change in the mean time on a listen socket. If it did we'd have a discrepancy for those SYN cookies in flight at the time of the change. These improvements allow one to run with SYN cookies only on Internet facing servers. However while SYN cookies are calculated and sent all the time, they're only used when the syn cache overflows due to attacks or overload. In that cause though you can rest assured that no significant degradation in TCP connection setup happens anymore and that even Windows clients can make use of window scaling and SACK. In addition the hash MAC to protect the SYN cookies is changed from MD5 to SipHash-2-4, a much faster and cryptographically secure algorithm recently developed by Jean-Philippe Aumasson and Daniel J. Bernstein. Ministat makes the MAC hash calculation speed difference even more obvious: x md5 + siphash +------------------------------------------------------------+ | + | ~ . .. ~ | + xx | |++ xx | |++ xx | |++ xx | |++ + xx | |++ + xx | |++ ++ xx | |++ ++ xxx | |++ ++ xxx | |++ ++ xxx xx x| | |_A_| | | MA | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 84 23467 28845 23955 23920.714 746.57003 + 84 8311 9777 8800 8840.6786 323.69754 Difference at 95.0% confidence -15080 +/- 174.018 -63.0417% +/- 0.727477% (Student's t, pooled s = 575.39) Happy testing. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 11:44:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 251D5DBE for ; Mon, 8 Jul 2013 11:44:39 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id B7AE81731 for ; Mon, 8 Jul 2013 11:44:38 +0000 (UTC) Received: from [192.168.1.80] ([31.46.168.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQiVh-1UmZdA3VbJ-00U1zF for ; Mon, 08 Jul 2013 13:44:38 +0200 Message-ID: <51DAA5FE.4040505@gmx.com> Date: Mon, 08 Jul 2013 13:43:58 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: another -Wunsequenced topic References: <51CEEC34.2010308@gmx.com> <51D03D27.3020100@gmx.com> In-Reply-To: <51D03D27.3020100@gmx.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OiFYkrsRBzVc+8rmk6w59VKPLgEmvkKW/jIlP34DwgW4gNDUi/w dkSOzqtBVm7Hc1AlEnF7wvXXGQwJm4iUbjqNscR5gY/FqaW6hSyGA8ZIrP8S3i3WixiWqk+ 5UoqBZlVmEBSPM+/feSMociGCa96IuBP7yGdjEyqyX01duQOejwe2vh86hsdSAjougKSCLx PN6Ru3nkAMjEWCq0kxGIw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 11:44:39 -0000 Well, this turned out to be a semi-false alarm. A week ago, for a short time, there was a bug in Clang. There is no undefined behavior in ptr = func(++ptr);, partially because a function call introduces a sequence point in C, but Clang did not respect this at that time. However, x = func1(++ptr) + func2(++ptr); is compiler-dependent. Additionally, if func() turns out to be a macro, rather than a native function, then undefined behavior (due to unsequencedness) occurs. According to the manpage for ntohl(): "On machines which have a byte order which is the same as the network order, routines are defined as null macros.". This can bite libstand on big-endian systems So in the end, Clang has accidentally pointed me to an irrelated bug, and induced some unnecessary code changes. lolz From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 11:55:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5C76B31F for ; Mon, 8 Jul 2013 11:55:34 +0000 (UTC) (envelope-from matthias@d2ux.net) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2017919DE for ; Mon, 8 Jul 2013 11:55:33 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 1FFF584F25E1; Mon, 8 Jul 2013 13:55:33 +0200 (CEST) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id sVX9pABst3iC; Mon, 8 Jul 2013 13:55:31 +0200 (CEST) Received: from www.s1.d2ux.org (unknown [10.0.0.4]) by mail.s1.d2ux.org (Postfix) with ESMTP id 019E484F2574; Mon, 8 Jul 2013 13:55:31 +0200 (CEST) Received: from 188.92.33.52 ([188.92.33.52]) by d2ux.org (Horde Framework) with HTTP; Mon, 08 Jul 2013 13:55:30 +0200 Date: Mon, 08 Jul 2013 13:55:30 +0200 Message-ID: <20130708135530.Horde.FnPwsSps0y86gQYFaIK_tw2@d2ux.org> From: Matthias Petermann To: freebsd-current@freebsd.org Subject: Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e) User-Agent: Internet Messaging Program (IMP) H5 (6.1.0) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: matthias@d2ux.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 11:55:34 -0000 Hello, I applied the patch, trying to get brightness controls for my X121e. But it looks like I need a different loader.conf setting. hw.pci0.0.2.0.handle="\\\\_SB_.PCI0.PEG.VID" doesn't work. In my ASl there is only one device providing DOD / DOS: Scope (_SB.PCI0) { Device (GFX0) { Name (_ADR, 0x00020000) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching { Store (And (Arg0, 0x07), DSEN) If (LEqual (And (Arg0, 0x03), Zero)) { If (CondRefOf (HDOS)) { HDOS () } } } Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices { If (CondRefOf (IDAB)) { IDAB () } Else { [truncated] Unfortunately I'm far away from understanding the ASL, so I can only guess this is the part where my graphics device is described. Also, because I don't have a PEG device with DOD / DOS, I fear the described patch for the X220 will not solve the problem for me? My ASL is located here: https://d2ux.org/owncloud/public.php?service=files&t=7022f90cea5e48da7fa65806c0d66091 I would really appreciate if someone with more ACPI background could take a look at it and tell me what I should try next. Thanks & kind regards, Matthias From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 11:55:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF4504D2 for ; Mon, 8 Jul 2013 11:55:50 +0000 (UTC) (envelope-from matthias@d2ux.net) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id 92CA419EB for ; Mon, 8 Jul 2013 11:55:50 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id E9BF184F25E5; Mon, 8 Jul 2013 13:55:49 +0200 (CEST) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id Pd_B9NI67dbQ; Mon, 8 Jul 2013 13:55:48 +0200 (CEST) Received: from www.s1.d2ux.org (unknown [10.0.0.4]) by mail.s1.d2ux.org (Postfix) with ESMTP id 2C25A84F25E1; Mon, 8 Jul 2013 13:55:48 +0200 (CEST) Received: from 188.92.33.52 ([188.92.33.52]) by d2ux.org (Horde Framework) with HTTP; Mon, 08 Jul 2013 13:55:48 +0200 Date: Mon, 08 Jul 2013 13:55:48 +0200 Message-ID: <20130708135548.Horde.q0PUQMyfbIgNVXQKfN5f9w9@d2ux.org> From: Matthias Petermann To: freebsd-current@freebsd.org Subject: Re: ACPI Lenovo X121e (Model 3045-79G, i3, HD3000) Suspend and LCD Brightness User-Agent: Internet Messaging Program (IMP) H5 (6.1.0) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: matthias@d2ux.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 11:55:50 -0000 Hello Kevin, Zitat von Kevin Oberman : > Can't help with suspend/resume, but I can point you to the brightness > solution. > > This is probably the same issue that impacts most recent Lenovo laptops. If > so, there is a fix in the thread titled "Fixing X220 Video The Right Way" > on this (acpi@) mailing list with the patch by jhb on Feb. 28, but be usre > to a followup message on using the fix posted on June 14. It' a tricky > issue with getting a string with quoted characters parsed correctly. > > There have been a number of discussions on ThinkPad suspend/resume, but I > have not seen a reliable fix. (I can't resume mine at this time, though it > suspends fine :-) Thanks for your reply. I found the thread you recommended to me and followed up with it. Looks like I cannot apply the same procedure unchanged to the X121e. It would be interesting to know if the suspend / brightness issues are specific to the Thinkpads with integrated Intel HD graphics or if also the NVidia models are affected. Kind regards, Matthias From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 12:19:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A5F386D for ; Mon, 8 Jul 2013 12:19:56 +0000 (UTC) (envelope-from matthias@d2ux.net) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id 196051D56 for ; Mon, 8 Jul 2013 12:19:55 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 7D75684F25C3 for ; Mon, 8 Jul 2013 10:41:30 +0200 (CEST) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id jzHsQSi3hiA7 for ; Mon, 8 Jul 2013 10:41:28 +0200 (CEST) Received: from www.s1.d2ux.org (unknown [10.0.0.4]) by mail.s1.d2ux.org (Postfix) with ESMTP id 6215584F2573 for ; Mon, 8 Jul 2013 10:41:28 +0200 (CEST) Received: from 188.92.33.52 ([188.92.33.52]) by d2ux.org (Horde Framework) with HTTP; Mon, 08 Jul 2013 10:41:28 +0200 Date: Mon, 08 Jul 2013 10:41:28 +0200 Message-ID: <20130708104128.Horde.4uMDgEJsnvTlAjpUPueiyQ1@d2ux.org> From: Matthias Petermann To: freebsd-current@freebsd.org Subject: Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e) References: <512A6FFF.2060603@gmail.com> <201302281209.45170.jhb@freebsd.org> <51394952.9030700@gmail.com> <201306141139.16728.jhb@freebsd.org> In-Reply-To: <201306141139.16728.jhb@freebsd.org> User-Agent: Internet Messaging Program (IMP) H5 (6.1.0) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 12:19:56 -0000 Hello, I applied the patch, trying to get brightness controls for my X121e. But it looks like I need a different loader.conf setting. hw.pci0.0.2.0.handle="\\\\_SB_.PCI0.PEG.VID" doesn't work. In my ASl there is only one device providing DOD / DOS: Scope (_SB.PCI0) { Device (GFX0) { Name (_ADR, 0x00020000) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching { Store (And (Arg0, 0x07), DSEN) If (LEqual (And (Arg0, 0x03), Zero)) { If (CondRefOf (HDOS)) { HDOS () } } } Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices { If (CondRefOf (IDAB)) { IDAB () } Else { [truncated] Unfortunately I'm far away from understanding the ASL, so I can only guess this is the part where my graphics device is described. Also, because I don't have a PEG device with DOD / DOS, I fear the described patch for the X220 will not solve the problem for me? My ASL is located here: https://d2ux.org/owncloud/public.php?service=files&t=7022f90cea5e48da7fa65806c0d66091 I would really appreciate if someone with more ACPI background could take a look at it and tell me what I should try next. Thanks & kind regards, Matthias From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 12:24:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 74258AB0 for ; Mon, 8 Jul 2013 12:24:55 +0000 (UTC) (envelope-from matthias@d2ux.net) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id 340DD1DB8 for ; Mon, 8 Jul 2013 12:24:55 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 6466984F2589 for ; Mon, 8 Jul 2013 10:49:11 +0200 (CEST) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id fxKRpMSh1bIr for ; Mon, 8 Jul 2013 10:49:09 +0200 (CEST) Received: from www.s1.d2ux.org (unknown [10.0.0.4]) by mail.s1.d2ux.org (Postfix) with ESMTP id 99B3484F2573 for ; Mon, 8 Jul 2013 10:49:09 +0200 (CEST) Received: from 188.92.33.52 ([188.92.33.52]) by d2ux.org (Horde Framework) with HTTP; Mon, 08 Jul 2013 10:49:09 +0200 Date: Mon, 08 Jul 2013 10:49:09 +0200 Message-ID: <20130708104909.Horde.uT2PlpWXIC0rslVjAeQ72Q1@d2ux.org> From: Matthias Petermann To: freebsd-current@freebsd.org Subject: Re: ACPI Lenovo X121e (Model 3045-79G, i3, HD3000) Suspend and LCD Brightness References: <51D86927.5090907@d2ux.net> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.0) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 12:24:55 -0000 Hello Kevin, Zitat von Kevin Oberman : > Can't help with suspend/resume, but I can point you to the brightness > solution. > > This is probably the same issue that impacts most recent Lenovo laptops. If > so, there is a fix in the thread titled "Fixing X220 Video The Right Way" > on this (acpi@) mailing list with the patch by jhb on Feb. 28, but be usre > to a followup message on using the fix posted on June 14. It' a tricky > issue with getting a string with quoted characters parsed correctly. > > There have been a number of discussions on ThinkPad suspend/resume, but I > have not seen a reliable fix. (I can't resume mine at this time, though it > suspends fine :-) Thanks for your reply. I found the thread you recommended to me and followed up with it. Looks like I cannot apply the same procedure unchanged to the X121e. It would be interesting to know if the suspend / brightness issues are specific to the Thinkpads with integrated Intel HD graphics or if also the NVidia models are affected. Kind regards, Matthias From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 13:27:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BE8C3839 for ; Mon, 8 Jul 2013 13:27:01 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 368EB10F5 for ; Mon, 8 Jul 2013 13:27:00 +0000 (UTC) Received: (qmail 61524 invoked from network); 8 Jul 2013 10:18:06 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jul 2013 10:18:06 -0000 Message-ID: <51DA85CF.3000401@freebsd.org> Date: Mon, 08 Jul 2013 11:26:39 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cy Schubert Subject: Re: Ipfilter pre-Vendor Import Issue References: <201307051838.r65IcL2Q005119@slippy.cwsent.com> In-Reply-To: <201307051838.r65IcL2Q005119@slippy.cwsent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Smirnoff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 13:27:01 -0000 On 05.07.2013 20:38, Cy Schubert wrote: > In message <20130705084649.GC67810@FreeBSD.org>, Gleb Smirnoff writes: >> What I'd prefer to see is the following: >> >> - commit new ipfilter untouched to vendor-sys/ipfilter >> - nuke sys/contrib/ipfilter >> - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter > > Having ipfilter in one place instead of two (vendor and vendor-sys) makes a > lot more sense. > > I suppose we could put ipfilter's kernel components in sys/netpfil but what > about the userland sources? Also see my reply below regarding keeping it in > contrib. > >> >> In future imports do: >> >> - commit newer ipfilter to vendor-sys/ipfilter >> - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter >> >> What's the reason to keep code in contrib? > > The reason to keep ipftilter in contrib is to maintain consistency with > other contributed software such as bind, nvi, sendmail, pf, and a host of > other notable software we don't maintain ourselves. Maintaining consistency > with other contributed software should probably be maintained. I'm open to > moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as > long as consistency is maintained across the board. > > Do you think we should put the userland sources also in the same location > or should we maintain a similar separation we do today? I'm open to both > however I'd prefer keeping all vendor software (kernel and userland) in one > location. I think the main distinction here is whether the adaptions to FreeBSD are kept local (resulting in almost a fork) or are fed upstream so that successive updates require less or no local changes. Having the kernel part in sys/netpfil certainly makes it easier for kernel people to adjust it to changed realities. IIRC ipfilter also has very messy ifdef's all over the place for every possible ancient version of FreeBSD. This probably should be cleaned up (and upstreamed) as well. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 13:44:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3602AE5E for ; Mon, 8 Jul 2013 13:44:02 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 98F1711A1 for ; Mon, 8 Jul 2013 13:44:01 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r68Di0Eq088443; Mon, 8 Jul 2013 17:44:00 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r68Di0WN088442; Mon, 8 Jul 2013 17:44:00 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 8 Jul 2013 17:44:00 +0400 From: Gleb Smirnoff To: Cy Schubert Subject: Re: Ipfilter pre-Vendor Import Issue Message-ID: <20130708134400.GH67810@glebius.int.ru> References: <20130705084649.GC67810@FreeBSD.org> <201307051838.r65IcL2Q005119@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201307051838.r65IcL2Q005119@slippy.cwsent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 13:44:02 -0000 Cy, On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote: C> > What I'd prefer to see is the following: C> > C> > - commit new ipfilter untouched to vendor-sys/ipfilter C> > - nuke sys/contrib/ipfilter C> > - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter C> C> Having ipfilter in one place instead of two (vendor and vendor-sys) makes a C> lot more sense. C> C> I suppose we could put ipfilter's kernel components in sys/netpfil but what C> about the userland sources? Also see my reply below regarding keeping it in C> contrib. IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter, but merge kernel files separately to sys/netpfil/ipfilter, and separately merge userland files to appropriate place. C> > In future imports do: C> > C> > - commit newer ipfilter to vendor-sys/ipfilter C> > - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter C> > C> > What's the reason to keep code in contrib? C> C> The reason to keep ipftilter in contrib is to maintain consistency with C> other contributed software such as bind, nvi, sendmail, pf, and a host of C> other notable software we don't maintain ourselves. Maintaining consistency C> with other contributed software should probably be maintained. I'm open to C> moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as C> long as consistency is maintained across the board. C> C> Do you think we should put the userland sources also in the same location C> or should we maintain a similar separation we do today? I'm open to both C> however I'd prefer keeping all vendor software (kernel and userland) in one C> location. The BSD license allows us to put the code into FreeBSD w/o any separation. So the question is: what is more handy to us? What do we actually gain having contrib/ipf, assuming we got vendor branch already? What we lose is: - more complex Makefiles - more complex hacking: edit files in one place, run make in other -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 14:56:09 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 88FB725F; Mon, 8 Jul 2013 14:56:09 +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 5F8821710; Mon, 8 Jul 2013 14:56:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r68Eu8Zj064717; Mon, 8 Jul 2013 10:56:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r68Eu8eO064708; Mon, 8 Jul 2013 14:56:08 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Jul 2013 14:56:08 GMT Message-Id: <201307081456.r68Eu8eO064708@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:56:09 -0000 TB --- 2013-07-08 11:50:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-08 11:50:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-08 11:50:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-08 11:50:18 - cleaning the object tree TB --- 2013-07-08 11:51:22 - /usr/local/bin/svn stat /src TB --- 2013-07-08 11:51:25 - At svn revision 253030 TB --- 2013-07-08 11:51:26 - building world TB --- 2013-07-08 11:51:26 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 11:51:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 11:51:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 11:51:26 - SRCCONF=/dev/null TB --- 2013-07-08 11:51:26 - TARGET=arm TB --- 2013-07-08 11:51:26 - TARGET_ARCH=armv6 TB --- 2013-07-08 11:51:26 - TZ=UTC TB --- 2013-07-08 11:51:26 - __MAKE_CONF=/dev/null TB --- 2013-07-08 11:51:26 - cd /src TB --- 2013-07-08 11:51:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 8 11:51:33 UTC 2013 >>> 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 Mon Jul 8 14:53:29 UTC 2013 TB --- 2013-07-08 14:53:29 - generating LINT kernel config TB --- 2013-07-08 14:53:29 - cd /src/sys/arm/conf TB --- 2013-07-08 14:53:29 - /usr/bin/make -B LINT TB --- 2013-07-08 14:53:29 - cd /src/sys/arm/conf TB --- 2013-07-08 14:53:29 - /usr/sbin/config -m LINT TB --- 2013-07-08 14:53:29 - skipping LINT kernel TB --- 2013-07-08 14:53:29 - cd /src/sys/arm/conf TB --- 2013-07-08 14:53:29 - /usr/sbin/config -m AC100 TB --- 2013-07-08 14:53:29 - building AC100 kernel TB --- 2013-07-08 14:53:29 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 14:53:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 14:53:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 14:53:29 - SRCCONF=/dev/null TB --- 2013-07-08 14:53:29 - TARGET=arm TB --- 2013-07-08 14:53:29 - TARGET_ARCH=armv6 TB --- 2013-07-08 14:53:29 - TZ=UTC TB --- 2013-07-08 14:53:29 - __MAKE_CONF=/dev/null TB --- 2013-07-08 14:53:29 - cd /src TB --- 2013-07-08 14:53:29 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Mon Jul 8 14:53:29 UTC 2013 >>> 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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -ffreestanding -Werror /src/sys/arm/arm/pmap-v6.c /src/sys/arm/arm/pmap-v6.c:3339:28: error: more '%' conversions than data arguments [-Werror,-Wformat] "va %x pte %x in %s", va, *ptep)); ~^ /src/sys/sys/systm.h:83:17: note: expanded from macro 'KASSERT' kassert_panic msg; \ ^ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-08 14:56:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-08 14:56:07 - ERROR: failed to build AC100 kernel TB --- 2013-07-08 14:56:07 - 8905.29 user 1540.20 system 11149.19 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 19:02:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1758E66 for ; Mon, 8 Jul 2013 19:02:05 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 3182112A3 for ; Mon, 8 Jul 2013 19:02:05 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r68J24HL082177 for ; Mon, 8 Jul 2013 15:02:04 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at mail.pix.net Message-ID: <51DB0CAC.4040004@pix.net> Date: Mon, 08 Jul 2013 15:02:04 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] sysutils/bsdconfg (0.9.0) and sysutils/sysrc (5.2) References: <13CA24D6AB415D428143D44749F57D7201FB267E@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FB267E@ltcfiswmsgmb21> Content-Type: multipart/mixed; boundary="------------040700080200020107080705" X-Mailman-Approved-At: Mon, 08 Jul 2013 19:27:16 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 19:02:06 -0000 This is a multi-part message in MIME format. --------------040700080200020107080705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In light of Devin's CFT, I offer the following, related code... Greetings - I've been asked to look at inserting ZFS support into the guided setup for FreeBSD. I've got a mostly working set of patches, but they are still a bit ugly -- hard wired to use ZFS now, rather than UFS, but I'm to the point where some external input is needed. On of the issues that I've run into is the partedit command "knows" that pretty much a partition equates to a filesystem. While that is true for UFS, it's not that way for ZFS. A partition is more likely a zpool, and that zpool can have as many filesystems as the user wants. Also, the bsdinstall framework (nice piece of work!) would need to be extended to query for zfs vs ufs and also have some hook for setting up the different zfs filesystems. Right now, I just kludged in a static list of filesystems to create in the "mount" script. I suppose there should be "filesystems" script before "mount" that lets a user muck about in terms of creating filesystems... Anyway, attached should be a patch against a recent snapshot of a -current source tree to add in this code. It's not ready for primetime, buy I would like some feedback about the approach I've taken so far. Thanks. -Kurt --------------040700080200020107080705 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="zfs.diffs" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfs.diffs" diff --git a/usr.sbin/bsdinstall/partedit/Makefile b/usr.sbin/bsdinstall/partedit/Makefile --- a/usr.sbin/bsdinstall/partedit/Makefile +++ b/usr.sbin/bsdinstall/partedit/Makefile @@ -1,9 +1,11 @@ # $FreeBSD$ +STRIP= +CFLAGS+=-g BINDIR= /usr/libexec/bsdinstall PROG= partedit LINKS= ${BINDIR}/partedit ${BINDIR}/autopart \ ${BINDIR}/partedit ${BINDIR}/scriptedpart SYMLINKS= ${BINDIR}/partedit /usr/sbin/sade DPADD= ${LIBGEOM} ${LIBNCURSESW} ${LIBUTIL} ${LIBDIALOG} ${LIBM} LDADD= -lgeom -lncursesw -lutil -ldialog -lm diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c b/usr.sbin/bsdinstall/partedit/gpart_ops.c --- a/usr.sbin/bsdinstall/partedit/gpart_ops.c +++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c @@ -114,16 +114,56 @@ newfs_command(const char *fstype, char * strcat(command, "-O1 "); else if (strcmp(items[i].name, "SU") == 0) strcat(command, "-U "); else if (strcmp(items[i].name, "SUJ") == 0) strcat(command, "-j "); else if (strcmp(items[i].name, "TRIM") == 0) strcat(command, "-t "); } + } else if (strcmp(fstype, "freebsd-zfs") == 0) { + int i; + DIALOG_LISTITEM items[] = { + {"fletcher4", "checksum algorithm: fletcher4", + "Use fletcher4 for data integrity checking. " + "(default)", 1 }, + {"fletcher2", "checksum algorithm: fletcher2", + "Use fletcher2 for data integrity checking. " + "(not recommended)", 0 }, + {"sha256", "checksum algorithm: sha256", + "Use sha256 for data integrity checking. " + "(not recommended)", 0 }, + {"atime", "Update atimes for files", + "Disable atime update", 0 }, + }; + + if (!use_default) { + int choice; + choice = dlg_checklist("ZFS Options", "", 0, 0, 0, + sizeof(items)/sizeof(items[0]), items, NULL, + FLAG_CHECK, &i); + if (choice == 1) /* Cancel */ + return; + } + + strcpy(command, "zpool create -o cachefile=/tmp/zpool.cache" + " -O canmount=off -O mountpoint=none "); + for (i = 0; i < (int)(sizeof(items)/sizeof(items[0])); i++) { + if (items[i].state == 0) + continue; + if (strcmp(items[i].name, "fletcher4") == 0) + strcat(command, "-O checksum=fletcher4 "); + else if (strcmp(items[i].name, "fletcher2") == 0) + strcat(command, "-O checksum=fletcher2 "); + else if (strcmp(items[i].name, "sha256") == 0) + strcat(command, "-O checksum=sha256 "); + else if (strcmp(items[i].name, "atime") == 0) + strcat(command, "-O atime=off "); + } + strcat(command, "zroot "); /* XXX */ } else if (strcmp(fstype, "fat32") == 0 || strcmp(fstype, "efi") == 0) { int i; DIALOG_LISTITEM items[] = { {"FAT32", "FAT Type 32", "Create a FAT32 filesystem (default)", 1 }, {"FAT16", "FAT Type 16", "Create a FAT16 filesystem", 0 }, {"FAT12", "FAT Type 12", @@ -339,30 +379,34 @@ gpart_partcode(struct gprovider *pp) LIST_FOREACH(gc, &pp->lg_geom->lg_config, lg_config) { if (strcmp(gc->lg_name, "scheme") == 0) { scheme = gc->lg_val; break; } } /* Make sure this partition scheme needs partcode on this platform */ - if (partcode_path(scheme) == NULL) + if (partcode_required(scheme) == NULL) return; LIST_FOREACH(gc, &pp->lg_config, lg_config) { if (strcmp(gc->lg_name, "index") == 0) { indexstr = gc->lg_val; break; } } /* Shell out to gpart for partcode for now */ sprintf(command, "gpart bootcode -p %s -i %s %s", - partcode_path(scheme), indexstr, pp->lg_geom->lg_name); - if (system(command) != 0) { + partcode_path(scheme, "zfs"), indexstr, pp->lg_geom->lg_name); + sprintf(message, "(echo %s; %s) >>%s 2>>%s", + command, command, getenv("BSDINSTALL_LOG"), + getenv("BSDINSTALL_LOG")); + + if (system(message) != 0) { sprintf(message, "Error installing partcode on partition %s", pp->lg_name); dialog_msgbox("Error", message, 0, 0, TRUE); } } void gpart_destroy(struct ggeom *lg_geom) @@ -586,16 +630,26 @@ set_default_part_metadata(const char *na mountpoint = "none"; if (strcmp(type, "freebsd-boot") == 0) md->bootcode = 1; /* VTOC8 needs partcode in UFS partitions */ if (strcmp(scheme, "VTOC8") == 0 && strcmp(type, "freebsd-ufs") == 0) md->bootcode = 1; + /* VTOC8 needs partcode at start of ZFS zpool */ + if (strcmp(scheme, "VTOC8") == 0 && strcmp(type, "freebsd-zfs") == 0) + md->bootcode = 1; + /* XXX + * ZFS on sparc64 uses the reserved space at the front of + * a zpool to hold the boot code, which is generally + * placed there with 'dd'. Just putting the bootcode on + * the disk is not enough. + */ + if (mountpoint == NULL || mountpoint[0] == '\0') { if (md->fstab != NULL) { free(md->fstab->fs_spec); free(md->fstab->fs_file); free(md->fstab->fs_vfstype); free(md->fstab->fs_mntops); free(md->fstab->fs_type); free(md->fstab); @@ -606,17 +660,17 @@ set_default_part_metadata(const char *na md->fstab = malloc(sizeof(struct fstab)); } else { free(md->fstab->fs_spec); free(md->fstab->fs_file); free(md->fstab->fs_vfstype); free(md->fstab->fs_mntops); free(md->fstab->fs_type); } - md->fstab->fs_spec = malloc(strlen(name) + 6); + md->fstab->fs_spec = malloc(strlen(name) + strlen("/dev/") + 1); sprintf(md->fstab->fs_spec, "/dev/%s", name); md->fstab->fs_file = strdup(mountpoint); /* Get VFS from text after freebsd-, if possible */ if (strncmp("freebsd-", type, 8) == 0) md->fstab->fs_vfstype = strdup(&type[8]); else if (strcmp("fat32", type) == 0 || strcmp("efi", type) == 0) md->fstab->fs_vfstype = strdup("msdosfs"); else @@ -743,25 +797,25 @@ gpart_create(struct gprovider *pp, char char *default_mountpoint, char **partname, int interactive) { struct gctl_req *r; struct gconfig *gc; struct gconsumer *cp; struct ggeom *geom; const char *errstr, *scheme; char sizestr[32], startstr[32], output[64], *newpartname; - char newfs[64], options_fstype[64]; + char newfs[255], options_fstype[64]; intmax_t maxsize, size, sector, firstfree, stripe; uint64_t bytes; int nitems, choice, junk; unsigned i; DIALOG_FORMITEM items[] = { - {0, "Type:", 5, 0, 0, FALSE, "freebsd-ufs", 11, 0, 12, 15, 0, - FALSE, "Filesystem type (e.g. freebsd-ufs, freebsd-swap)", + {0, "Type:", 5, 0, 0, FALSE, "freebsd-zfs", 11, 0, 12, 15, 0, + FALSE, "Filesystem type (e.g. freebsd-zfs, freebsd-swap)", FALSE}, {0, "Size:", 5, 1, 0, FALSE, "", 11, 1, 12, 15, 0, FALSE, "Partition size. Append K, M, G for kilobytes, " "megabytes or gigabytes.", FALSE}, {0, "Mountpoint:", 11, 2, 0, FALSE, "", 11, 2, 12, 15, 0, FALSE, "Path at which to mount partition (blank for " "swap, / for root filesystem)", FALSE}, {0, "Label:", 7, 3, 0, FALSE, "", 11, 3, 12, 15, 0, FALSE, @@ -890,18 +944,19 @@ addpartform: /* Check if the label has a / in it */ if (strchr(items[3].text, '/') != NULL) { dialog_msgbox("Error", "Label contains a /, which is not an " "allowed character.", 0, 0, TRUE); goto addpartform; } /* Warn if no mountpoint set */ - if (strcmp(items[0].text, "freebsd-ufs") == 0 && - items[2].text[0] != '/') { + if ((strcmp(items[0].text, "freebsd-ufs") == 0 && + items[2].text[0] != '/') || + strcmp(items[0].text, "freebsd-zfs") == 0) { dialog_vars.defaultno = TRUE; choice = dialog_yesno("Warning", "This partition does not have a valid mountpoint " "(for the partition from which you intend to boot the " "operating system, the mountpoint should be /). Are you " "sure you want to continue?" , 0, 0); dialog_vars.defaultno = FALSE; @@ -1040,17 +1095,17 @@ addpartform: for (i = 0; i < (sizeof(items) / sizeof(items[0])); i++) if (items[i].text_free) free(items[i].text); if (partname != NULL) *partname = strdup(newpartname); } - + void gpart_delete(struct gprovider *pp) { struct gconfig *gc; struct ggeom *geom; struct gconsumer *cp; struct gctl_req *r; const char *errstr; diff --git a/usr.sbin/bsdinstall/partedit/part_wizard.c b/usr.sbin/bsdinstall/partedit/part_wizard.c --- a/usr.sbin/bsdinstall/partedit/part_wizard.c +++ b/usr.sbin/bsdinstall/partedit/part_wizard.c @@ -39,20 +39,26 @@ #define MIN_FREE_SPACE (1024*1024*1024) /* 1 GB */ #define SWAP_SIZE(available) MIN(available/20, 4*1024*1024*1024LL) static char *boot_disk(struct gmesh *mesh); static char *wizard_partition(struct gmesh *mesh, const char *disk); int -part_wizard(void) { +part_wizard(const char *fsreq) { int error; struct gmesh mesh; - char *disk, *schemeroot; + char *disk, *schemeroot, *fstype; + char *fstypes[] = {"ufs", "zfs"}; + + fstype = fstypes[0]; + if (fsreq != NULL && strcmp(fsreq, "zfs") == 0) { + fstype = fstypes[1]; + } startwizard: error = geom_gettree(&mesh); dlg_put_backtitle(); error = geom_gettree(&mesh); disk = boot_disk(&mesh); if (disk == NULL) @@ -65,17 +71,17 @@ startwizard: if (schemeroot == NULL) return (1); geom_deletetree(&mesh); dlg_clear(); dlg_put_backtitle(); error = geom_gettree(&mesh); - error = wizard_makeparts(&mesh, schemeroot, 1); + error = wizard_makeparts(&mesh, schemeroot, fstype, 1); if (error) goto startwizard; free(schemeroot); geom_deletetree(&mesh); return (0); } @@ -277,26 +283,33 @@ query: } else { retval = strdup(disk); } return (retval); } int -wizard_makeparts(struct gmesh *mesh, const char *disk, int interactive) +wizard_makeparts(struct gmesh *mesh, const char *disk, const char *fstype, int interactive) { struct gmesh submesh; struct gclass *classp; struct ggeom *gp; struct gprovider *pp; intmax_t swapsize, available; - char swapsizestr[10], rootsizestr[10]; + char swapsizestr[10], rootsizestr[10], *fsname; + char *fsnames[] = {"freebsd-zfs", "freebsd-ufs"}; int retval; + if (strcmp(fstype, "zfs") == 0) { + fsname = fsnames[0]; + } else { + fsname = fsnames[1]; + } + LIST_FOREACH(classp, &mesh->lg_class, lg_class) if (strcmp(classp->lg_name, "PART") == 0) break; LIST_FOREACH(gp, &classp->lg_geom, lg_geom) if (strcmp(gp->lg_name, disk) == 0) break; @@ -326,17 +339,17 @@ wizard_makeparts(struct gmesh *mesh, con swapsize = SWAP_SIZE(available); humanize_number(swapsizestr, 7, swapsize, "B", HN_AUTOSCALE, HN_NOSPACE | HN_DECIMAL); humanize_number(rootsizestr, 7, available - swapsize - 1024*1024, "B", HN_AUTOSCALE, HN_NOSPACE | HN_DECIMAL); geom_gettree(&submesh); pp = provider_for_name(&submesh, disk); - gpart_create(pp, "freebsd-ufs", rootsizestr, "/", NULL, 0); + gpart_create(pp, fsname, rootsizestr, "/", NULL, 0); geom_deletetree(&submesh); geom_gettree(&submesh); pp = provider_for_name(&submesh, disk); gpart_create(pp, "freebsd-swap", swapsizestr, NULL, NULL, 0); geom_deletetree(&submesh); return (0); diff --git a/usr.sbin/bsdinstall/partedit/partedit.c b/usr.sbin/bsdinstall/partedit/partedit.c --- a/usr.sbin/bsdinstall/partedit/partedit.c +++ b/usr.sbin/bsdinstall/partedit/partedit.c @@ -90,17 +90,17 @@ main(int argc, const char **argv) nscroll = i = 0; /* Revert changes on SIGINT */ signal(SIGINT, sigint_handler); if (strcmp(basename(argv[0]), "autopart") == 0) { /* Guided */ prompt = "Please review the disk setup. When complete, press " "the Finish button."; - part_wizard(); + part_wizard("zfs"); } else if (strcmp(basename(argv[0]), "scriptedpart") == 0) { error = scripted_editor(argc, argv); prompt = NULL; if (error != 0) { end_dialog(); return (error); } } else { @@ -157,17 +157,17 @@ main(int argc, const char **argv) free(md->name); TAILQ_REMOVE(&part_metadata, md, metadata); free(md); } init_fstab_metadata(); break; case 4: /* Auto */ - part_wizard(); + part_wizard("zfs"); break; } error = 0; if (op == 5) { /* Finished */ dialog_vars.ok_label = __DECONST(char *, "Commit"); dialog_vars.extra_label = __DECONST(char *, "Revert & Exit"); @@ -489,16 +489,17 @@ init_fstab_metadata(void) md->fstab->fs_file = strdup(fstab->fs_file); md->fstab->fs_vfstype = strdup(fstab->fs_vfstype); md->fstab->fs_mntops = strdup(fstab->fs_mntops); md->fstab->fs_type = strdup(fstab->fs_type); md->fstab->fs_freq = fstab->fs_freq; md->fstab->fs_passno = fstab->fs_passno; md->newfs = NULL; + md->poolname = NULL; TAILQ_INSERT_TAIL(&part_metadata, md, metadata); } } static void get_mount_points(struct partedit_item *items, int nitems) { diff --git a/usr.sbin/bsdinstall/partedit/partedit.h b/usr.sbin/bsdinstall/partedit/partedit.h --- a/usr.sbin/bsdinstall/partedit/partedit.h +++ b/usr.sbin/bsdinstall/partedit/partedit.h @@ -40,28 +40,30 @@ struct ggeom; TAILQ_HEAD(pmetadata_head, partition_metadata); extern struct pmetadata_head part_metadata; struct partition_metadata { char *name; /* name of this partition, as in GEOM */ struct fstab *fstab; /* fstab data for this partition */ char *newfs; /* shell command to initialize partition */ + char *poolname; /* ZFS pool name */ int bootcode; TAILQ_ENTRY(partition_metadata) metadata; }; struct partition_metadata *get_part_metadata(const char *name, int create); void delete_part_metadata(const char *name); -int part_wizard(void); +int part_wizard(const char *fstype); int scripted_editor(int argc, const char **argv); -int wizard_makeparts(struct gmesh *mesh, const char *disk, int interactive); +int wizard_makeparts(struct gmesh *mesh, const char *disk, const char *fstype, + int interactive); /* gpart operations */ void gpart_delete(struct gprovider *pp); void gpart_destroy(struct ggeom *lg_geom); void gpart_edit(struct gprovider *pp); void gpart_create(struct gprovider *pp, char *default_type, char *default_size, char *default_mountpoint, char **output, int interactive); intmax_t gpart_max_free(struct ggeom *gp, intmax_t *start); @@ -72,11 +74,12 @@ int gpart_partition(const char *lg_name, void set_default_part_metadata(const char *name, const char *scheme, const char *type, const char *mountpoint, const char *newfs); /* machine-dependent bootability checks */ const char *default_scheme(void); int is_scheme_bootable(const char *part_type); size_t bootpart_size(const char *part_type); const char *bootcode_path(const char *part_type); -const char *partcode_path(const char *part_type); +const char *partcode_required(const char *part_type); +const char *partcode_path(const char *part_type, const char *fs_type); #endif diff --git a/usr.sbin/bsdinstall/partedit/partedit_generic.c b/usr.sbin/bsdinstall/partedit/partedit_generic.c --- a/usr.sbin/bsdinstall/partedit/partedit_generic.c +++ b/usr.sbin/bsdinstall/partedit/partedit_generic.c @@ -56,14 +56,19 @@ size_t bootpart_size(const char *part_type) { return (0); } const char * bootcode_path(const char *part_type) { return (NULL); } - + const char * -partcode_path(const char *part_type) { +partcode_required(const char *part_type) { return (NULL); } +const char * +partcode_path(const char *part_type, const char *fs_type) { + return (NULL); +} + diff --git a/usr.sbin/bsdinstall/partedit/partedit_pc98.c b/usr.sbin/bsdinstall/partedit/partedit_pc98.c --- a/usr.sbin/bsdinstall/partedit/partedit_pc98.c +++ b/usr.sbin/bsdinstall/partedit/partedit_pc98.c @@ -55,15 +55,21 @@ const char * bootcode_path(const char *part_type) { if (strcmp(part_type, "PC98") == 0) return ("/boot/pc98boot"); if (strcmp(part_type, "BSD") == 0) return ("/boot/boot"); return (NULL); } - + const char * -partcode_path(const char *part_type) { +partcode_required(const char *part_type) { /* No partcode */ return (NULL); } +const char * +partcode_path(const char *part_type, const char *fs_type) { + /* No partcode */ + return (NULL); +} + diff --git a/usr.sbin/bsdinstall/partedit/partedit_powerpc.c b/usr.sbin/bsdinstall/partedit/partedit_powerpc.c --- a/usr.sbin/bsdinstall/partedit/partedit_powerpc.c +++ b/usr.sbin/bsdinstall/partedit/partedit_powerpc.c @@ -71,18 +71,25 @@ bootpart_size(const char *part_type) { return (800*1024); return (0); } const char * bootcode_path(const char *part_type) { return (NULL); } - + const char * -partcode_path(const char *part_type) { +partcode_required(const char *part_type) { + if (strcmp(part_type, "APM") == 0 || strcmp(part_type, "MBR") == 0) + return ("required"); + return (NULL); +} + +const char * +partcode_path(const char *part_type, const char *fs_type) { if (strcmp(part_type, "APM") == 0) return ("/boot/boot1.hfs"); if (strcmp(part_type, "MBR") == 0) return ("/boot/boot1.elf"); return (NULL); } diff --git a/usr.sbin/bsdinstall/partedit/partedit_sparc64.c b/usr.sbin/bsdinstall/partedit/partedit_sparc64.c --- a/usr.sbin/bsdinstall/partedit/partedit_sparc64.c +++ b/usr.sbin/bsdinstall/partedit/partedit_sparc64.c @@ -48,16 +48,28 @@ bootpart_size(const char *part_type) { return (0); } const char * bootcode_path(const char *part_type) { return (NULL); } - + const char * -partcode_path(const char *part_type) { +partcode_required(const char *part_type) { if (strcmp(part_type, "VTOC8") == 0) - return ("/boot/boot1"); + return ("required"); return (NULL); } +const char * +partcode_path(const char *part_type, const char *fs_type) { + if (strcmp(part_type, "VTOC8") == 0) { + if (strcmp(fs_type, "ufs") == 0) { + return ("/boot/boot1"); + } else if (strcmp(fs_type, "zfs") == 0) { + return ("/boot/zfsboot"); + } + } + return (NULL); +} + diff --git a/usr.sbin/bsdinstall/partedit/partedit_x86.c b/usr.sbin/bsdinstall/partedit/partedit_x86.c --- a/usr.sbin/bsdinstall/partedit/partedit_x86.c +++ b/usr.sbin/bsdinstall/partedit/partedit_x86.c @@ -62,18 +62,31 @@ bootcode_path(const char *part_type) { return ("/boot/pmbr"); if (strcmp(part_type, "MBR") == 0) return ("/boot/mbr"); if (strcmp(part_type, "BSD") == 0) return ("/boot/boot"); return (NULL); } - + const char * -partcode_path(const char *part_type) { +partcode_required(const char *part_type) { if (strcmp(part_type, "GPT") == 0) - return ("/boot/gptboot"); + return ("required"); /* No partcode except for GPT */ return (NULL); } +const char * +partcode_path(const char *part_type, const char *fs_type) { + if (strcmp(part_type, "GPT") == 0) { + if (strcmp(fs_type, "ufs") == 0) { + return ("/boot/gptboot"); + } else if (strcmp(fs_type, "zfs") == 0) { + return ("/boot/gptzfsboot"); + } + } + + return (NULL); +} + diff --git a/usr.sbin/bsdinstall/partedit/scripted.c b/usr.sbin/bsdinstall/partedit/scripted.c --- a/usr.sbin/bsdinstall/partedit/scripted.c +++ b/usr.sbin/bsdinstall/partedit/scripted.c @@ -104,17 +104,17 @@ part_config(char *disk, const char *sche disk= strdup(disk); } geom_deletetree(&mesh); error = geom_gettree(&mesh); /* Create partitions */ if (config == NULL) { - wizard_makeparts(&mesh, disk, 0); + wizard_makeparts(&mesh, disk, "zfs", 0); goto finished; } while ((partition = strsep(&config, ",")) != NULL) { while ((ap = strsep(&partition, " \t\n")) != NULL) { if (*ap == '\0') continue; if (size == NULL) diff --git a/usr.sbin/bsdinstall/scripts/mount b/usr.sbin/bsdinstall/scripts/mount --- a/usr.sbin/bsdinstall/scripts/mount +++ b/usr.sbin/bsdinstall/scripts/mount @@ -28,28 +28,67 @@ TMP_FSTAB=/tmp/bsdinstall-tmp-fstab cat $PATH_FSTAB | awk -v BSDINSTALL_CHROOT=$BSDINSTALL_CHROOT '{ if ($2 ~ "^/.*") { fsname = $2; if (fsname == "/") fsname = "" - printf("%s\t%s%s\t%s\t%s\t%s\t%s\n", $1, BSDINSTALL_CHROOT, + dev = $1; + if ($3 == "zfs") + dev = "zroot" + printf("%s\t%s%s\t%s\t%s\t%s\t%s\n", dev, BSDINSTALL_CHROOT, fsname, $3, $4, $5, $6); } }' > $TMP_FSTAB -FILESYSTEMS=`cat $TMP_FSTAB | awk '/^[^#].*/ {if ($2 ~ "^/.*") printf("%s\n", $2);}' | sort -t /` +FILESYSTEMS=`cat $TMP_FSTAB | awk '/^[^#].*/ {if ($2 ~ "^/.*") printf("%s:%s\n", $2,$3);}' | sort -t /` -for i in $FILESYSTEMS; do - mkdir -p $i 2>/dev/null - MNTERROR=`mount -F $TMP_FSTAB $i 2>&1` - if [ $? -ne 0 ]; then - dialog --backtitle "FreeBSD Installer" --title "Error" \ - --msgbox "Error mounting partition $i:\n$MNTERROR" 0 0 - exit 1 +for f in $FILESYSTEMS; do + mnt=${f%:*} + fstype=${f##*:} + pool=zroot + mkdir -p $mnt 2>/dev/null + if [ $fstype != "zfs" ]; then + MNTERROR=`mount -F $TMP_FSTAB $mnt 2>&1` + if [ $? -ne 0 ]; then + dialog --backtitle "FreeBSD Installer" --title "Error" \ + --msgbox "Error mounting partition $mnt:\n$MNTERROR" 0 0 + exit 1 + fi + else + zfs set canmount=on $pool + zpool export $pool + zpool import -R $mnt -o cachefile=/tmp/zpool.cache $pool + zpool set bootfs=$pool $pool + + # tricky - the import of the pool forces it under /mnt! + zfs set mountpoint=/ $pool + zfs create -o exec=on -o setuid=off ${pool}/tmp + zfs create $pool/usr + zfs create -o setuid=off ${pool}/usr/ports + zfs create -o exec=off -o setuid=off ${pool}/usr/src + zfs create -o exec=on -o setuid=off ${pool}/usr/obj + zfs create $pool/var + zfs create -o exec=off -o setuid=off ${pool}/var/crash + zfs create -o exec=off -o setuid=off ${pool}/var/empty + zfs create -o exec=on -o setuid=off ${pool}/var/tmp + zfs create ${pool}/home + zfs mount -a + + mkdir -p $mnt/boot/zfs + echo 'zfs_load="YES"' > $mnt/boot/loader.conf + echo 'vfs.root.mountfrom="zfs:'$pool'"' >> $mnt/boot/loader.conf + if [ -f /tmp/zpool.cache ]; then + cp /tmp/zpool.cache $mnt/boot/zfs/zpool.cache + fi + echo 'zfs_enable="YES"' > $BSDINSTALL_TMPETC/rc.conf.zsh + chmod 1777 ${mnt}/tmp ${mnt}/var/tmp fi done # User might want a shell and require devfs, so mount it mkdir $BSDINSTALL_CHROOT/dev 2>/dev/null mount -t devfs devfs $BSDINSTALL_CHROOT/dev + +df > /tmp/log +ls -l /tmp >> /tmp/log diff --git a/usr.sbin/bsdinstall/scripts/umount b/usr.sbin/bsdinstall/scripts/umount --- a/usr.sbin/bsdinstall/scripts/umount +++ b/usr.sbin/bsdinstall/scripts/umount @@ -34,9 +34,12 @@ cat $PATH_FSTAB | awk -v BSDINSTALL_CHRO if (fsname == "/") fsname = "" printf("%s\t%s%s\t%s\t%s\t%s\t%s\n", $1, BSDINSTALL_CHROOT, fsname, $3, $4, $5, $6); } }' > $TMP_FSTAB umount $BSDINSTALL_CHROOT/dev 2>/dev/null +if [ -f $BSDINSTALL_TMPETC/rc.conf.zsh ]; then + zfs set readonly=on zroot/var/empty +fi umount -F $TMP_FSTAB -a 2>/dev/null --------------040700080200020107080705-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 20:00:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D76B8D2E; Mon, 8 Jul 2013 20:00:03 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-04.shaw.ca (smtp-out-04.shaw.ca [64.59.134.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8A5169A; Mon, 8 Jul 2013 20:00:03 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=HUoWN8sqH4wajA0WKpKyUV7G7o/UpN4YSPso/+twBIs= c=1 sm=1 a=uK1SP89eXToA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=ijVlJf1SI8H0ZCn5bmgA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-04.shaw.ca with ESMTP; 08 Jul 2013 14:00:01 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 3EE5C80; Mon, 8 Jul 2013 13:00:01 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.7/8.14.7) with ESMTP id r68Jxx5w063459; Mon, 8 Jul 2013 12:59:59 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201307081959.r68Jxx5w063459@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Andre Oppermann Subject: Re: Ipfilter pre-Vendor Import Issue In-Reply-To: Message from Andre Oppermann of "Mon, 08 Jul 2013 11:26:39 +0200." <51DA85CF.3000401@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jul 2013 12:59:59 -0700 Cc: Gleb Smirnoff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:00:04 -0000 In message <51DA85CF.3000401@freebsd.org>, Andre Oppermann writes: > On 05.07.2013 20:38, Cy Schubert wrote: > > In message <20130705084649.GC67810@FreeBSD.org>, Gleb Smirnoff writes: > >> What I'd prefer to see is the following: > >> > >> - commit new ipfilter untouched to vendor-sys/ipfilter > >> - nuke sys/contrib/ipfilter > >> - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter > > > > Having ipfilter in one place instead of two (vendor and vendor-sys) makes a > > lot more sense. > > > > I suppose we could put ipfilter's kernel components in sys/netpfil but what > > about the userland sources? Also see my reply below regarding keeping it in > > contrib. > > > >> > >> In future imports do: > >> > >> - commit newer ipfilter to vendor-sys/ipfilter > >> - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter > >> > >> What's the reason to keep code in contrib? > > > > The reason to keep ipftilter in contrib is to maintain consistency with > > other contributed software such as bind, nvi, sendmail, pf, and a host of > > other notable software we don't maintain ourselves. Maintaining consistency > > with other contributed software should probably be maintained. I'm open to > > moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as > > long as consistency is maintained across the board. > > > > Do you think we should put the userland sources also in the same location > > or should we maintain a similar separation we do today? I'm open to both > > however I'd prefer keeping all vendor software (kernel and userland) in one > > location. > > I think the main distinction here is whether the adaptions to > FreeBSD are kept local (resulting in almost a fork) or are fed > upstream so that successive updates require less or no local > changes. I see no problem feeding update upstream. The email I just received from Darren (cc'd Gleb and yourself) is likely to lead to this kind of relationship. > > Having the kernel part in sys/netpfil certainly makes it easier > for kernel people to adjust it to changed realities. True. I'm thinking we should do the same with the userland side of ipfilter, keeping everything consistent. Also, I think putting all of the vendor bits regardless of whether they're destined for kernel or userlan into vendor/ or vendor-sys/ should make it simpler as well. What are your thoughts? > > IIRC ipfilter also has very messy ifdef's all over the place for > every possible ancient version of FreeBSD. This probably should > be cleaned up (and upstreamed) as well. Yes. There's a lot of cruft in there for operating systems that are no longer relevant as well. At least we can push some of the FreeBSD cleanup upstream. Initially I'd like to import v5-1-2 into our vendor branch (either vendor/ or vendor-sys/ for the complete tarball) then svn merge into sys/netpfil/ (for kernel) and netpfil/ (for userland). Do you have any additional thoughts on any of this? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 20:00:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF568E2B; Mon, 8 Jul 2013 20:00:10 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7D278169B; Mon, 8 Jul 2013 20:00:10 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=dWI+KISfqi6yXfbrXJvRDWIsIl/dscdoFNN/P4RSWeA= c=1 sm=1 a=uK1SP89eXToA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=mR7p8zZ_AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=85G9OQlxTEjs4HCS67sA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 08 Jul 2013 14:00:03 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 0FF51D2; Mon, 8 Jul 2013 13:00:03 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.7/8.14.7) with ESMTP id r68K02Ef063517; Mon, 8 Jul 2013 13:00:02 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201307082000.r68K02Ef063517@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Gleb Smirnoff Subject: Re: Ipfilter pre-Vendor Import Issue In-Reply-To: Message from Gleb Smirnoff of "Mon, 08 Jul 2013 17:44:00 +0400." <20130708134400.GH67810@glebius.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jul 2013 13:00:02 -0700 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:00:10 -0000 In message <20130708134400.GH67810@glebius.int.ru>, Gleb Smirnoff writes: > Cy, > > On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote: > C> > What I'd prefer to see is the following: > C> > > C> > - commit new ipfilter untouched to vendor-sys/ipfilter > C> > - nuke sys/contrib/ipfilter > C> > - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter > C> > C> Having ipfilter in one place instead of two (vendor and vendor-sys) makes > a > C> lot more sense. > C> > C> I suppose we could put ipfilter's kernel components in sys/netpfil but wha > t > C> about the userland sources? Also see my reply below regarding keeping it i > n > C> contrib. > > IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter, > but merge kernel files separately to sys/netpfil/ipfilter, and separately > merge userland files to appropriate place. > > C> > In future imports do: > C> > > C> > - commit newer ipfilter to vendor-sys/ipfilter > C> > - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter > C> > > C> > What's the reason to keep code in contrib? > C> > C> The reason to keep ipftilter in contrib is to maintain consistency with > C> other contributed software such as bind, nvi, sendmail, pf, and a host of > C> other notable software we don't maintain ourselves. Maintaining consistenc > y > C> with other contributed software should probably be maintained. I'm open to > > C> moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as > > C> long as consistency is maintained across the board. > C> > C> Do you think we should put the userland sources also in the same location > C> or should we maintain a similar separation we do today? I'm open to both > C> however I'd prefer keeping all vendor software (kernel and userland) in on > e > C> location. > > The BSD license allows us to put the code into FreeBSD w/o any separation. > > So the question is: what is more handy to us? > > What do we actually gain having contrib/ipf, assuming we got vendor branch > already? > > What we lose is: > - more complex Makefiles > - more complex hacking: edit files in one place, run make in other How is this for a plan? Instead of importing the kernel bits into vendor-sys/ipfilter and the userland bits into vendor/ipfilter, the base tarball should be imported into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We keep the complete tarball imported into one place in the tree. Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and netpfil/ipfilter (for userland bits). We should probably think of moving pf and ipfw into the new subdirectory as well, but that's for a future discussion. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 21:08:25 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC187A87; Mon, 8 Jul 2013 21:08:25 +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 86C09191F; Mon, 8 Jul 2013 21:08:24 +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 AAA22627; Tue, 09 Jul 2013 00:08:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UwIfW-0008tW-DG; Tue, 09 Jul 2013 00:08:22 +0300 Message-ID: <51DB2A10.2030700@FreeBSD.org> Date: Tue, 09 Jul 2013 00:07:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-ports@FreeBSD.org, freebsd-toolchain@FreeBSD.org, FreeBSD Current Subject: new make vs security/vpnc X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 21:08:25 -0000 Using recent head and the latest ports as of now. $ cd /usr/ports/security/vpnc $ make ===> Building for vpnc-0.5.3_8 /usr/ports/security/vpnc/Makefile:37: *** missing separator. Stop. *** Error code 1 But fmake works just fine without any error. In my ports tree Makefile:37 is: .include Please advise. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 21:20:39 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE0BD226; Mon, 8 Jul 2013 21:20:39 +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 4E79319B3; Mon, 8 Jul 2013 21:20:37 +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 AAA22888; Tue, 09 Jul 2013 00:20:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UwIrM-0008uz-7w; Tue, 09 Jul 2013 00:20:36 +0300 Message-ID: <51DB2CEE.2040504@FreeBSD.org> Date: Tue, 09 Jul 2013 00:19:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-ports@FreeBSD.org, freebsd-toolchain@FreeBSD.org, FreeBSD Current Subject: Re: new make vs security/vpnc References: <51DB2A10.2030700@FreeBSD.org> In-Reply-To: <51DB2A10.2030700@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 21:20:39 -0000 on 09/07/2013 00:07 Andriy Gapon said the following: > > Using recent head and the latest ports as of now. > $ cd /usr/ports/security/vpnc > $ make > ===> Building for vpnc-0.5.3_8 > /usr/ports/security/vpnc/Makefile:37: *** missing separator. Stop. > *** Error code 1 > > But fmake works just fine without any error. > > In my ports tree Makefile:37 is: > .include > > Please advise. > A quick followup. I ran make -dA and noticed the following in the output: *** Failed target: do-build *** Failed command: (cd /usr/obj/ports/usr/ports/security/vpnc/work/vpnc-0.5.3; if ! /usr/bin/env BINS="cisco-decrypt" SHELL=/bin/sh NO_LINT=YES ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar" AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" PREFIX=/usr/local LOCALBASE=/usr/local MOTIFLIB="-L/usr/local/lib -lXm -lXp" LIBDIR="/usr/lib" CC="gcc46" CFLAGS="-O2 -pipe -O2 -fno-strict-aliasing -pipe -march=amdfam10 -DOPENSSL_GPL_VIOLATION -DCISCO_PATCH_VERSION -march=amdfam10 -march=amdfam10" CPP="cpp46" CPPFLAGS="" LDFLAGS=" -lcrypto -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46" CXX="g++46" CXXFLAGS="-O2 -pipe -O2 -fno-strict-aliasing -pipe -march=amdfam10 -DOPENSSL_GPL_VIOLATION -DCISCO_PATCH_VERSION -march=amdfam10 -march=amdfam10 -O2 -fno-strict-aliasing -pipe -march=amdfam10 -march=amdfam10" MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -o root -g wheel -m 555" BSD_INSTALL_LIB="install -s -o root -g wheel -m 444" BSD_INSTALL_SCRIPT="install -o root -g wheel -m 555" BSD_INSTALL_DATA="install -o root -g wheel -m 444" BSD_INSTALL_MAN="install -o root -g wheel -m 444" gmake -f /usr/ports/security/vpnc/Makefile -j`/sbin/sysctl -n kern.smp.cpus` all; then if [ -n "" ] ; then echo "===> Compilation failed unexpectedly."; (echo "") | /usr/bin/fmt 75 79 ; fi; false; fi) This is quite a large snippet, so here is a smaller and more obvious one: gmake -f /usr/ports/security/vpnc/Makefile -j`/sbin/sysctl -n kern.smp.cpus` all And indeed: $ gmake Makefile:37: *** missing separator. Stop. The port has USES= ... gmake but that's supposed to affect what is used inside the working directory. It's certainly a bug that gmake is run with the port's make file. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 22:06:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B9624352; Mon, 8 Jul 2013 22:06:29 +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 656601BB5; Mon, 8 Jul 2013 22:06:27 +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 BAA23631; Tue, 09 Jul 2013 01:06:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UwJZh-0008zR-OC; Tue, 09 Jul 2013 01:06:26 +0300 Message-ID: <51DB37AA.1050206@FreeBSD.org> Date: Tue, 09 Jul 2013 01:05:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-ports@FreeBSD.org, freebsd-toolchain@FreeBSD.org, FreeBSD Current Subject: Re: new make vs security/vpnc References: <51DB2A10.2030700@FreeBSD.org> <51DB2CEE.2040504@FreeBSD.org> In-Reply-To: <51DB2CEE.2040504@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jul 2013 22:06:29 -0000 Seems like the problem boils down to this: $ make -V MAKEFILE /usr/ports/security/vpnc/Makefile $ fmake -V MAKEFILE Makefile The only explicit assignments of MAKEFILE that I could find in ports infrastructure are these: /usr/ports/Mk/bsd.port.mk:MAKEFILE?= Makefile /usr/ports/Mk/bsd.gnustep.mk:MAKEFILE= GNUmakefile -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 02:06:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36EF4652; Tue, 9 Jul 2013 02:06:11 +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 0EFF31CD8; Tue, 9 Jul 2013 02:06:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69269lO068495; Mon, 8 Jul 2013 22:06:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69269ig068486; Tue, 9 Jul 2013 02:06:09 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 02:06:09 GMT Message-Id: <201307090206.r69269ig068486@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 02:06:11 -0000 TB --- 2013-07-08 23:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-08 23:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-08 23:00:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-08 23:00:18 - cleaning the object tree TB --- 2013-07-08 23:01:23 - /usr/local/bin/svn stat /src TB --- 2013-07-08 23:01:26 - At svn revision 253048 TB --- 2013-07-08 23:01:27 - building world TB --- 2013-07-08 23:01:27 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 23:01:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 23:01:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 23:01:27 - SRCCONF=/dev/null TB --- 2013-07-08 23:01:27 - TARGET=arm TB --- 2013-07-08 23:01:27 - TARGET_ARCH=armv6 TB --- 2013-07-08 23:01:27 - TZ=UTC TB --- 2013-07-08 23:01:27 - __MAKE_CONF=/dev/null TB --- 2013-07-08 23:01:27 - cd /src TB --- 2013-07-08 23:01:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 8 23:01:34 UTC 2013 >>> 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 Jul 9 02:03:30 UTC 2013 TB --- 2013-07-09 02:03:30 - generating LINT kernel config TB --- 2013-07-09 02:03:30 - cd /src/sys/arm/conf TB --- 2013-07-09 02:03:30 - /usr/bin/make -B LINT TB --- 2013-07-09 02:03:30 - cd /src/sys/arm/conf TB --- 2013-07-09 02:03:30 - /usr/sbin/config -m LINT TB --- 2013-07-09 02:03:30 - skipping LINT kernel TB --- 2013-07-09 02:03:30 - cd /src/sys/arm/conf TB --- 2013-07-09 02:03:30 - /usr/sbin/config -m AC100 TB --- 2013-07-09 02:03:31 - building AC100 kernel TB --- 2013-07-09 02:03:31 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 02:03:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 02:03:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 02:03:31 - SRCCONF=/dev/null TB --- 2013-07-09 02:03:31 - TARGET=arm TB --- 2013-07-09 02:03:31 - TARGET_ARCH=armv6 TB --- 2013-07-09 02:03:31 - TZ=UTC TB --- 2013-07-09 02:03:31 - __MAKE_CONF=/dev/null TB --- 2013-07-09 02:03:31 - cd /src TB --- 2013-07-09 02:03:31 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Tue Jul 9 02:03:31 UTC 2013 >>> 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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -ffreestanding -Werror /src/sys/arm/arm/pmap-v6.c /src/sys/arm/arm/pmap-v6.c:3339:28: error: more '%' conversions than data arguments [-Werror,-Wformat] "va %x pte %x in %s", va, *ptep)); ~^ /src/sys/sys/systm.h:83:17: note: expanded from macro 'KASSERT' kassert_panic msg; \ ^ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 02:06:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 02:06:09 - ERROR: failed to build AC100 kernel TB --- 2013-07-09 02:06:09 - 8909.68 user 1540.76 system 11150.78 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 04:40:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D44B54BA for ; Tue, 9 Jul 2013 04:40:52 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id B7989172A for ; Tue, 9 Jul 2013 04:40:51 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r694eiD6039264; Tue, 9 Jul 2013 04:40:44 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id mc6hrzs7aavxtheweh8rdnqdb6; Tue, 09 Jul 2013 04:40:44 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: another -Wunsequenced topic Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <51DAA5FE.4040505@gmx.com> Date: Mon, 8 Jul 2013 21:40:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6AC1186D-3D9C-4B7A-B5E4-4EA9CB120517@kientzle.com> References: <51CEEC34.2010308@gmx.com> <51D03D27.3020100@gmx.com> <51DAA5FE.4040505@gmx.com> To: dt71@gmx.com X-Mailer: Apple Mail (2.1283) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 04:40:52 -0000 On Jul 8, 2013, at 4:43 AM, dt71@gmx.com wrote: > Well, this turned out to be a semi-false alarm. A week ago, for a = short time, there was a bug in Clang. There is no undefined behavior in >=20 > ptr =3D func(++ptr);, No, there is not. However, this does have an implicit redundant store, so changing it to ptr =3D func(ptr + 1); is still a good idea, just not for the reason Clang was claiming. > partially because a function call introduces a sequence point in C, = but Clang did not respect this at that time. However, >=20 > x =3D func1(++ptr) + func2(++ptr); >=20 > is compiler-dependent. Code like this is badly broken. The order of evaluation here can even change across compiler versions (optimizers use a variety of criteria to reorganize code, which can easily change from version to version). > Additionally, if func() turns out to be a macro, rather than a native = function, then undefined behavior (due to unsequencedness) occurs. Replacing functions with macros is a common way to optimize code, which is yet another reason the idiom above should generally be avoided. > So in the end, Clang has accidentally pointed me to an irrelated bug, = and induced some unnecessary code changes. Not strictly necessary for correctness, but still good changes for the = most part. Tim From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 04:41:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 78D2E5D4 for ; Tue, 9 Jul 2013 04:41:20 +0000 (UTC) (envelope-from eric.camachat@gmail.com) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 55E66173F for ; Tue, 9 Jul 2013 04:41:20 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rr13so5079571pbb.34 for ; Mon, 08 Jul 2013 21:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer; bh=bDWgbXmuJMz4IXBZOLOAN+KGIATHP89bv4/D9L7P24c=; b=LLmXOgHI3DoEhjtWNQ8b1lEh7CKsijfszuJqZ/awFzQHRp85JzXl8SdvkFEqduVilp oOjny0/iP3qc/23fQm7/Ax1vTh5UlALFsM7KIo90TRzUyn/9umYP2tIeVyZMHOObOvfe 0/9MxbaUOFpFir5v8drFkcAO4XwqlxUUOIcm2I0mIU2Z4tCPO5jRpQWPsbXCuWSxZrvm UJDKr8G7gbvAZ6QDoJBx2/D9C3ti4JWhmHBkYkm8pP2jQ7Fv1TNpjHFwP1jG/aiokLgA OO+w2ofvS1XQ0YTbOP7/QvKjdv6XWa36tt+UqGKPyWHFEkPDovS8h6l+ppWerziL6Ny6 op8A== X-Received: by 10.67.8.98 with SMTP id dj2mr25908523pad.47.1373344880133; Mon, 08 Jul 2013 21:41:20 -0700 (PDT) Received: from [192.168.1.73] (172-1-142-179.lightspeed.sntcca.sbcglobal.net. [172.1.142.179]) by mx.google.com with ESMTPSA id at1sm25873941pbc.10.2013.07.08.21.41.18 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 08 Jul 2013 21:41:19 -0700 (PDT) Subject: Kernel crash during heavy disk access From: Eric Camachat To: current@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EClq6sh3pyFgT8a0ch2T" Date: Mon, 08 Jul 2013 21:41:11 -0700 Message-ID: <1373344871.1831.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 04:41:20 -0000 --=-EClq6sh3pyFgT8a0ch2T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I experienced kernel crashes while make world or ports. For example: # cd /usr/port/lang/mono # make Will cause the crash, from /var/crash/core.txt: eb8460p dumped core - see /var/crash/vmcore.5 Mon Jul 8 21:22:58 PDT 2013 FreeBSD eb8460p 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r253048: Mon Jul 8 19:07:18 PDT 2013 root@eb8460p:/u sr/obj/usr/src/sys/EB8460p amd64 panic: ffs_valloc: dup alloc GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: mode =3D 0100600, inum =3D 52969060, fs =3D / panic: ffs_valloc: dup alloc cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff805fd6d0 at kdb_backtrace+0x60 #1 0xffffffff805c5b65 at panic+0x155 #2 0xffffffff807dda6a at ffs_valloc+0x88a #3 0xffffffff8081a34c at ufs_makeinode+0x7c #4 0xffffffff808d2872 at VOP_CREATE_APV+0x92 #5 0xffffffff80670c49 at vn_open_cred+0x2c9 #6 0xffffffff8066a22f at kern_openat+0x1ef #7 0xffffffff8085db47 at amd64_syscall+0x357 #8 0xffffffff808475db at Xfast_syscall+0xfb Uptime: 6m57s Dumping 599 out of 3972 MB:..3%..11%..22%..33%..41%..51%..62%..73%..81%..91% Reading symbols from /boot/modules/cuse4bsd.ko...done. Loaded symbols for /boot/modules/cuse4bsd.ko Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ubt.ko.symbols Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. Loaded symbols for /boot/kernel/ng_hci.ko.symbols Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. Loaded symbols for /boot/kernel/ng_bluetooth.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. Loaded symbols for /boot/kernel/ng_l2cap.ko.symbols Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. Loaded symbols for /boot/kernel/ng_btsocket.ko.symbols Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. Loaded symbols for /boot/kernel/ng_socket.ko.symbols #0 doadump (textdump=3D) at pcpu.h:236 236 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3D) at pcpu.h:236 #1 0xffffffff805c57e0 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff805c5ba4 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff807dda6a in ffs_valloc (pvp=3D, mode=3D, cred=3D, vpp=3D) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1022 #4 0xffffffff8081a34c in ufs_makeinode (mode=3D, dvp=3D0xfffffe011bf44ce8, vpp=3D0xffffff811ba058d8, cnp=3D0xffffff811ba05900) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2620 #5 0xffffffff808d2872 in VOP_CREATE_APV (vop=3D, a=3D) at vnode_if.c:265 #6 0xffffffff80670c49 in vn_open_cred (ndp=3D0xffffff811ba05880, flagp=3D0xffffff811ba0595c, cmode=3D420, vn_open_flags=3D, cred=3D0xfffffe0011fcee00, fp=3D0xfffffe00110925a0) at vnode_if.h:109 #7 0xffffffff8066a22f in kern_openat (td=3D0xfffffe011960f920, fd=3D, path=3D0x801dbd580
, pathseg=3DUIO_USERSPACE, flags=3D1538, mode=3D) at /usr/src/sys/kern/vfs_syscalls.c:1093 #8 0xffffffff8085db47 in amd64_syscall (td=3D0xfffffe011960f920, traced=3D0) at subr_syscall.c:134 #9 0xffffffff808475db in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #10 0x00000008013a5f2a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) --=20 Eric Camachat --=-EClq6sh3pyFgT8a0ch2T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iF4EABEIAAYFAlHblGcACgkQSfBQu3oOwYxD/QEAhy+daVGzCMeZKl7ba09ve1zQ tw9SMiSKsiZ/9KGwa+0A/R06gU9vXDt7/k4GERniIcAHCqK7qMIkKE9O9vwYF9hT =lGQX -----END PGP SIGNATURE----- --=-EClq6sh3pyFgT8a0ch2T-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 06:05:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E145533E for ; Tue, 9 Jul 2013 06:05:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id A9102199E for ; Tue, 9 Jul 2013 06:05:14 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id k14so2762933qcv.34 for ; Mon, 08 Jul 2013 23:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uFUpMG3vvxMF1aYibrODNTsXtY3qlzcpVmx397jOjpc=; b=xkvCnKAgE6CCk8IxF1i6umCxD3dUztEK+fp1o6JvOH0W8wKgXNZ/1tWYHo8sMSnsM8 kvxDBriIUu3lCGB0iEhYWLL/wcPrca3K6+B00LFJTHsGU6m3iNAH7Nox/X2dvA+efhU4 lhpN7r77eQvl3OWyvQm47RZgW77pbuGjMrGFPG/8SmdtoDJNbx0yyo2OIZH6Y6FqFTa1 0CNR32e+SF80/t1tN0mQq7GFqNDKGe/LI4/uZViWwtXs6R6OvyINARlnD8tSNXWZNjqo uvkrf9WF/2KgCL/wHtVFnG0a8RL7h46QJvmGQqCrqOkSk/aohpc+ENLQc1ddJeN29aVu MYLQ== MIME-Version: 1.0 X-Received: by 10.224.13.19 with SMTP id z19mr22024655qaz.12.1373349914263; Mon, 08 Jul 2013 23:05:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Mon, 8 Jul 2013 23:05:14 -0700 (PDT) In-Reply-To: <1373344871.1831.9.camel@localhost> References: <1373344871.1831.9.camel@localhost> Date: Mon, 8 Jul 2013 23:05:14 -0700 X-Google-Sender-Auth: sy1XKyMZnzwo6VzagKbePNkyhps Message-ID: Subject: Re: Kernel crash during heavy disk access From: Adrian Chadd To: Eric Camachat Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 06:05:14 -0000 Hi, Try doing a full, non-journal fsck. -adrian On 8 July 2013 21:41, Eric Camachat wrote: > I experienced kernel crashes while make world or ports. > For example: > # cd /usr/port/lang/mono > # make > > Will cause the crash, from /var/crash/core.txt: > eb8460p dumped core - see /var/crash/vmcore.5 > > Mon Jul 8 21:22:58 PDT 2013 > > FreeBSD eb8460p 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r253048: Mon Jul 8 > 19:07:18 PDT 2013 root@eb8460p:/u > sr/obj/usr/src/sys/EB8460p amd64 > > panic: ffs_valloc: dup alloc > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > mode = 0100600, inum = 52969060, fs = / > panic: ffs_valloc: dup alloc > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff805fd6d0 at kdb_backtrace+0x60 > #1 0xffffffff805c5b65 at panic+0x155 > #2 0xffffffff807dda6a at ffs_valloc+0x88a > #3 0xffffffff8081a34c at ufs_makeinode+0x7c > #4 0xffffffff808d2872 at VOP_CREATE_APV+0x92 > #5 0xffffffff80670c49 at vn_open_cred+0x2c9 > #6 0xffffffff8066a22f at kern_openat+0x1ef > #7 0xffffffff8085db47 at amd64_syscall+0x357 > #8 0xffffffff808475db at Xfast_syscall+0xfb > Uptime: 6m57s > Dumping 599 out of 3972 > MB:..3%..11%..22%..33%..41%..51%..62%..73%..81%..91% > > Reading symbols from /boot/modules/cuse4bsd.ko...done. > Loaded symbols for /boot/modules/cuse4bsd.ko > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_ubt.ko.symbols > Reading symbols from /boot/kernel/netgraph.ko.symbols...done. > Loaded symbols for /boot/kernel/netgraph.ko.symbols > Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_hci.ko.symbols > Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_bluetooth.ko.symbols > Reading symbols from /boot/kernel/ums.ko.symbols...done. > Loaded symbols for /boot/kernel/ums.ko.symbols > Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_l2cap.ko.symbols > Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_btsocket.ko.symbols > Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_socket.ko.symbols > #0 doadump (textdump=) at pcpu.h:236 > 236 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:236 > #1 0xffffffff805c57e0 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff805c5ba4 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xffffffff807dda6a in ffs_valloc (pvp=, > mode=, cred=, > vpp=) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1022 > #4 0xffffffff8081a34c in ufs_makeinode (mode=, > dvp=0xfffffe011bf44ce8, vpp=0xffffff811ba058d8, > cnp=0xffffff811ba05900) > at /usr/src/sys/ufs/ufs/ufs_vnops.c:2620 > #5 0xffffffff808d2872 in VOP_CREATE_APV (vop=, > a=) at vnode_if.c:265 > #6 0xffffffff80670c49 in vn_open_cred (ndp=0xffffff811ba05880, > flagp=0xffffff811ba0595c, cmode=420, vn_open_flags= out>, > cred=0xfffffe0011fcee00, fp=0xfffffe00110925a0) at vnode_if.h:109 > #7 0xffffffff8066a22f in kern_openat (td=0xfffffe011960f920, > fd=, > path=0x801dbd580
, > pathseg=UIO_USERSPACE, flags=1538, mode=) > at /usr/src/sys/kern/vfs_syscalls.c:1093 > #8 0xffffffff8085db47 in amd64_syscall (td=0xfffffe011960f920, > traced=0) > at subr_syscall.c:134 > #9 0xffffffff808475db in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:391 > #10 0x00000008013a5f2a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > -- > Eric Camachat From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 07:12:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6CFAB43B for ; Tue, 9 Jul 2013 07:12:21 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8281C6A for ; Tue, 9 Jul 2013 07:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=JimxZdsrTc7Nkv239Nb2jMGuaUz3i2wzJLe2vAEm5OA=; b=Hz1LqoDRLVziSz4h6DCYCvszU8h+/GR6iu+PWZRzUKxpJBFSXtuiL38qDrmF0J7PgiSxXt6AgzPOVKyghQQk5wRSTtsCPIsqFVFOE5NHnFZ2/0pIWucO6r+bOzHLEzkZXd6U3e8DjQr1UH/l0MJMlLV0mBka/4nuD68qJttzJtg=; Received: from [39.216.39.205] (port=29938 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UwS5x-003ZIk-4t for freebsd-current@freebsd.org; Tue, 09 Jul 2013 01:12:20 -0600 Date: Tue, 9 Jul 2013 15:12:08 +0800 From: Erich Dollansky To: freebsd-current@freebsd.org Subject: Problem with X, Intel integrated graphics and drm ... Message-ID: <20130709151208.6211db2f@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 07:12:21 -0000 Hi, since I upgraded away from FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: Wed Jul 3 08:45:23 CIT 2013 to FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r253048M: Tue Jul 9 11:21:48 CIT 2013 erich@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 I get this in Xorg.0.log which was not there before: FreeType: couldn't find encoding 'iso8859-13' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADC.TTF' [ 21736.957] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/ahronbd.ttf' [ 21737.124] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/ahronbd.ttf' [ 21758.395] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/amazonen.ttf' [ 21771.138] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/calibriz.ttf' [ 21783.650] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/frank.ttf' [ 21794.146] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/kunstshm.ttf' [ 21829.041] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/kunstshm.ttf' [ 21837.470] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/kunstshm.ttf' [ 21845.380] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/kunstshm.ttf' [ 21850.479] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/ahronbd.ttf' [ 21852.510] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADCI.TTF' [ 21852.520] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/lucon.ttf' [ 21855.945] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADCI.TTF' [ 21867.661] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADCI.TTF' [ 21885.381] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADCI.TTF' [ 21893.325] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADCI.TTF' [ 21893.325] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/lucon.ttf' [ 21902.660] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/palabi.ttf' [ 21906.663] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/palabi.ttf' [ 21910.339] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/palabi.ttf' [ 21917.686] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADCI.TTF' [ 21917.687] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/lucon.ttf' [ 21927.186] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/WindowsFonts/MYRIADCI.TTF' [ 21927.186] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/lucon.ttf' [ 21932.510] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsaz.ttf' [ 21955.685] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsaz.ttf' [ 21961.984] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsaz.ttf' [ 21965.813] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsai.ttf' [ 21970.656] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 21994.783] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 21999.138] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22002.488] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22005.670] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22007.834] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22009.677] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22011.825] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22014.092] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22016.646] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22019.186] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsa.ttf' [ 22021.553] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsai.ttf' [ 22024.664] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsaz.ttf' [ 22040.118] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/angsaz.ttf' [ 22058.881] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/arialbi.ttf' [ 22069.861] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/ariali.ttf' [ 22077.604] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/arial.ttf' [ 22081.942] FreeType: couldn't find encoding 'ascii-0' for '/usr/local/lib/X11/fonts/Windows-7-Fonts/arial.ttf' [ 73475.075] FreeType: couldn't find encoding 'iso8859-13' for'/usr/local/lib/X11/fonts/WindowsFonts/MYRIADC.TTF' [ Erich From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 07:18:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6391E786; Tue, 9 Jul 2013 07:18:36 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 7A73E1CAB; Tue, 9 Jul 2013 07:18:35 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id n57so4447071wev.0 for ; Tue, 09 Jul 2013 00:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mF1kFKl18p9XL2OQNPEyIKgTl/v0g9bX9gdr/NUBGII=; b=BruE2itLsC6bTJRvV8rZE1xpSkd1we5iIg1T6J+u9eYCtuLhBRWTf2Px6UgvqAfTG0 7sgISMNRPHtSPfG3Qw6wky01hpYSIOSsnnCuma+dsZQ7jCUCad4jpRIzT9znliyzzYOW MRlAZ8gVc9hP7blt6Lz2S4YweZTrS8HLp5EN/nA7pa2PERvtO/SkHQaetGbVApnn071+ cExMVK3ec+wL9HHOldvFcHl8tpbY4zLnYZVeKJMavYTHDBh3+Y84b8FlgEvYgELHF7/G 9tj/W2ZOXhZgYVmXfzuv4HSykJE5yF3P+LnZ2EN+a0C73/wBVP/mTdpYjApKeLvzVYc6 9HNg== X-Received: by 10.194.119.228 with SMTP id kx4mr14059095wjb.33.1373354314728; Tue, 09 Jul 2013 00:18:34 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id b20sm27879442wiw.4.2013.07.09.00.18.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 00:18:33 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 9 Jul 2013 09:18:31 +0200 From: Baptiste Daroussin To: Andriy Gapon Subject: Re: new make vs security/vpnc Message-ID: <20130709071831.GF4078@ithaqua.etoilebsd.net> References: <51DB2A10.2030700@FreeBSD.org> <51DB2CEE.2040504@FreeBSD.org> <51DB37AA.1050206@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hUH5gZbnpyIv7Mn4" Content-Disposition: inline In-Reply-To: <51DB37AA.1050206@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-toolchain@FreeBSD.org, freebsd-ports@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 07:18:36 -0000 --hUH5gZbnpyIv7Mn4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 09, 2013 at 01:05:30AM +0300, Andriy Gapon wrote: >=20 > Seems like the problem boils down to this: >=20 > $ make -V MAKEFILE > /usr/ports/security/vpnc/Makefile > $ fmake -V MAKEFILE > Makefile >=20 > The only explicit assignments of MAKEFILE that I could find in ports > infrastructure are these: > /usr/ports/Mk/bsd.port.mk:MAKEFILE?=3D Makefile > /usr/ports/Mk/bsd.gnustep.mk:MAKEFILE=3D GNUmakefile >=20 > --=20 > Andriy Gapon I really can't reproduce it. running a week old head regards, Bapt --hUH5gZbnpyIv7Mn4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHbuUYACgkQ8kTtMUmk6EwktQCgtrLDXmoVVVkaPOeHjDNwhlOo 738An2ITAZLRzDitIHR+yB02MqpfUynk =j3iW -----END PGP SIGNATURE----- --hUH5gZbnpyIv7Mn4-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 07:26:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E24EA3B; Tue, 9 Jul 2013 07:26:32 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by mx1.freebsd.org (Postfix) with ESMTP id 8AAF41D0F; Tue, 9 Jul 2013 07:26:31 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocGALO521FR8a/X/2dsb2JhbABagwkygw6+QYEcF3SCIwEBBVYiARALDgoJFg8JAwIBAgEnHgYNAQcBAYgPuQ+PawcJg2cDkAuBLZdjgxM6 Received: from 215.175-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.175.215]) by relay.skynet.be with ESMTP; 09 Jul 2013 09:25:20 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id r697PJst001149; Tue, 9 Jul 2013 09:25:19 +0200 (CEST) (envelope-from tijl@coosemans.org) Message-ID: <51DBBAD8.7070502@coosemans.org> Date: Tue, 09 Jul 2013 09:25:12 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130701 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: new make vs security/vpnc References: <51DB2A10.2030700@FreeBSD.org> <51DB2CEE.2040504@FreeBSD.org> <51DB37AA.1050206@FreeBSD.org> In-Reply-To: <51DB37AA.1050206@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2JRXQUEPINKVWUIVSOHIX" Cc: freebsd-toolchain@FreeBSD.org, freebsd-ports@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 07:26:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JRXQUEPINKVWUIVSOHIX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-09 00:05, Andriy Gapon wrote: > Seems like the problem boils down to this: >=20 > $ make -V MAKEFILE > /usr/ports/security/vpnc/Makefile > $ fmake -V MAKEFILE > Makefile >=20 > The only explicit assignments of MAKEFILE that I could find in ports > infrastructure are these: > /usr/ports/Mk/bsd.port.mk:MAKEFILE?=3D Makefile > /usr/ports/Mk/bsd.gnustep.mk:MAKEFILE=3D GNUmakefile The problem is probably that .OBJDIR (/usr/obj/usr/ports/security/vpnc) exists. Bmake assigns an absolute path to MAKEFILE in that case. MAKEFILE is an internal variable of make and bsd.port.mk uses it for another purpose. It should use another name like MAKE_FILE imho. ------enig2JRXQUEPINKVWUIVSOHIX 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.20 (FreeBSD) iF4EAREIAAYFAlHbut8ACgkQfoCS2CCgtiu4vwD/WFnifpQJluOitm14dIYT4qmB OFsfnNtr7HvBZl/rR6wA/jfteGBxF7ENWLFifPCzMHWwZsamVLJMCxA41vIP2awh =hwjo -----END PGP SIGNATURE----- ------enig2JRXQUEPINKVWUIVSOHIX-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 07:32:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B602DFF; Tue, 9 Jul 2013 07:32:13 +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 66DC01D6F; Tue, 9 Jul 2013 07:32:12 +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 KAA03695; Tue, 09 Jul 2013 10:32:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UwSPB-000CdS-6w; Tue, 09 Jul 2013 10:32:09 +0300 Message-ID: <51DBBC43.5040703@FreeBSD.org> Date: Tue, 09 Jul 2013 10:31:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: new make vs security/vpnc References: <51DB2A10.2030700@FreeBSD.org> <51DB2CEE.2040504@FreeBSD.org> <51DB37AA.1050206@FreeBSD.org> <51DBBAD8.7070502@coosemans.org> In-Reply-To: <51DBBAD8.7070502@coosemans.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@FreeBSD.org, freebsd-ports@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 07:32:13 -0000 on 09/07/2013 10:25 Tijl Coosemans said the following: > On 2013-07-09 00:05, Andriy Gapon wrote: >> Seems like the problem boils down to this: >> >> $ make -V MAKEFILE /usr/ports/security/vpnc/Makefile $ fmake -V MAKEFILE >> Makefile >> >> The only explicit assignments of MAKEFILE that I could find in ports >> infrastructure are these: /usr/ports/Mk/bsd.port.mk:MAKEFILE?= >> Makefile /usr/ports/Mk/bsd.gnustep.mk:MAKEFILE= GNUmakefile > > The problem is probably that .OBJDIR (/usr/obj/usr/ports/security/vpnc) > exists. Bmake assigns an absolute path to MAKEFILE in that case. Bingo! I use WRKDIRPREFIX=/usr/obj/*ports*, so i am not sure how /usr/obj/usr/ports/security/vpnc came to exist. A timestamp on it is 1 year old, so I won't be able to recall now. Thank you! > MAKEFILE is an internal variable of make and bsd.port.mk uses it for > another purpose. It should use another name like MAKE_FILE imho. I agree. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 08:13:39 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7923CEEF for ; Tue, 9 Jul 2013 08:13:39 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 316221F43 for ; Tue, 9 Jul 2013 08:13:38 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r698DFQ2089234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Jul 2013 08:13:16 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_5A46FA65-E6BA-4461-97EE-481C88DB19C4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: another -Wunsequenced topic From: David Chisnall In-Reply-To: <6AC1186D-3D9C-4B7A-B5E4-4EA9CB120517@kientzle.com> Date: Tue, 9 Jul 2013 09:13:12 +0100 Message-Id: <374FC203-F5FB-4C7C-84D3-76A7AD507D90@FreeBSD.org> References: <51CEEC34.2010308@gmx.com> <51D03D27.3020100@gmx.com> <51DAA5FE.4040505@gmx.com> <6AC1186D-3D9C-4B7A-B5E4-4EA9CB120517@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1503) Cc: dt71@gmx.com, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 08:13:39 -0000 --Apple-Mail=_5A46FA65-E6BA-4461-97EE-481C88DB19C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Jul 2013, at 05:40, Tim Kientzle wrote: > However, this does have an implicit redundant store, > so changing it to >=20 > ptr =3D func(ptr + 1); >=20 > is still a good idea, just not for the reason Clang was claiming. If the compiler can tell that ptr has not escaped, then it will elide = the redundant store (typically, it will be gone as long as ptr is a = local and its address has not been passed out of the function), so there = should be no change to the generated code. However, I still agree that it is good style, because if I read the = original code I would be left wondering what the original programmer = expected the incremented value of ptr++ to be visible to and suspect a = more subtle error. =20 David --Apple-Mail=_5A46FA65-E6BA-4461-97EE-481C88DB19C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR28YYAAoJEKx65DEEsqIdj6gP/jdC6pgahOjH/rP+cKoSuo2p Z5S3BcaFn7d0VNeqFxN29lxfqjvnqwXLcZg2G/p7u4Vkn78sXwUNqX9XjIk5QmVY 5LQ1qez6QLrpPKcmwC3yHaKuiPm0yThy4I/v/sRmEXgkFYw4JMuvOsfq0aWO4guj h7CtRXHkvxH7xx5RY4miWnow76W39IUSZFbidSWYmDydHrzIy/zgBzlQgnWg7NWI GGa6ESM7L7/1EQ61jSSBGxlW39Rfw8qQsBsrpg61rQs/7u/ZpKNpS9x3Cqy7npww eqwCePVa6DeVMYJgd3Lx8TNOR7jND7qjw4GcsLBk5zXK5lkpyK1tVc1AlL4eiEJJ wPiq91SIvwJgoNUT2qGYhlAxrDCqtkucPK46MG2hOD+tAv0FCCZKTcF/VtjA12uP eQnPDwyAIDHDGWJVBuRMny7mMv4jn+TpHIe1D+5NNYkQw8kPUbqCddsRgj3hJfaA og9hoV3EhKEbJTS574XjPw7AQaJrosJR8sRTKcm/fjMbEn7xylw0B0CU+NK/eH9s lQvBWRPwldzYONRq6FCMyaKMSD8U1ZsMQMg82hjN53e16PYU8dZGrkrxFU3OhBWf yFxeqWM5ez0x3YK/3lG7lqgDqzYm3m3IzdLfaogz/4ksdj4uzdObueCfnqVJCRBz 2dfonQ6HcbHM2B5H81/j =qg4B -----END PGP SIGNATURE----- --Apple-Mail=_5A46FA65-E6BA-4461-97EE-481C88DB19C4-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 09:21:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 668A2870 for ; Tue, 9 Jul 2013 09:21:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id E58DD12C8 for ; Tue, 9 Jul 2013 09:21:43 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r699Lbip093385; Tue, 9 Jul 2013 13:21:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r699La1I093384; Tue, 9 Jul 2013 13:21:36 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 9 Jul 2013 13:21:36 +0400 From: Gleb Smirnoff To: Cy Schubert Subject: Re: Ipfilter pre-Vendor Import Issue Message-ID: <20130709092136.GL67810@glebius.int.ru> References: <20130708134400.GH67810@glebius.int.ru> <201307082000.r68K02Ef063517@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201307082000.r68K02Ef063517@slippy.cwsent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 09:21:45 -0000 On Mon, Jul 08, 2013 at 01:00:02PM -0700, Cy Schubert wrote: C> > The BSD license allows us to put the code into FreeBSD w/o any separation. C> > C> > So the question is: what is more handy to us? C> > C> > What do we actually gain having contrib/ipf, assuming we got vendor branch C> > already? C> > C> > What we lose is: C> > - more complex Makefiles C> > - more complex hacking: edit files in one place, run make in other C> C> How is this for a plan? C> C> Instead of importing the kernel bits into vendor-sys/ipfilter and the C> userland bits into vendor/ipfilter, the base tarball should be imported C> into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We C> keep the complete tarball imported into one place in the tree. I'd prefer vendor/ipfilter as single place of vendor imports. C> Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and C> netpfil/ipfilter (for userland bits). C> C> We should probably think of moving pf and ipfw into the new subdirectory as C> well, but that's for a future discussion. No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin, according to the place where they are installed. An exlusion can be made adding a intermediate subdir (like this is already done for ipfilter tools), to group all related tools together. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 12:21:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1F52E07; Tue, 9 Jul 2013 12:21:50 +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 CABF51C9E; Tue, 9 Jul 2013 12:21:50 +0000 (UTC) Received: from Julian-MBP3.local (124-169-161-9.dyn.iinet.net.au [124.169.161.9]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r69CLjCM011827 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 9 Jul 2013 05:21:49 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51DC0054.2040703@freebsd.org> Date: Tue, 09 Jul 2013 20:21:40 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current , Jamie Gritton Subject: chroots/jails in jails Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 12:21:51 -0000 I'm making a build system for a project which creates a chroot in which to do some of the building to avoid base-system contamination (yeah I know lots of people do that). the trick is that my test system is itself, a jail. So I can not mount /dev in the chroot. I can not predict where a build will occur so I can not pre-mount the devfs from outside the jail. (users may fire off builds in different locations) Does anyone have any solution to this problem? We have hierarchical jails, but no way of allowing the parent jail to give the child jail a devfs. Has anyone looked at what it would take to make devfs "jail friendly"? I'm guessing that the jail would have to get some devfs-rule parameter and that mount_devfs or it's in-kernel parts would have to know what to do.. seems like there should be someone out there who has hit this.. (and solved it?) Julian From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 12:43:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CA3358E for ; Tue, 9 Jul 2013 12:43:52 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 226DB1DA1 for ; Tue, 9 Jul 2013 12:43:51 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 32137206D1 for ; Tue, 9 Jul 2013 08:43:51 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 09 Jul 2013 08:43:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=juJanUOcVUD77TItIJuB5jzWjY4=; b=nVpsVNyrQ1hmMDiXbnVCU aVqCdmnzRqEzXAIsszOLWbuQRE37HXYSSfMPaP0DNTxm5kSXQqvfbHGniORD8ZiA IHTIhYTksAAAmLWe58Tk/RN1cNBUrS3U3abAiXMLUWvYWhyPjXgg8tgaFdvI9v4l YEvXycofXXks2Po0+Iivs0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:subject:references:date :mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=juJanUOcVUD77TItIJuB5jzWjY4=; b=c8Gv 00meamXUT1bhPjp3jw0f1pMzduWzLu/tfANXxy+FQlZCl+f+32WfVaIkugLYQUmf 56FM/KoeAEd5BrSMk5x3nvN8njIUng3ki56yR9wjDqtN8Tl5ScvEe7zNAXqZz//d 3sUgI8ebeBsPyXHu0cxsa8AUqSp/xVnzzIOhgl8= X-Sasl-enc: f7QimEcCWGUTcwpq8dYmZA/qEz+v8QSsK14PbcwGGmia 1373373831 Received: from markf.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id F21A3C00E82 for ; Tue, 9 Jul 2013 08:43:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-current@freebsd.org Subject: Re: chroots/jails in jails References: <51DC0054.2040703@freebsd.org> Date: Tue, 09 Jul 2013 07:43:50 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <51DC0054.2040703@freebsd.org> User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 12:43:52 -0000 On Tue, 09 Jul 2013 07:21:40 -0500, Julian Elischer wrote: > seems like there should be someone out there who has hit this.. (and > solved it?) Poudriere can itself be run in a jail... does it do hierarchical jails? I've never tested it myself. Bapt's loose documentation of it is here: https://fossil.etoilebsd.net/poudriere/doc/trunk/doc/poudriere_in_jail.wiki From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 12:44:01 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33390693; Tue, 9 Jul 2013 12:44:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 19D3E1DA7; Tue, 9 Jul 2013 12:43:59 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r69ChfSf071934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jul 2013 21:43:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r69CheHl062755; Tue, 9 Jul 2013 21:43:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 09 Jul 2013 21:42:28 +0900 (JST) Message-Id: <20130709.214228.1702026470722804811.hrs@allbsd.org> To: julian@FreeBSD.org Subject: Re: chroots/jails in jails From: Hiroki Sato In-Reply-To: <51DC0054.2040703@freebsd.org> References: <51DC0054.2040703@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Jul__9_21_42_28_2013_084)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 09 Jul 2013 21:43:52 +0900 (JST) X-Spam-Status: No, score=-89.1 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,QENCPTR1,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: current@FreeBSD.org, jamie@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 12:44:01 -0000 ----Security_Multipart(Tue_Jul__9_21_42_28_2013_084)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Elischer wrote in <51DC0054.2040703@freebsd.org>: ju> I'm making a build system for a project which creates a chroot in ju> which to do some of the building to avoid base-system contamination ju> (yeah I know lots of people do that). ju> the trick is that my test system is itself, a jail. ju> So I can not mount /dev in the chroot. ju> ju> I can not predict where a build will occur so I can not pre-mount the ju> devfs from outside the jail. (users may fire off builds in different ju> locations) ju> ju> Does anyone have any solution to this problem? ju> ju> We have hierarchical jails, but no way of allowing the parent jail to ju> give the child jail a devfs. ju> ju> Has anyone looked at what it would take to make devfs "jail friendly"? ju> ju> I'm guessing that the jail would have to get some devfs-rule parameter ju> and that mount_devfs or it's in-kernel parts would have to know what ju> to do.. ju> ju> seems like there should be someone out there who has hit this.. (and ju> solved it?) Allowing to mount devfs inside hierarchical jails should work like the following: # jail -c allow.mount.devfs=1 allow.mount=1 enforce_statfs=1 children.max=10 path=/ name=j1 persist # jexec j1 /bin/tcsh # mkdir /tmp/dev1 # mount -t devfs devfs /tmp/dev1 # jail -c allow.mount.devfs=1 allow.mount=1 enforce_statfs=1 path=/ name=j2 persist # jexec j2 /bin/tcsh # mkdir /tmp/dev2 # mount -t devfs devfs /tmp/dev2 -- Hiroki ----Security_Multipart(Tue_Jul__9_21_42_28_2013_084)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHcBTQACgkQTyzT2CeTzy1EpwCfUsApw7x8v/GO6Z7DWYIRXpQn yjIAoM1nx4Q1BBGwV6Qt7wjyzqfF7D1R =sncX -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Jul__9_21_42_28_2013_084)---- From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 12:47:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D8677D6 for ; Tue, 9 Jul 2013 12:47:59 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id DBAA51DD1 for ; Tue, 9 Jul 2013 12:47:58 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 93B9B20B36 for ; Tue, 9 Jul 2013 08:47:58 -0400 (EDT) Received: from web5.nyi.mail.srv.osa ([10.202.2.215]) by compute2.internal (MEProxy); Tue, 09 Jul 2013 08:47:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:reply-to:date :in-reply-to:references; s=smtpout; bh=FF+ZtMPLuibhyLzmmqGtyZA9Y ZM=; b=saOWbGuD9KTK18dju6djd8myiEtm0ztQX1GuhN56oqBLX1umBXRXlX5zQ 6KZoSqNz144KbbCoFfVk01M3jbqEbOv+4Soayyv1xzUzyW4RxVik2ndhvIZwXuyu km42JhMHED7N/F8G8aTj6wzUc3YZ32xXTXOl2W4Sacy7KMwWfU= Received: by web5.nyi.mail.srv.osa (Postfix, from userid 99) id 667471613C9; Tue, 9 Jul 2013 08:47:58 -0400 (EDT) Message-Id: <1373374078.28355.140661253573118.7D24AA96@webmail.messagingengine.com> X-Sasl-Enc: YSYehlF8Od0YnH0wmEQsdXoBcqRT+z3zAF3/Y7Dr33Sj 1373374078 From: Darren Reed To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cea5092a Subject: Re: Ipfilter pre-Vendor Import Issue Date: Tue, 09 Jul 2013 14:47:58 +0200 In-Reply-To: <51DA85CF.3000401@freebsd.org> References: <201307051838.r65IcL2Q005119@slippy.cwsent.com> <51DA85CF.3000401@freebsd.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@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, 09 Jul 2013 12:47:59 -0000 On Mon, Jul 8, 2013, at 11:26 AM, Andre Oppermann wrote: > I think the main distinction here is whether the adaptions to > FreeBSD are kept local (resulting in almost a fork) or are fed > upstream so that successive updates require less or no local > changes. > > Having the kernel part in sys/netpfil certainly makes it easier > for kernel people to adjust it to changed realities. > > IIRC ipfilter also has very messy ifdef's all over the place for > every possible ancient version of FreeBSD. This probably should > be cleaned up (and upstreamed) as well. At one point in time, I believed that this was the right thing to do as it allowed new code to work with older systems. That was back when there was little ifdef's... now it is #ifdef hell. However almost nobody cares about this so at some point in the future, I'll join with the masses and new versions or patches will just work with the latest whatever. If the code being imported removed lots of ifdef code that is irrelevant, I don't think anyone will be upset... Cheers, Darren From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 12:50:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D12E91D for ; Tue, 9 Jul 2013 12:50:31 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 664CD1DF9 for ; Tue, 9 Jul 2013 12:50:31 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0546920FA8 for ; Tue, 9 Jul 2013 08:50:31 -0400 (EDT) Received: from web5.nyi.mail.srv.osa ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 09 Jul 2013 08:50:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:reply-to:date :in-reply-to:references; s=smtpout; bh=IMg/E9UP1qlF7ZCJm0gWWwL1K EU=; b=DHAio4qerW8CVRAHagaW+16HuEq27HVQN98OBQZs4hGWaIB+vvmZk0BJI 9oTnMW21lJ6YKMw5qP5fo7HhQnR1yEtTqTMkmKVQpWOjx7/GiaBmX8/UKYDBFQMr jszF7Oioz5PKf0exxAc4KoIDkQBnGsdrHY9SZFlrqy2Vfm7q90= Received: by web5.nyi.mail.srv.osa (Postfix, from userid 99) id D79891613C8; Tue, 9 Jul 2013 08:50:30 -0400 (EDT) Message-Id: <1373374230.28930.140661253574002.7D123D20@webmail.messagingengine.com> X-Sasl-Enc: 4HWjJ08r3f0iv819b86ibJLb6rffavxh1GPJknzhQJjE 1373374230 From: Darren Reed To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cea5092a Subject: Re: Ipfilter pre-Vendor Import Issue Date: Tue, 09 Jul 2013 14:50:30 +0200 In-Reply-To: <20130709092136.GL67810@glebius.int.ru> References: <20130708134400.GH67810@glebius.int.ru> <201307082000.r68K02Ef063517@slippy.cwsent.com> <20130709092136.GL67810@glebius.int.ru> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@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, 09 Jul 2013 12:50:31 -0000 On Tue, Jul 9, 2013, at 11:21 AM, Gleb Smirnoff wrote: ... > No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin, > according to the place where they are installed. An exlusion can be made > adding a intermediate subdir (like this is already done for ipfilter > tools), > to group all related tools together. The structure NetBSD have adopted for vendor code is to have (for example) src/usr.sbin/ipf and for the Makefiles to reference the vendor code in src/dist/ipfilter. Do you see that working for FreeBSD or would you prefer to have source code live with Makefiles? Cheers, Darren From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 13:03:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6CEAFD0; Tue, 9 Jul 2013 13:03:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF3A1EAC; Tue, 9 Jul 2013 13:03:58 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 5so2999404qeb.31 for ; Tue, 09 Jul 2013 06:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=v6dXmHtkO65ny6FVKgySzmqEPWEhI0hhz94ihD4RwZY=; b=ObPJCUxozMhMf0Q33Ed/ZLHI2BXytmJLyHq0pEF58T9UC8TAP5ce3CrVQ7aczKDGc2 Kw4d3jUlV68kRqXDLF911jMF+oBOQ1yPl6c8Lz/cW2+MpukH1r50npc9sY8+Gf9Kc8Hq +1eUv2VO4UzY6DIPL9JWAeLn6IkbidwAMTuAgrlYmcIDZmYBeGBEIgeqDFDpySOyAExH vfjcqEO09LUNapwJ+7dS90cbcKwHSeNrAgTybpDsq7dEP5eZzVTVduzo4J8mwMf/IsvB iD/7O7XXB5sW/cV3m2s3HLrTp2FjtAgCS1jh6GtdKvwhgFOxrCM0xN3B3OOi1O4hbOgn c3Yw== MIME-Version: 1.0 X-Received: by 10.224.13.19 with SMTP id z19mr23377106qaz.12.1373375038092; Tue, 09 Jul 2013 06:03:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Tue, 9 Jul 2013 06:03:58 -0700 (PDT) Date: Tue, 9 Jul 2013 06:03:58 -0700 X-Google-Sender-Auth: 7ibDvLFRUe6vBywUWbbUlGnDlIw Message-ID: Subject: Deadlock in nullfs/zfs somewhere From: Adrian Chadd To: freebsd-current , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 13:03:58 -0000 Hi all, I'm doing some -10 i386/amd64 package builds on a 32-core build server running: FreeBSD vm0.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r252897: Sat Jul 6 23:16:03 UTC 2013 sbruno@vm0.freebsd.org:/usr/obj/usr/src/sys/VM0 amd64 And I hit a deadlock: Unread portion of the kernel message buffer: panic: deadlkres: possible deadlock detected for 0xfffffe00adc2a920, blocked for 1800101 ticks (kgdb) tid 100874 [Switching to thread 799 (Thread 100874)]#0 sched_switch (td=0xfffffe00adc2a920, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1954 1954 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xfffffe00adc2a920, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1954 #1 0xffffffff804e70ee in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0xffffffff8052150a in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0xffffffff804c2abc in sleeplk (lk=, flags=524544, ilk=, wmesg=0xffffffff80f1b89a "zfs", pri=, timo=) at /usr/src/sys/kern/kern_lock.c:226 #4 0xffffffff804c22f5 in __lockmgr_args (lk=0xfffffe00ad56a068, flags=, ilk=0xfffffe00ad56a098, wmesg=0xffffffff80f1b89a "zfs", pri=96, timo=51, line=) at /usr/src/sys/kern/kern_lock.c:919 #5 0xffffffff8056a26c in vop_stdlock (ap=) at lockmgr.h:97 #6 0xffffffff80790ded in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2084 #7 0xffffffff805891a3 in _vn_lock (vp=0xfffffe00ad56a000, flags=, file=0xffffffff807fb89e "/usr/src/sys/kern/vfs_subr.c", line=2099) at vnode_if.h:859 #8 0xffffffff805791aa in vget (vp=0xfffffe00ad56a000, flags=524544, td=0xfffffe00adc2a920) at /usr/src/sys/kern/vfs_subr.c:2099 #9 0xffffffff805664b2 in cache_lookup (dvp=0xfffffe00ad4e1588, vpp=0xffffff9049b29188, cnp=0xffffff9049b295a0, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:674 #10 0xffffffff80567651 in vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:1033 #11 0xffffffff8078efa2 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:129 #12 0xffffffff8126714b in null_lookup (ap=0xffffff9049b29248) at vnode_if.h:54 #13 0xffffffff8078efa2 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:129 #14 0xffffffff8056f6eb in lookup (ndp=0xffffff9049b29520) at vnode_if.h:54 #15 0xffffffff8056ee84 in namei (ndp=0xffffff9049b29520) at /usr/src/sys/kern/vfs_lookup.c:292 #16 0xffffffff80588952 in vn_open_cred (ndp=0xffffff9049b29520, flagp=0xffffff9049b296a0, cmode=0, vn_open_flags=, cred=0xfffffe071c32a900, fp=0x0) at /usr/src/sys/kern/vfs_vnops.c:202 #17 0xffffffff8056a774 in vop_stdvptocnp (ap=) at /usr/src/sys/kern/vfs_default.c:797 #18 0xffffffff81267a1b in null_vptocnp (ap=0xffffff9049b29878) at /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:824 #19 0xffffffff80792628 in VOP_VPTOCNP_APV (vop=, a=) at vnode_if.c:3649 #20 0xffffffff80567ee3 in vn_vptocnp_locked (vp=0xffffff9049b29900, cred=0xfffffe071c32a900, buf=0xfffffe00ad708800 "", buflen=0xffffff9049b298fc) at vnode_if.h:1564 #21 0xffffffff80567a02 in vn_fullpath1 (td=0xfffffe00adc2a920, vp=0xfffffe03ec1d5ce8, rdir=0xfffffe071b898760, buf=0xfffffe00ad708800 "", retbuf=0xffffff9049b29960, buflen=1004) at /usr/src/sys/kern/vfs_cache.c:1325 #22 0xffffffff805677b5 in kern___getcwd (td=0xfffffe00adc2a920, buf=0x80dd3d4
, bufseg=UIO_USERSPACE, buflen=Cannot access memory at address 0x400 ) at /usr/src/sys/kern/vfs_cache.c:1089 #23 0xffffffff8076554c in ia32_syscall (frame=0xffffff9049b29ac0) at subr_syscall.c:134 #24 0xffffffff807227a5 in Xint0x80_syscall () at ia32_exception.S:73 #25 0x0000000008072c33 in ?? () Previous frame inner to this frame (corrupt stack?) .. and it's here: (kgdb) sleepchain 100874 thread 100874 (pid 75371, make) blocked on lk "zfs" SHARED (count 2) Now, this system doesn't have witness (yet!), so a bunch more hoops need to be jumped through to figure out what else is blocking on that particular lock. Does anyone have any ideas as to what's going on? Or has it been fixed over the last couple days and I haven't noticed? Thanks! -adrian From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 13:15:40 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 215AF43D; Tue, 9 Jul 2013 13:15: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 EDC3F1F42; Tue, 9 Jul 2013 13:15:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69DFWVc069397; Tue, 9 Jul 2013 09:15:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69DFWRr069360; Tue, 9 Jul 2013 13:15:32 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 13:15:32 GMT Message-Id: <201307091315.r69DFWRr069360@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:15:40 -0000 TB --- 2013-07-09 10:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 10:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 10:10:19 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-09 10:10:19 - cleaning the object tree TB --- 2013-07-09 10:11:19 - /usr/local/bin/svn stat /src TB --- 2013-07-09 10:11:22 - At svn revision 253088 TB --- 2013-07-09 10:11:23 - building world TB --- 2013-07-09 10:11:23 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 10:11:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 10:11:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 10:11:23 - SRCCONF=/dev/null TB --- 2013-07-09 10:11:23 - TARGET=arm TB --- 2013-07-09 10:11:23 - TARGET_ARCH=armv6 TB --- 2013-07-09 10:11:23 - TZ=UTC TB --- 2013-07-09 10:11:23 - __MAKE_CONF=/dev/null TB --- 2013-07-09 10:11:23 - cd /src TB --- 2013-07-09 10:11:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 10:11:30 UTC 2013 >>> 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 Jul 9 13:13:30 UTC 2013 TB --- 2013-07-09 13:13:30 - generating LINT kernel config TB --- 2013-07-09 13:13:30 - cd /src/sys/arm/conf TB --- 2013-07-09 13:13:30 - /usr/bin/make -B LINT TB --- 2013-07-09 13:13:30 - cd /src/sys/arm/conf TB --- 2013-07-09 13:13:30 - /usr/sbin/config -m LINT TB --- 2013-07-09 13:13:30 - skipping LINT kernel TB --- 2013-07-09 13:13:30 - cd /src/sys/arm/conf TB --- 2013-07-09 13:13:30 - /usr/sbin/config -m AC100 TB --- 2013-07-09 13:13:30 - building AC100 kernel TB --- 2013-07-09 13:13:30 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:13:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:13:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:13:30 - SRCCONF=/dev/null TB --- 2013-07-09 13:13:30 - TARGET=arm TB --- 2013-07-09 13:13:30 - TARGET_ARCH=armv6 TB --- 2013-07-09 13:13:30 - TZ=UTC TB --- 2013-07-09 13:13:30 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:13:30 - cd /src TB --- 2013-07-09 13:13:30 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Tue Jul 9 13:13:30 UTC 2013 >>> 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/net/vnet.h:127:2: note: expanded from macro 'SYSCTL_VNET_PCPUSTAT' CTASSERT(sizeof(type) == sizeof(VNET(array))); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") ^ ~ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 13:15:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 13:15:32 - ERROR: failed to build AC100 kernel TB --- 2013-07-09 13:15:32 - 8884.13 user 1516.02 system 11112.82 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 13:24:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE2C282F; Tue, 9 Jul 2013 13:24: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 B42FA1FB8; Tue, 9 Jul 2013 13:24:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69DObpg025341; Tue, 9 Jul 2013 09:24:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69DOb6Z025339; Tue, 9 Jul 2013 13:24:37 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 13:24:37 GMT Message-Id: <201307091324.r69DOb6Z025339@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:24:38 -0000 TB --- 2013-07-09 10:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 10:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 10:10:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-09 10:10:19 - cleaning the object tree TB --- 2013-07-09 10:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-09 10:10:24 - At svn revision 253088 TB --- 2013-07-09 10:10:25 - building world TB --- 2013-07-09 10:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 10:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 10:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 10:10:25 - SRCCONF=/dev/null TB --- 2013-07-09 10:10:25 - TARGET=arm TB --- 2013-07-09 10:10:25 - TARGET_ARCH=arm TB --- 2013-07-09 10:10:25 - TZ=UTC TB --- 2013-07-09 10:10:25 - __MAKE_CONF=/dev/null TB --- 2013-07-09 10:10:25 - cd /src TB --- 2013-07-09 10:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 10:10:33 UTC 2013 >>> 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 Jul 9 13:11:49 UTC 2013 TB --- 2013-07-09 13:11:49 - generating LINT kernel config TB --- 2013-07-09 13:11:49 - cd /src/sys/arm/conf TB --- 2013-07-09 13:11:49 - /usr/bin/make -B LINT TB --- 2013-07-09 13:11:49 - cd /src/sys/arm/conf TB --- 2013-07-09 13:11:49 - /usr/sbin/config -m LINT TB --- 2013-07-09 13:11:49 - building LINT kernel TB --- 2013-07-09 13:11:49 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:11:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:11:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:11:49 - SRCCONF=/dev/null TB --- 2013-07-09 13:11:49 - TARGET=arm TB --- 2013-07-09 13:11:49 - TARGET_ARCH=arm TB --- 2013-07-09 13:11:49 - TZ=UTC TB --- 2013-07-09 13:11:49 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:11:49 - cd /src TB --- 2013-07-09 13:11:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 13:11:49 UTC 2013 >>> 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/net/vnet.h:127:2: note: expanded from macro 'SYSCTL_VNET_PCPUSTAT' CTASSERT(sizeof(type) == sizeof(VNET(array))); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") ^ ~ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 13:24:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 13:24:37 - ERROR: failed to build LINT kernel TB --- 2013-07-09 13:24:37 - 9212.61 user 1629.68 system 11658.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 13:32:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13BA9BB0; Tue, 9 Jul 2013 13:32:18 +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 DFEED1034; Tue, 9 Jul 2013 13:32:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69DWH0U073241; Tue, 9 Jul 2013 09:32:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69DWHtH073238; Tue, 9 Jul 2013 13:32:17 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 13:32:17 GMT Message-Id: <201307091332.r69DWHtH073238@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:32:18 -0000 TB --- 2013-07-09 10:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 10:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 10:10:19 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-09 10:10:19 - cleaning the object tree TB --- 2013-07-09 10:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-09 10:10:23 - At svn revision 253088 TB --- 2013-07-09 10:10:24 - building world TB --- 2013-07-09 10:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 10:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 10:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 10:10:24 - SRCCONF=/dev/null TB --- 2013-07-09 10:10:24 - TARGET=i386 TB --- 2013-07-09 10:10:24 - TARGET_ARCH=i386 TB --- 2013-07-09 10:10:24 - TZ=UTC TB --- 2013-07-09 10:10:24 - __MAKE_CONF=/dev/null TB --- 2013-07-09 10:10:24 - cd /src TB --- 2013-07-09 10:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 10:10:33 UTC 2013 >>> 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 Jul 9 13:22:16 UTC 2013 TB --- 2013-07-09 13:22:16 - generating LINT kernel config TB --- 2013-07-09 13:22:16 - cd /src/sys/i386/conf TB --- 2013-07-09 13:22:16 - /usr/bin/make -B LINT TB --- 2013-07-09 13:22:16 - cd /src/sys/i386/conf TB --- 2013-07-09 13:22:16 - /usr/sbin/config -m LINT TB --- 2013-07-09 13:22:16 - building LINT kernel TB --- 2013-07-09 13:22:16 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:22:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:22:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:22:16 - SRCCONF=/dev/null TB --- 2013-07-09 13:22:16 - TARGET=i386 TB --- 2013-07-09 13:22:16 - TARGET_ARCH=i386 TB --- 2013-07-09 13:22:16 - TZ=UTC TB --- 2013-07-09 13:22:16 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:22:16 - cd /src TB --- 2013-07-09 13:22:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 13:22:16 UTC 2013 >>> 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 [...] In file included from /src/sys/dev/ixgb/if_ixgb.h:83: /src/sys/dev/ixgb/ixgb_ids.h:43:9: error: 'INTEL_VENDOR_ID' macro redefined [-Werror] #define INTEL_VENDOR_ID 0x8086 ^ ./x86/specialreg.h:304:9: note: previous definition is here #define INTEL_VENDOR_ID "GenuineIntel" ^ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 13:32:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 13:32:17 - ERROR: failed to build LINT kernel TB --- 2013-07-09 13:32:17 - 9812.70 user 1669.30 system 12117.47 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 13:41:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A0D5F83; Tue, 9 Jul 2013 13:41:12 +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 614E810A9; Tue, 9 Jul 2013 13:41:12 +0000 (UTC) Received: from Julian-MBP3.local (124-169-161-9.dyn.iinet.net.au [124.169.161.9]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r69Df7AG012051 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 9 Jul 2013 06:41:10 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51DC12ED.1050105@freebsd.org> Date: Tue, 09 Jul 2013 21:41:01 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hiroki Sato Subject: Re: chroots/jails in jails References: <51DC0054.2040703@freebsd.org> <20130709.214228.1702026470722804811.hrs@allbsd.org> In-Reply-To: <20130709.214228.1702026470722804811.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, jamie@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 13:41:12 -0000 On 7/9/13 8:42 PM, Hiroki Sato wrote: > Julian Elischer wrote > in <51DC0054.2040703@freebsd.org>: it occurs to me that the machine on which the jail is on is running 8.0 and maybe this was fixed since.. I guess I should have checked that first. > > ju> I'm making a build system for a project which creates a chroot in > ju> which to do some of the building to avoid base-system contamination > ju> (yeah I know lots of people do that). > ju> the trick is that my test system is itself, a jail. > ju> So I can not mount /dev in the chroot. > ju> > ju> I can not predict where a build will occur so I can not pre-mount the > ju> devfs from outside the jail. (users may fire off builds in different > ju> locations) > ju> > ju> Does anyone have any solution to this problem? > ju> > ju> We have hierarchical jails, but no way of allowing the parent jail to > ju> give the child jail a devfs. > ju> > ju> Has anyone looked at what it would take to make devfs "jail friendly"? > ju> > ju> I'm guessing that the jail would have to get some devfs-rule parameter > ju> and that mount_devfs or it's in-kernel parts would have to know what > ju> to do.. > ju> > ju> seems like there should be someone out there who has hit this.. (and > ju> solved it?) > > Allowing to mount devfs inside hierarchical jails should work like > the following: > > # jail -c allow.mount.devfs=1 allow.mount=1 enforce_statfs=1 children.max=10 path=/ name=j1 persist > # jexec j1 /bin/tcsh > # mkdir /tmp/dev1 > # mount -t devfs devfs /tmp/dev1 > # jail -c allow.mount.devfs=1 allow.mount=1 enforce_statfs=1 path=/ name=j2 persist > # jexec j2 /bin/tcsh > # mkdir /tmp/dev2 > # mount -t devfs devfs /tmp/dev2 > > -- Hiroki From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 14:12:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04757831; Tue, 9 Jul 2013 14:12:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD10B1219; Tue, 9 Jul 2013 14:12:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69ECCqF003064; Tue, 9 Jul 2013 10:12:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69ECCA1003063; Tue, 9 Jul 2013 14:12:12 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 14:12:12 GMT Message-Id: <201307091412.r69ECCA1003063@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:12:13 -0000 TB --- 2013-07-09 10:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 10:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 10:10:19 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-09 10:10:19 - cleaning the object tree TB --- 2013-07-09 10:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-09 10:10:23 - At svn revision 253088 TB --- 2013-07-09 10:10:24 - building world TB --- 2013-07-09 10:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 10:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 10:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 10:10:24 - SRCCONF=/dev/null TB --- 2013-07-09 10:10:24 - TARGET=amd64 TB --- 2013-07-09 10:10:24 - TARGET_ARCH=amd64 TB --- 2013-07-09 10:10:24 - TZ=UTC TB --- 2013-07-09 10:10:24 - __MAKE_CONF=/dev/null TB --- 2013-07-09 10:10:24 - cd /src TB --- 2013-07-09 10:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 10:10:33 UTC 2013 >>> 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 Jul 9 13:57:07 UTC 2013 TB --- 2013-07-09 13:57:07 - generating LINT kernel config TB --- 2013-07-09 13:57:07 - cd /src/sys/amd64/conf TB --- 2013-07-09 13:57:07 - /usr/bin/make -B LINT TB --- 2013-07-09 13:57:07 - cd /src/sys/amd64/conf TB --- 2013-07-09 13:57:07 - /usr/sbin/config -m LINT TB --- 2013-07-09 13:57:07 - building LINT kernel TB --- 2013-07-09 13:57:07 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:57:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:57:07 - SRCCONF=/dev/null TB --- 2013-07-09 13:57:07 - TARGET=amd64 TB --- 2013-07-09 13:57:07 - TARGET_ARCH=amd64 TB --- 2013-07-09 13:57:07 - TZ=UTC TB --- 2013-07-09 13:57:07 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:57:07 - cd /src TB --- 2013-07-09 13:57:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 13:57:07 UTC 2013 >>> 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/net/vnet.h:440:37: note: expanded from macro 'VNET_DECLARE' #define VNET_DECLARE(t, n) extern t n ^ /src/sys/netinet/sctp_input.c:5717:30: error: member reference base type 'counter_u64_t [1570]' is not a structure or union MODULE_GLOBAL(ipsec6stat).in_polvio++; ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ 4 errors generated. *** Error code 1 Stop. make: stopped in /obj/amd64.amd64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 14:12:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 14:12:11 - ERROR: failed to build LINT kernel TB --- 2013-07-09 14:12:11 - 11533.05 user 2076.41 system 14512.22 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 14:35:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36683E77; Tue, 9 Jul 2013 14:35:27 +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 48C021345; Tue, 9 Jul 2013 14:35:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69EZPvi027628; Tue, 9 Jul 2013 10:35:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69EZPZ5027626; Tue, 9 Jul 2013 14:35:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 14:35:25 GMT Message-Id: <201307091435.r69EZPZ5027626@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 , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:35:27 -0000 TB --- 2013-07-09 13:32:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 13:32:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 13:32:17 - starting HEAD tinderbox run for mips/mips TB --- 2013-07-09 13:32:17 - cleaning the object tree TB --- 2013-07-09 13:32:17 - /usr/local/bin/svn stat /src TB --- 2013-07-09 13:32:20 - At svn revision 253088 TB --- 2013-07-09 13:32:21 - building world TB --- 2013-07-09 13:32:21 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:32:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:32:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:32:21 - SRCCONF=/dev/null TB --- 2013-07-09 13:32:21 - TARGET=mips TB --- 2013-07-09 13:32:21 - TARGET_ARCH=mips TB --- 2013-07-09 13:32:21 - TZ=UTC TB --- 2013-07-09 13:32:21 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:32:21 - cd /src TB --- 2013-07-09 13:32:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 13:32:28 UTC 2013 >>> 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 Jul 9 14:32:43 UTC 2013 TB --- 2013-07-09 14:32:43 - cd /src/sys/mips/conf TB --- 2013-07-09 14:32:43 - /usr/sbin/config -m ADM5120 TB --- 2013-07-09 14:32:43 - skipping ADM5120 kernel TB --- 2013-07-09 14:32:43 - cd /src/sys/mips/conf TB --- 2013-07-09 14:32:43 - /usr/sbin/config -m ALCHEMY TB --- 2013-07-09 14:32:43 - skipping ALCHEMY kernel TB --- 2013-07-09 14:32:43 - cd /src/sys/mips/conf TB --- 2013-07-09 14:32:43 - /usr/sbin/config -m AP121 TB --- 2013-07-09 14:32:43 - building AP121 kernel TB --- 2013-07-09 14:32:43 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 14:32:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 14:32:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 14:32:43 - SRCCONF=/dev/null TB --- 2013-07-09 14:32:43 - TARGET=mips TB --- 2013-07-09 14:32:43 - TARGET_ARCH=mips TB --- 2013-07-09 14:32:43 - TZ=UTC TB --- 2013-07-09 14:32:43 - __MAKE_CONF=/dev/null TB --- 2013-07-09 14:32:43 - cd /src TB --- 2013-07-09 14:32:43 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Tue Jul 9 14:32:44 UTC 2013 >>> 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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/net80211/ieee80211_superg.c 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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/net80211/ieee80211_tdma.c 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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/net80211/ieee80211_wds.c 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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/net80211/ieee80211_xauth.c 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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/net80211/ieee80211_alq.c 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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/netinet/if_ether.c /src/sys/netinet/if_ether.c: In function 'arpstat_sysctl': /src/sys/netinet/if_ether.c:122: error: size of array '__assert_3' is negative *** Error code 1 Stop. make: stopped in /obj/mips.mips/src/sys/AP121 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 14:35:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 14:35:25 - ERROR: failed to build AP121 kernel TB --- 2013-07-09 14:35:25 - 2748.83 user 651.13 system 3787.66 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 15:17:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6ECAEAA; Tue, 9 Jul 2013 15:17: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 BE59F1737; Tue, 9 Jul 2013 15:17:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69FHbXf052167; Tue, 9 Jul 2013 11:17:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69FHbmA052166; Tue, 9 Jul 2013 15:17:37 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 15:17:37 GMT Message-Id: <201307091517.r69FHbmA052166@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:17:38 -0000 TB --- 2013-07-09 13:24:38 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 13:24:38 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 13:24:38 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-07-09 13:24:38 - cleaning the object tree TB --- 2013-07-09 13:24:38 - /usr/local/bin/svn stat /src TB --- 2013-07-09 13:24:41 - At svn revision 253088 TB --- 2013-07-09 13:24:42 - building world TB --- 2013-07-09 13:24:42 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:24:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:24:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:24:42 - SRCCONF=/dev/null TB --- 2013-07-09 13:24:42 - TARGET=ia64 TB --- 2013-07-09 13:24:42 - TARGET_ARCH=ia64 TB --- 2013-07-09 13:24:42 - TZ=UTC TB --- 2013-07-09 13:24:42 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:24:42 - cd /src TB --- 2013-07-09 13:24:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 13:24:50 UTC 2013 >>> 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 Jul 9 15:00:13 UTC 2013 TB --- 2013-07-09 15:00:13 - generating LINT kernel config TB --- 2013-07-09 15:00:13 - cd /src/sys/ia64/conf TB --- 2013-07-09 15:00:13 - /usr/bin/make -B LINT TB --- 2013-07-09 15:00:13 - cd /src/sys/ia64/conf TB --- 2013-07-09 15:00:13 - /usr/sbin/config -m LINT TB --- 2013-07-09 15:00:14 - building LINT kernel TB --- 2013-07-09 15:00:14 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 15:00:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 15:00:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 15:00:14 - SRCCONF=/dev/null TB --- 2013-07-09 15:00:14 - TARGET=ia64 TB --- 2013-07-09 15:00:14 - TARGET_ARCH=ia64 TB --- 2013-07-09 15:00:14 - TZ=UTC TB --- 2013-07-09 15:00:14 - __MAKE_CONF=/dev/null TB --- 2013-07-09 15:00:14 - cd /src TB --- 2013-07-09 15:00:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 15:00:14 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/sctp_crc32.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/sctp_indata.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/sctp_input.c /src/sys/netinet/sctp_input.c: In function 'sctp_common_input_processing': /src/sys/netinet/sctp_input.c:5708: error: 'V_ipsec4stat' undeclared (first use in this function) /src/sys/netinet/sctp_input.c:5708: error: (Each undeclared identifier is reported only once /src/sys/netinet/sctp_input.c:5708: error: for each function it appears in.) /src/sys/netinet/sctp_input.c:5717: error: 'V_ipsec6stat' undeclared (first use in this function) *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 15:17:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 15:17:37 - ERROR: failed to build LINT kernel TB --- 2013-07-09 15:17:37 - 5467.21 user 947.16 system 6779.00 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 15:32:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 339C3970 for ; Tue, 9 Jul 2013 15:32:38 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id BDD86184D for ; Tue, 9 Jul 2013 15:32:37 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id jm2so2443420bkc.16 for ; Tue, 09 Jul 2013 08:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=IUKGJHpSgdqTvXKkkNw4I+JEKk2GM3/QW2f0GXpHFFo=; b=K7m92QmrqM5vtgRugKkvhV2BX7/ZePbBoi5dxz3pdY9Iu/5p61OplwykPMQcfQM/cE Gr9lTOS39kMnXbSd7iGwrM7Yg91r+7lYrjqwt7os2wG9pxBqg11Vhr8sK/g8GCOKdpi7 R+VQw1kAK43jiY7gcQUxzfU/1/yh9JxZ6+JRIdsV1F3EQOKYJOizC3WlqeMBzfhkze1Z cxHPJvh7MyFRnFp7OC4UBBa3znH7q0qVkVUnQOSJaLLfA1IObk2qpO+9aOzJq+ZCrOOQ BWuXp4nntEMHRjim6Md230EU0/c32lNGoyReBOMuf3vvEeN00qVQjOxQV5mHrlTgm6Fs ksbA== X-Received: by 10.204.228.76 with SMTP id jd12mr4268030bkb.133.1373383956788; Tue, 09 Jul 2013 08:32:36 -0700 (PDT) Received: from ernst.home (p4FCA7CCC.dip0.t-ipconnect.de. [79.202.124.204]) by mx.google.com with ESMTPSA id l11sm6020039bkk.13.2013.07.09.08.32.34 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 08:32:35 -0700 (PDT) Date: Tue, 9 Jul 2013 17:32:33 +0200 From: Gary Jennejohn To: FreeBSD Current Subject: kernel compile broken in latest HEAD Message-ID: <20130709173233.275469b4@ernst.home> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Jul 2013 15:32:38 -0000 I just saw this breakage while compiling a kernel on HEAD updated minutes ago: -------------------------------------------------------------- >>> stage 3.2: building everything -------------------------------------------------------------- cc1: warnings being treated as errors In file included from /usr/src/sys/modules/linux/../../compat/linux/linux_ioctl.c:91: @/contrib/v4l/videodev2.h:430: warning: declaration does not declare anything @/contrib/v4l/videodev2.h:460: warning: declaration does not declare anything @/contrib/v4l/videodev2.h:837: warning: declaration does not declare anything @/contrib/v4l/videodev2.h:930: warning: declaration does not declare anything @/contrib/v4l/videodev2.h:1478: warning: declaration does not declare anything @/contrib/v4l/videodev2.h:1600: warning: declaration does not declare anything @/contrib/v4l/videodev2.h:1651: warning: declaration does not declare anything --- linux_ioctl.o --- *** [linux_ioctl.o] Error code 1 make: stopped in /usr/src/sys/modules/linux 1 error These line numbers all point at nameless unions. Seems to me that a union needs a name, otherwise one cannot access its contents. I simply named them all x to get the kernel to compile, which succeeded. It seems that none of these unions are used at the moment. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:12:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD38E817 for ; Tue, 9 Jul 2013 16:12:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4151AAD for ; Tue, 9 Jul 2013 16:12:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 02746B94C; Tue, 9 Jul 2013 12:12:33 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e) Date: Tue, 9 Jul 2013 11:56:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201306141139.16728.jhb@freebsd.org> <20130708104128.Horde.4uMDgEJsnvTlAjpUPueiyQ1@d2ux.org> In-Reply-To: <20130708104128.Horde.4uMDgEJsnvTlAjpUPueiyQ1@d2ux.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307091156.43848.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Jul 2013 12:12:33 -0400 (EDT) Cc: Matthias Petermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 16:12:33 -0000 On Monday, July 08, 2013 4:41:28 am Matthias Petermann wrote: > > Hello, > > I applied the patch, trying to get brightness controls for my X121e. > > But it looks like I need a different loader.conf setting. > > hw.pci0.0.2.0.handle="\\\\_SB_.PCI0.PEG.VID" > > doesn't work. In my ASl there is only one device providing DOD / DOS: > > Scope (_SB.PCI0) > { > Device (GFX0) > { > Name (_ADR, 0x00020000) // _ADR: Address > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output > Switching > { > Store (And (Arg0, 0x07), DSEN) > If (LEqual (And (Arg0, 0x03), Zero)) > { > If (CondRefOf (HDOS)) > { > HDOS () > } > } > } > > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > { > If (CondRefOf (IDAB)) > { > IDAB () > } > Else > { So this is the \_SB_.PCI0.GFX0 device. However, you should kldload acpi_video and see if it already attaches to this device (devinfo -v can be helpful here as it will show the ACPI handle of the parent of the acpi_video device). If it does, then this patch can't help you. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:12:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DB9198D for ; Tue, 9 Jul 2013 16:12:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id E1A3A1AB2 for ; Tue, 9 Jul 2013 16:12:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0DF4FB94A; Tue, 9 Jul 2013 12:12:37 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: using ConnectX card as Ethernet (mlxen) Date: Tue, 9 Jul 2013 11:58:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> In-Reply-To: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307091158.19381.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Jul 2013 12:12:40 -0400 (EDT) Cc: John Nielsen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 16:12:41 -0000 On Monday, September 24, 2012 12:37:30 pm John Nielsen wrote: > I have a machine running "FreeBSD 10.0-CURRENT #0 r240887" amd64 with two ConnectX (InfiniBand) cards. Relevant bits of dmesg and pciconf -lv below. The cards are connected directly to a 10GB Ethernet switch so I need to run them in "eth" mode rather than "ib". Unfortunately they come up in "ib" mode and I don't know how to change it. > > The same hardware works fine under CentOS 6.3, though I need to manually set the cards to 'eth' there as well (which I do using a 'connectx_port_config script from Mellanox that twiddles the mlx4_port1 entries under /sys (sysfs). Under FreeBSD I see these sysctls but I can't set them to 'eth' either via /boot/loader.conf or by sysctl after boot, with or without mlxen and/or mlx4ib loaded: > sys.device.mlx4_core0.mlx4_port1: ib > sys.device.mlx4_core1.mlx4_port1: ib So this was just fixed (finally) in HEAD in r253048. You can how use the sysctls to change this. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:12:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B7C39AA for ; Tue, 9 Jul 2013 16:12:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3D31AB3 for ; Tue, 9 Jul 2013 16:12:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0095B948; Tue, 9 Jul 2013 12:12:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Filesystem wedges caused by r251446 Date: Tue, 9 Jul 2013 12:02:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130704082113.GJ91021@kib.kiev.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307091202.24493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Jul 2013 12:12:41 -0400 (EDT) Cc: Konstantin Belousov , Ian FREISLICH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 16:12:41 -0000 On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: > Konstantin Belousov wrote: > > > > Care to provide any useful information ? > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html > > Well, the system doesn't deadlock it's perfectly useable so long > as you don't touch the file that's wedged. A lot of the time the > userland process is unkillable, but often it is killable. How do > I get from from the PID to where the FS is stuck in the kernel? Use kgdb. 'proc ', then 'bt'. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:12:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5684A9B1; Tue, 9 Jul 2013 16:12:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7751AB4; Tue, 9 Jul 2013 16:12:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 707B1B94C; Tue, 9 Jul 2013 12:12:41 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Ipfilter pre-Vendor Import Issue Date: Tue, 9 Jul 2013 12:12:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307042210.r64MAEJb002949@slippy.cwsent.com> <20130705084649.GC67810@FreeBSD.org> In-Reply-To: <20130705084649.GC67810@FreeBSD.org> MIME-Version: 1.0 Message-Id: <201307091212.22444.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Jul 2013 12:12:41 -0400 (EDT) Cc: Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 16:12:42 -0000 On Friday, July 05, 2013 4:46:49 am Gleb Smirnoff wrote: > Cy, > > On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote: > C> Unfortunately it doesn't work any more. Here is what svn spit out at me. > C> > C> slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter > C> slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte > C> r/dist@252548 > C> svn: E205000: Try 'svn help merge' for more information > C> svn: E205000: Source and target must be different but related branches > C> svn: E205000: Source and target have no common ancestor: > C> 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and > C> '.@unspecified' > C> slippy$ > > AFAIU, the problem is that current contrib/ipfilter was never merged > from vendor/ipfilter. So, actually we are dealing with a first import > (from subversion viewpoint), not n-th. > > What I'd prefer to see is the following: > > - commit new ipfilter untouched to vendor-sys/ipfilter > - nuke sys/contrib/ipfilter > - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter > > In future imports do: > > - commit newer ipfilter to vendor-sys/ipfilter > - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter > > What's the reason to keep code in contrib? Because we put all other vendor code in contrib/ by convention. When there is vendor code in other places it usually results in confusion. For bits that have userland and kernel bits we use head/contrib and head/sys/contrib pulling from vendor/foo and vendor-sys/foo, respectively. Also, this is not the first import as we used a CVS vendor branch for IP filter previously that svn2cvs preserved. Cy, for your svn merge you said you would do this: cd $MY_WORK_DIR/current/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor/ipfilter/dist@NNNNNNN cd $MY_WORK_DIR/current/sys/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor-sys/ipfilter/dist@NNNNNNN but instead you did this: slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte r/dist@252548 Notice you are using 'file:///tank/', not the official SVN repository. All your checkouts and merges should be done using svn.FreeBSD.org, not a local mirror. That might explain your merge problem. Also, if you are just updating the existing vendor branch and not updating it to a newer version I'm not sure you really need the @NNNNNN part for the bootstrap merge, but it probably doesn't hurt. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:25:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C3961F6B; Tue, 9 Jul 2013 16:25:01 +0000 (UTC) (envelope-from eric.camachat@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 997D21B79; Tue, 9 Jul 2013 16:25:01 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz11so5717190pad.16 for ; Tue, 09 Jul 2013 09:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; bh=2E/bLzeCewXJA229WaeMmHCvOvpcg666VwlTomOOnBw=; b=P01j5U008KlTrGorjYZs5ncMNCCneGTHRhR0cHORCe3AXkE8cDnYuNxGKVxkJHi1/P LNxAfVp6lq0o1yuKat2lF/JV2yyXz67AsqtcdB/ffq6jLVxUCwrgfbZt3UdggVpMt+Cd HfxIntcBtFRquBrgEeSPxCvdb1PeB8rJvxvlgZw2TPCp/QkmUnHtGwFSDGvwiOU4JFS1 w/yX8nKkW7U94+hiAJKBI8MrybsymPBRglaY2jmRdlUAA6YsH/VDJw3waF1+4m+zbg8y yyAQFfwJFcbTqxt2XRiaiJu8In2yafJ1T5t5FBBZqmNCJmGehqr7mNlSipEb/XtD2eVi PNyw== X-Received: by 10.68.210.103 with SMTP id mt7mr27087495pbc.179.1373387100577; Tue, 09 Jul 2013 09:25:00 -0700 (PDT) Received: from [192.168.1.73] (172-1-142-179.lightspeed.sntcca.sbcglobal.net. [172.1.142.179]) by mx.google.com with ESMTPSA id wr9sm29080558pbc.7.2013.07.09.09.24.59 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 09:24:59 -0700 (PDT) Subject: Re: Kernel crash during heavy disk access From: Eric Camachat To: Adrian Chadd In-Reply-To: References: <1373344871.1831.9.camel@localhost> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fGiAIzwGfpBR1GRkZF3S" Date: Tue, 09 Jul 2013 09:24:58 -0700 Message-ID: <1373387098.12637.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 16:25:01 -0000 --=-fGiAIzwGfpBR1GRkZF3S Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2013-07-08 at 23:05 -0700, Adrian Chadd wrote: > Hi, >=20 > Try doing a full, non-journal fsck. >=20 > -adrian Thank you, it fixed the problem! Does it mean journal didn't work? --=20 Eric Camachat --=-fGiAIzwGfpBR1GRkZF3S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iF4EABEIAAYFAlHcOVoACgkQSfBQu3oOwYwiJwD/VqdB7lkxyXs00j1LvmtoBV2C UMgONMrx46o4OprpRgEA/3hRZ/ecvOrmjzwv8X3AcaUJ5zOIa+TVfbDznMD7hjH5 =2eAH -----END PGP SIGNATURE----- --=-fGiAIzwGfpBR1GRkZF3S-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:39:40 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82D6340B; Tue, 9 Jul 2013 16:39: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 5A2CF1C3C; Tue, 9 Jul 2013 16:39:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69Gddju066412; Tue, 9 Jul 2013 12:39:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69GddaB066405; Tue, 9 Jul 2013 16:39:39 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 16:39:39 GMT Message-Id: <201307091639.r69GddaB066405@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:39:40 -0000 TB --- 2013-07-09 13:15:33 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 13:15:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 13:15:33 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-07-09 13:15:33 - cleaning the object tree TB --- 2013-07-09 13:15:33 - /usr/local/bin/svn stat /src TB --- 2013-07-09 13:15:37 - At svn revision 253088 TB --- 2013-07-09 13:15:38 - building world TB --- 2013-07-09 13:15:38 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:15:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:15:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:15:38 - SRCCONF=/dev/null TB --- 2013-07-09 13:15:38 - TARGET=pc98 TB --- 2013-07-09 13:15:38 - TARGET_ARCH=i386 TB --- 2013-07-09 13:15:38 - TZ=UTC TB --- 2013-07-09 13:15:38 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:15:38 - cd /src TB --- 2013-07-09 13:15:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 13:15:46 UTC 2013 >>> 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 Jul 9 16:32:01 UTC 2013 TB --- 2013-07-09 16:32:01 - generating LINT kernel config TB --- 2013-07-09 16:32:01 - cd /src/sys/pc98/conf TB --- 2013-07-09 16:32:01 - /usr/bin/make -B LINT TB --- 2013-07-09 16:32:01 - cd /src/sys/pc98/conf TB --- 2013-07-09 16:32:01 - /usr/sbin/config -m LINT TB --- 2013-07-09 16:32:01 - building LINT kernel TB --- 2013-07-09 16:32:01 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 16:32:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 16:32:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 16:32:01 - SRCCONF=/dev/null TB --- 2013-07-09 16:32:01 - TARGET=pc98 TB --- 2013-07-09 16:32:01 - TARGET_ARCH=i386 TB --- 2013-07-09 16:32:01 - TZ=UTC TB --- 2013-07-09 16:32:01 - __MAKE_CONF=/dev/null TB --- 2013-07-09 16:32:01 - cd /src TB --- 2013-07-09 16:32:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 16:32:01 UTC 2013 >>> 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 [...] In file included from /src/sys/dev/ixgb/if_ixgb.h:83: /src/sys/dev/ixgb/ixgb_ids.h:43:9: error: 'INTEL_VENDOR_ID' macro redefined [-Werror] #define INTEL_VENDOR_ID 0x8086 ^ ./x86/specialreg.h:304:9: note: previous definition is here #define INTEL_VENDOR_ID "GenuineIntel" ^ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 16:39:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 16:39:39 - ERROR: failed to build LINT kernel TB --- 2013-07-09 16:39:39 - 9969.51 user 1446.25 system 12246.34 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:49:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A86E5F1; Tue, 9 Jul 2013 16:49:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 580411CA7; Tue, 9 Jul 2013 16:49:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CC244B94A; Tue, 9 Jul 2013 12:49:42 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Ipfilter pre-Vendor Import Issue Date: Tue, 9 Jul 2013 12:49:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307082000.r68K02Ef063517@slippy.cwsent.com> <20130709092136.GL67810@glebius.int.ru> In-Reply-To: <20130709092136.GL67810@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307091249.36403.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Jul 2013 12:49:42 -0400 (EDT) Cc: Gleb Smirnoff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 16:49:43 -0000 On Tuesday, July 09, 2013 5:21:36 am Gleb Smirnoff wrote: > On Mon, Jul 08, 2013 at 01:00:02PM -0700, Cy Schubert wrote: > C> > The BSD license allows us to put the code into FreeBSD w/o any separation. > C> > > C> > So the question is: what is more handy to us? > C> > > C> > What do we actually gain having contrib/ipf, assuming we got vendor branch > C> > already? > C> > > C> > What we lose is: > C> > - more complex Makefiles > C> > - more complex hacking: edit files in one place, run make in other > C> > C> How is this for a plan? > C> > C> Instead of importing the kernel bits into vendor-sys/ipfilter and the > C> userland bits into vendor/ipfilter, the base tarball should be imported > C> into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We > C> keep the complete tarball imported into one place in the tree. > > I'd prefer vendor/ipfilter as single place of vendor imports. > > C> Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and > C> netpfil/ipfilter (for userland bits). > C> > C> We should probably think of moving pf and ipfw into the new subdirectory as > C> well, but that's for a future discussion. > > No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin, > according to the place where they are installed. An exlusion can be made > adding a intermediate subdir (like this is already done for ipfilter tools), > to group all related tools together. Please, please! Let's not make ipfilter some random one-off vendor source that imports code into random places. The remaining instances of that that we have (such as stdtime) are a PITA to deal with. vendor/ipfilter == userland bits => contrib/ipfilter. You then put suitable Makefiles/build glue that uses .PATH in usr.bin|sbin|whatever. vendor-sys/ipfilter == kernel bits => sys/contrib/ipfilter. You then fix sys/conf/files, etc. as appropriate. This is our _standard_ practice for dealing with this stuff. This is how all the OpenSolaris bits for Dtrace and ZFS are handled (except that they end up in a cddl directory instead of contrib). GENERIC / LINT builds can include things from sys/contrib just fine, so ipfilter won't be missed by builds, etc. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 17:03:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECF56BA0; Tue, 9 Jul 2013 17:03:11 +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 C37F41D61; Tue, 9 Jul 2013 17:03:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69H3Bgb041174; Tue, 9 Jul 2013 13:03:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69H3Bvs041173; Tue, 9 Jul 2013 17:03:11 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 17:03:11 GMT Message-Id: <201307091703.r69H3Bvs041173@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:03:12 -0000 TB --- 2013-07-09 15:44:24 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 15:44:24 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 15:44:24 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-09 15:44:24 - cleaning the object tree TB --- 2013-07-09 15:44:24 - /usr/local/bin/svn stat /src TB --- 2013-07-09 15:44:27 - At svn revision 253088 TB --- 2013-07-09 15:44:28 - building world TB --- 2013-07-09 15:44:28 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 15:44:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 15:44:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 15:44:28 - SRCCONF=/dev/null TB --- 2013-07-09 15:44:28 - TARGET=sparc64 TB --- 2013-07-09 15:44:28 - TARGET_ARCH=sparc64 TB --- 2013-07-09 15:44:28 - TZ=UTC TB --- 2013-07-09 15:44:28 - __MAKE_CONF=/dev/null TB --- 2013-07-09 15:44:28 - cd /src TB --- 2013-07-09 15:44:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 15:44:35 UTC 2013 >>> 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 Jul 9 16:52:20 UTC 2013 TB --- 2013-07-09 16:52:20 - generating LINT kernel config TB --- 2013-07-09 16:52:20 - cd /src/sys/sparc64/conf TB --- 2013-07-09 16:52:20 - /usr/bin/make -B LINT TB --- 2013-07-09 16:52:20 - cd /src/sys/sparc64/conf TB --- 2013-07-09 16:52:20 - /usr/sbin/config -m LINT TB --- 2013-07-09 16:52:20 - building LINT kernel TB --- 2013-07-09 16:52:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 16:52:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 16:52:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 16:52:20 - SRCCONF=/dev/null TB --- 2013-07-09 16:52:20 - TARGET=sparc64 TB --- 2013-07-09 16:52:20 - TARGET_ARCH=sparc64 TB --- 2013-07-09 16:52:20 - TZ=UTC TB --- 2013-07-09 16:52:20 - __MAKE_CONF=/dev/null TB --- 2013-07-09 16:52:20 - cd /src TB --- 2013-07-09 16:52:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 16:52:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 17:03:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 17:03:11 - ERROR: failed to build LINT kernel TB --- 2013-07-09 17:03:11 - 3788.10 user 708.66 system 4726.76 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 17:10:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AE89D98 for ; Tue, 9 Jul 2013 17:10:59 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 92C921DC5 for ; Tue, 9 Jul 2013 17:10:58 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id it16so2473485bkc.27 for ; Tue, 09 Jul 2013 10:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=joUg8wqxtCrABc03EvWUOMcvRxfzRQ9091QIsl5qm0o=; b=kRiMYgzRWC54HqA9kkI8iXqZeRA+jeJHaQz5ghosxpLuUkmxuRYTAffNL8iSTmWU9F i6p76tUeixZqO5wD0zrwKx41SO+fBQRGsYGLsbbBmOYXK46Z7/Kq080bLslSc5+d4WUd CkVWQpAES3L7VOMsBarq7qcqPQ98gLcq2QUL4JKKfQRa9nPLaW3ZoOa6/4Hp7fWsNAWp Gp+6DvX4TrKOK2uRCJhcjgsAh2lwCo1zoFtN1JySXbgn3fQ7JK6UzM6kKvQ+fdG+LicZ CLs5g+TAgmYp9dwFzu8VrSaJanTHJkU2txZp3xVFMI9OPijVE6EOQ3Z4LtkRush6sAFF ahcQ== X-Received: by 10.205.15.194 with SMTP id pv2mr4294789bkb.122.1373389857458; Tue, 09 Jul 2013 10:10:57 -0700 (PDT) Received: from ernst.home (p4FCA7CCC.dip0.t-ipconnect.de. [79.202.124.204]) by mx.google.com with ESMTPSA id rj6sm6108028bkb.12.2013.07.09.10.10.55 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 10:10:56 -0700 (PDT) Date: Tue, 9 Jul 2013 19:10:54 +0200 From: Gary Jennejohn To: Alie Tan Subject: Re: kernel compile broken in latest HEAD Message-ID: <20130709191054.4c38b204@ernst.home> In-Reply-To: References: <20130709173233.275469b4@ernst.home> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Jul 2013 17:10:59 -0000 On Tue, 9 Jul 2013 23:50:57 +0800 Alie Tan wrote: > On Tue, Jul 9, 2013 at 11:32 PM, Gary Jennejohn > wrote: > > > I just saw this breakage while compiling a kernel on HEAD updated > > minutes ago: > > > > -------------------------------------------------------------- > > >>> stage 3.2: building everything > > -------------------------------------------------------------- > > cc1: warnings being treated as errors > > > Try declare below lines to your /etc/src.conf as workaround > NO_WERROR= > WERROR= > Thanks for you input. But there's an error in the code which should be corrected. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 15:57:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9C5258B for ; Tue, 9 Jul 2013 15:57:14 +0000 (UTC) (envelope-from alie@afflemedialab.com) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by mx1.freebsd.org (Postfix) with ESMTP id B119619BE for ; Tue, 9 Jul 2013 15:57:14 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id l10so3059941qcy.4 for ; Tue, 09 Jul 2013 08:57:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=84VwvKJ/ZhWU+rtGLur7sex2U/MxjB6Jp43f2z3ED+A=; b=pZIKIAgPBK3lQRYa6X3pTGyx38eezh0JTJ4agJ4lCdgyboSi5m9TyflwVwLRrul+HU KMPhnkqptKTfsg6axynaq6BGFFrmP41tLwCpM87/Ppw6/VTRAR7F8uMf3dS1w61CfVB7 ZCcYmpXcge6lQxSgtiXejg3D3CDXSjm0p13HsveV3jY1LORVyJ/r9vNMm2Ui8oDDt0Cc fvZNsFVPmdwcz6RZ1Ge0027piZf3lW3WAWbwpJgPx4QrxyGIH5ET5CU/5utj2ThnBe3z qVyWP9iuYSMLd7bNCCRhQ6L7ZqnabAYgqz1UySj/C9EbcJIJ9zkiBnrDDEGcOltCr9pc zebQ== MIME-Version: 1.0 X-Received: by 10.49.85.199 with SMTP id j7mr21049467qez.45.1373385057932; Tue, 09 Jul 2013 08:50:57 -0700 (PDT) Received: by 10.49.84.168 with HTTP; Tue, 9 Jul 2013 08:50:57 -0700 (PDT) In-Reply-To: <20130709173233.275469b4@ernst.home> References: <20130709173233.275469b4@ernst.home> Date: Tue, 9 Jul 2013 23:50:57 +0800 Message-ID: Subject: Re: kernel compile broken in latest HEAD From: Alie Tan To: gljennjohn@googlemail.com X-Gm-Message-State: ALoCoQm/UETuAmwUuo6WcgI4Q9OYbSg8hpx0BzueUEpYCLfb+znkEEr4bmRbb33d/6Smkfc0kqNj X-Mailman-Approved-At: Tue, 09 Jul 2013 17:16:16 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 15:57:15 -0000 On Tue, Jul 9, 2013 at 11:32 PM, Gary Jennejohn wrote: > I just saw this breakage while compiling a kernel on HEAD updated > minutes ago: > > -------------------------------------------------------------- > >>> stage 3.2: building everything > -------------------------------------------------------------- > cc1: warnings being treated as errors > Try declare below lines to your /etc/src.conf as workaround NO_WERROR= WERROR= > In file included from > /usr/src/sys/modules/linux/../../compat/linux/linux_ioctl.c:91: > @/contrib/v4l/videodev2.h:430: warning: declaration does not declare > anything > @/contrib/v4l/videodev2.h:460: warning: declaration does not declare > anything > @/contrib/v4l/videodev2.h:837: warning: declaration does not declare > anything > @/contrib/v4l/videodev2.h:930: warning: declaration does not declare > anything > @/contrib/v4l/videodev2.h:1478: warning: declaration does not declare > anything > @/contrib/v4l/videodev2.h:1600: warning: declaration does not declare > anything > @/contrib/v4l/videodev2.h:1651: warning: declaration does not declare > anything > --- linux_ioctl.o --- > *** [linux_ioctl.o] Error code 1 > > make: stopped in /usr/src/sys/modules/linux > 1 error > > These line numbers all point at nameless unions. > > Seems to me that a union needs a name, otherwise one cannot > access its contents. > > I simply named them all x to get the kernel to compile, which > succeeded. > > It seems that none of these unions are used at the moment. > > -- > Gary Jennejohn > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 17:20:40 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D199D397; Tue, 9 Jul 2013 17:20: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 A7E851E67; Tue, 9 Jul 2013 17:20:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69HKeIA095521; Tue, 9 Jul 2013 13:20:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69HKer3095520; Tue, 9 Jul 2013 17:20:40 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 17:20:40 GMT Message-Id: <201307091720.r69HKer3095520@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:20:40 -0000 TB --- 2013-07-09 14:35:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 14:35:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 14:35:25 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-07-09 14:35:25 - cleaning the object tree TB --- 2013-07-09 14:35:25 - /usr/local/bin/svn stat /src TB --- 2013-07-09 14:35:29 - At svn revision 253088 TB --- 2013-07-09 14:35:30 - building world TB --- 2013-07-09 14:35:30 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 14:35:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 14:35:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 14:35:30 - SRCCONF=/dev/null TB --- 2013-07-09 14:35:30 - TARGET=powerpc TB --- 2013-07-09 14:35:30 - TARGET_ARCH=powerpc TB --- 2013-07-09 14:35:30 - TZ=UTC TB --- 2013-07-09 14:35:30 - __MAKE_CONF=/dev/null TB --- 2013-07-09 14:35:30 - cd /src TB --- 2013-07-09 14:35:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 14:35:39 UTC 2013 >>> 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 Jul 9 17:12:25 UTC 2013 TB --- 2013-07-09 17:12:25 - generating LINT kernel config TB --- 2013-07-09 17:12:25 - cd /src/sys/powerpc/conf TB --- 2013-07-09 17:12:25 - /usr/bin/make -B LINT TB --- 2013-07-09 17:12:25 - cd /src/sys/powerpc/conf TB --- 2013-07-09 17:12:25 - /usr/sbin/config -m LINT TB --- 2013-07-09 17:12:25 - building LINT kernel TB --- 2013-07-09 17:12:25 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 17:12:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 17:12:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 17:12:25 - SRCCONF=/dev/null TB --- 2013-07-09 17:12:25 - TARGET=powerpc TB --- 2013-07-09 17:12:25 - TARGET_ARCH=powerpc TB --- 2013-07-09 17:12:25 - TZ=UTC TB --- 2013-07-09 17:12:25 - __MAKE_CONF=/dev/null TB --- 2013-07-09 17:12:25 - cd /src TB --- 2013-07-09 17:12:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 17:12:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/netgraph/ng_vlan.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/netinet/accf_data.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/netinet/accf_dns.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/netinet/accf_http.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/netinet/if_atm.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/netinet/if_ether.c /src/sys/netinet/if_ether.c: In function 'arpstat_sysctl': /src/sys/netinet/if_ether.c:122: error: size of array '__assert_3' is negative *** Error code 1 Stop. make: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 17:20:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 17:20:39 - ERROR: failed to build LINT kernel TB --- 2013-07-09 17:20:39 - 8488.68 user 1126.84 system 9914.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 18:16:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03996727 for ; Tue, 9 Jul 2013 18:16:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id BFB2611CA for ; Tue, 9 Jul 2013 18:16:10 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id f11so3105828qae.10 for ; Tue, 09 Jul 2013 11:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=X0FwF0mQMGEnuM0IBK398lyQdCnnPPP65bAmaEwfZuY=; b=LcGG80vZ5jsK75pEJnuN6XaQ++EFiSqxs6VCX8B7do04TtiWrJm7k+oW4BrvhrQ3vW 3hqh2vJB1cYu2wqku6Iuu8w/80/BPIWhsZFwjIaMAFMTEKeGqjASfPt0KQP3FC2AM14P jeX1ynu0UlUswnphlgVo5FcdpyQ3iYU9qwRmlMjFe81lo5OeSkUZqeiK4IG7qWoyWWQm qLELJFfkjfMMd+qXGtbn3u1ZdiNxE/Du96i/nojpTgG+FWGZryj51YU6ijvuxmrgnTV5 FeB51uV0j1kTy4H6JaVACGlZfOyG3++RcXQsQ996lHu8jGrCBdum9HXjq8i2JW9RBzhZ UoLA== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr21744537qeb.6.1373393770268; Tue, 09 Jul 2013 11:16:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Tue, 9 Jul 2013 11:16:10 -0700 (PDT) In-Reply-To: <1373387098.12637.1.camel@localhost> References: <1373344871.1831.9.camel@localhost> <1373387098.12637.1.camel@localhost> Date: Tue, 9 Jul 2013 11:16:10 -0700 X-Google-Sender-Auth: qNcQeavc46ek_4M49bvahJXpPvs Message-ID: Subject: Re: Kernel crash during heavy disk access From: Adrian Chadd To: Eric Camachat Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 18:16:11 -0000 On 9 July 2013 09:24, Eric Camachat wrote: > On Mon, 2013-07-08 at 23:05 -0700, Adrian Chadd wrote: >> Hi, >> >> Try doing a full, non-journal fsck. >> >> -adrian > > Thank you, it fixed the problem! > Does it mean journal didn't work? Yup :( -adrian From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 19:19:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66FA4E52 for ; Tue, 9 Jul 2013 19:19:23 +0000 (UTC) (envelope-from matthias@d2ux.net) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id 271F616A8 for ; Tue, 9 Jul 2013 19:19:22 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id D20F684F25C2 for ; Tue, 9 Jul 2013 21:19:13 +0200 (CEST) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id te8cOiCFO9sQ for ; Tue, 9 Jul 2013 21:19:11 +0200 (CEST) Received: from [192.168.2.112] (p5DDAADA5.dip0.t-ipconnect.de [93.218.173.165]) by mail.s1.d2ux.org (Postfix) with ESMTPSA id A6FAE84F25B4 for ; Tue, 9 Jul 2013 21:19:11 +0200 (CEST) Message-ID: <51DC6231.60000@d2ux.net> Date: Tue, 09 Jul 2013 21:19:13 +0200 From: Matthias Petermann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e) References: <512A6FFF.2060603@gmail.com> <201306141139.16728.jhb@freebsd.org> <20130708104128.Horde.4uMDgEJsnvTlAjpUPueiyQ1@d2ux.org> <201307091156.43848.jhb@freebsd.org> In-Reply-To: <201307091156.43848.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 19:19:23 -0000 Am 09.07.2013 17:56, schrieb John Baldwin: > On Monday, July 08, 2013 4:41:28 am Matthias Petermann wrote: >> Hello, >> >> I applied the patch, trying to get brightness controls for my X121e. >> >> But it looks like I need a different loader.conf setting. >> >> hw.pci0.0.2.0.handle="\\\\_SB_.PCI0.PEG.VID" >> >> doesn't work. In my ASl there is only one device providing DOD / DOS: >> >> Scope (_SB.PCI0) >> { >> Device (GFX0) >> { >> Name (_ADR, 0x00020000) // _ADR: Address >> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output >> Switching >> { >> Store (And (Arg0, 0x07), DSEN) >> If (LEqual (And (Arg0, 0x03), Zero)) >> { >> If (CondRefOf (HDOS)) >> { >> HDOS () >> } >> } >> } >> >> Method (_DOD, 0, NotSerialized) // _DOD: Display Output > Devices >> { >> If (CondRefOf (IDAB)) >> { >> IDAB () >> } >> Else >> { > So this is the \_SB_.PCI0.GFX0 device. However, you should kldload acpi_video > and see if it already attaches to this device (devinfo -v can be helpful here > as it will show the ACPI handle of the parent of the acpi_video device). If > it does, then this patch can't help you. > Hi John, thanks for this hint. After "kldload acpi_video" devinfo -v shows the following (truncated): nexus0 acpi0 pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x0104 subvendor=0x17aa subdevice=0x21ed class=0x060000 at slot=0 function=0 vgapci0 pnpinfo vendor=0x8086 device=0x0116 subvendor=0x17aa subdevice=0x21ed class=0x030000 at slot=2 function=0 handle=\_SB_.PCI0.GFX0 agp0 drm0 drmn0 acpi_video0 Assuming the patch cannot help me, do you have an idea what I could check next? I can control the brightness with acpi_call -p '\VBRU' acpi_call -p '\VBRD' https://d2ux.org/owncloud/public.php?service=files&t=7022f90cea5e48da7fa65806c0d66091 Regards, Matthias From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 20:10:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B9F22148; Tue, 9 Jul 2013 20:10:40 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) by mx1.freebsd.org (Postfix) with ESMTP id A24221997; Tue, 9 Jul 2013 20:10:39 +0000 (UTC) Received: from [10.10.1.32] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id r69K8MJe099977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Jul 2013 16:08:22 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: using ConnectX card as Ethernet (mlxen) From: John Nielsen In-Reply-To: <201307091158.19381.jhb@freebsd.org> Date: Tue, 9 Jul 2013 14:08:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> <201307091158.19381.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) X-DCC-Etherboy-Metrics: ns1.jnielsen.net 1002; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.5 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 20:10:40 -0000 On Jul 9, 2013, at 9:58 AM, John Baldwin wrote: > On Monday, September 24, 2012 12:37:30 pm John Nielsen wrote: >> I have a machine running "FreeBSD 10.0-CURRENT #0 r240887" amd64 with = two=20 > ConnectX (InfiniBand) cards. Relevant bits of dmesg and pciconf -lv = below. The=20 > cards are connected directly to a 10GB Ethernet switch so I need to = run them=20 > in "eth" mode rather than "ib". Unfortunately they come up in "ib" = mode and I=20 > don't know how to change it. >>=20 >> The same hardware works fine under CentOS 6.3, though I need to = manually set=20 > the cards to 'eth' there as well (which I do using a = 'connectx_port_config=20 > script from Mellanox that twiddles the mlx4_port1 entries under /sys = (sysfs).=20 > Under FreeBSD I see these sysctls but I can't set them to 'eth' either = via=20 > /boot/loader.conf or by sysctl after boot, with or without mlxen = and/or mlx4ib=20 > loaded: >> sys.device.mlx4_core0.mlx4_port1: ib >> sys.device.mlx4_core1.mlx4_port1: ib >=20 > So this was just fixed (finally) in HEAD in r253048. You can how use = the > sysctls to change this. I saw the commit. Thanks! I'll give it a try at some point (whenever my = schedule and hardware availability align). JN From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 20:34:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 035DA83C for ; Tue, 9 Jul 2013 20:34:13 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B5D7C1AC6 for ; Tue, 9 Jul 2013 20:34:12 +0000 (UTC) Received: from outgoing.leidinger.net (pD9FBBBE3.dip0.t-ipconnect.de [217.251.187.227]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9D63484408D; Tue, 9 Jul 2013 22:33:59 +0200 (CEST) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id 37A9BD64; Tue, 9 Jul 2013 22:33:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1373402037; bh=2V9mmk/+IDqkcNm3cAsXVm4f8EBsWQo53+3SqKsM4ss=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=rFXAS5757t1ninvGNzLo5O4V1vBk6qah1YeMhNgWoctOxpS5L1nD5C6dg9GcIFbeq ith5PWln/CVz9FvWr3PhhBQkMVnlz4JMOfA0ycQlyxsbBEvtktWlKmFxTmrZzE7yxx Ngm2gaOqkV7fUzYymA7/BV0xZEolLPGtcBGNdH8HkUVChg76Sm3rru3XfOf2OlMs4+ SzJVIBp3wn/iUAri2b5IDqpt4y9nE/A0IJ3rR/618hkGgQkFOjuDYQg8rWUiuSgQ5P er0uBuW4p+B98rpV2BeKEKsSyMgEsFxyXAFOm51j8Y0ESGzB+9yjfd+81OP9HHqsbA jAbDOchHil9Ng== Date: Tue, 9 Jul 2013 22:33:56 +0200 From: Alexander Leidinger To: gljennjohn@googlemail.com Subject: Re: kernel compile broken in latest HEAD Message-ID: <20130709223356.000005ad@unknown> In-Reply-To: <20130709173233.275469b4@ernst.home> References: <20130709173233.275469b4@ernst.home> X-Mailer: Claws Mail 3.9.1-2-g66aa06 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9D63484408D.AF0B8 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.979, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.13, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01, URIBL_BLOCKED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1374006839.82287@s7l9jtCZLHJ1r/we7fKXSw X-EBL-Spam-Status: No Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 20:34:13 -0000 On Tue, 9 Jul 2013 17:32:33 +0200 Gary Jennejohn wrote: > I just saw this breakage while compiling a kernel on HEAD updated > minutes ago: Is your cc a gcc or clang? My one is clang and I didn't get build errors when I tested the commit. I was told there are those errors with gcc. My question in the corresponding thread is so far unanswered. Here's what I wrote as a reference: ---snip--- Does someone know what this is supposed to result in? I would assume as the unions are unnamed and no variable is declared inside the struct with it, that the size of the struct is the same as not having those unions inside the structs. If this is correct I would assume the correct fix would be to #if-0 them out. ---snip--- > These line numbers all point at nameless unions. > > Seems to me that a union needs a name, otherwise one cannot > access its contents. > > I simply named them all x to get the kernel to compile, which > succeeded. Did you name it x ("union x {...};"), or did you declare a variable x with it ("union {...} x;")? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 20:42:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44FB9A87; Tue, 9 Jul 2013 20:42:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id BDE9B1B2A; Tue, 9 Jul 2013 20:42:38 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r69KgaVj097150; Wed, 10 Jul 2013 00:42:36 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r69KgZQe097149; Wed, 10 Jul 2013 00:42:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 10 Jul 2013 00:42:35 +0400 From: Gleb Smirnoff To: John Baldwin Subject: Re: Ipfilter pre-Vendor Import Issue Message-ID: <20130709204235.GU67810@glebius.int.ru> References: <201307082000.r68K02Ef063517@slippy.cwsent.com> <20130709092136.GL67810@glebius.int.ru> <201307091249.36403.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201307091249.36403.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 20:42:39 -0000 On Tue, Jul 09, 2013 at 12:49:36PM -0400, John Baldwin wrote: J> Let's not make ipfilter some random one-off vendor source that imports code J> into random places. The remaining instances of that that we have (such as J> stdtime) are a PITA to deal with. J> J> vendor/ipfilter == userland bits => contrib/ipfilter. You then put suitable J> Makefiles/build glue that uses .PATH in usr.bin|sbin|whatever. J> J> vendor-sys/ipfilter == kernel bits => sys/contrib/ipfilter. You then fix J> sys/conf/files, etc. as appropriate. J> J> This is our _standard_ practice for dealing with this stuff. This is how all J> the OpenSolaris bits for Dtrace and ZFS are handled (except that they end up J> in a cddl directory instead of contrib). GENERIC / LINT builds can include J> things from sys/contrib just fine, so ipfilter won't be missed by builds, etc. Okay, let it be so. My initial intention was to "own" ipfilter by FreeBSD, since for the last years it was unmaintained, and its contrib status prevented people from touching its sources. Now, that Darren responded on this thread and promises to take our patches upstream, I am fine with having it in contrib. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 21:03:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C78455A for ; Tue, 9 Jul 2013 21:03:13 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id BF0EB1C57 for ; Tue, 9 Jul 2013 21:03:12 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id r69Kde82033942; Tue, 9 Jul 2013 22:40:53 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <51DC750C.6090707@fgznet.ch> Date: Tue, 09 Jul 2013 22:39:40 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexander Leidinger Subject: Re: kernel compile broken in latest HEAD References: <20130709173233.275469b4@ernst.home> <20130709223356.000005ad@unknown> In-Reply-To: <20130709223356.000005ad@unknown> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jul 2013 21:03:13 -0000 On 09.07.13 22:33, Alexander Leidinger wrote: > On Tue, 9 Jul 2013 17:32:33 +0200 > Gary Jennejohn wrote: > >> I just saw this breakage while compiling a kernel on HEAD updated >> minutes ago: So did I. > Is your cc a gcc or clang? My one is clang and I didn't get build > errors when I tested the commit. I was told there are those errors with > gcc. My question in the corresponding thread is so far unanswered. My cc is gcc, stock. > Here's what I wrote as a reference: > ---snip--- > Does someone know what this is supposed to result in? > > I would assume as the unions are unnamed and no variable is declared > inside the struct with it, that the size of the struct is the same as > not having those unions inside the structs. > > If this is correct I would assume the correct fix would be to #if-0 > them out. > ---snip--- I did so and my kernelbuild is happy now. Yes, I do not use this header at all. >> These line numbers all point at nameless unions. >> >> Seems to me that a union needs a name, otherwise one cannot >> access its contents. >> >> I simply named them all x to get the kernel to compile, which >> succeeded. > > Did you name it x ("union x {...};"), or did you declare a variable > x with it ("union {...} x;")? From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 00:48:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5565DF49; Wed, 10 Jul 2013 00:48:45 +0000 (UTC) (envelope-from bjk@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 44A17196E; Wed, 10 Jul 2013 00:48:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6A0mjjY022397; Wed, 10 Jul 2013 00:48:45 GMT (envelope-from bjk@freebsd.org) Received: from localhost (bjk@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) with ESMTP id r6A0miVB022394; Wed, 10 Jul 2013 00:48:44 GMT (envelope-from bjk@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bjk owned process doing -bs Date: Wed, 10 Jul 2013 00:48:44 +0000 (UTC) From: Benjamin Kaduk To: Adrian Chadd Subject: Re: Kernel crash during heavy disk access In-Reply-To: Message-ID: References: <1373344871.1831.9.camel@localhost> <1373387098.12637.1.camel@localhost> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Eric Camachat , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 00:48:45 -0000 On Tue, 9 Jul 2013, Adrian Chadd wrote: > On 9 July 2013 09:24, Eric Camachat wrote: >> On Mon, 2013-07-08 at 23:05 -0700, Adrian Chadd wrote: >>> Hi, >>> >>> Try doing a full, non-journal fsck. >>> >>> -adrian >> >> Thank you, it fixed the problem! >> Does it mean journal didn't work? > > Yup :( So, you are going to tell Kirk about it? -Ben From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 01:29:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB9F9858; Wed, 10 Jul 2013 01:29:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE361A96; Wed, 10 Jul 2013 01:29:02 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id c10so3379327qcz.14 for ; Tue, 09 Jul 2013 18:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QRGEa0NU3eufDOcOhBBagmDYHb7A7nfx8lcGqTOsTaA=; b=gsDX7vV+kvS3AGWWIgEEwwljlcUm9h2Z3/GrhCcGDJgvqq2T6zMzeCJ9ovE5zhbq3V C+yubrrE84ugZTViiDoWLDyvKPPCuQSfAbj1f81iIqSN2B44qAhCzzcdLE2KIm3vuoeE fhTDHT1MDarQ0/ujp4kLx6BY7gcL5rLpJBDle+enXGz9m1iCpf2/1i7IfbOrc2j9vO0a xCpf8CKPTF8wdIZ87QJyX4bFm7abnAh212Auj6Z68Dhwco6Sciexnk6byIXBwkRpUCwL 5TaAtx7nDFLHU/U3RUbaB7jmQiBweLfuhvJxkrT8Yv9f0WNGPk6JffYeBT/5GG2bdoL1 6hJw== MIME-Version: 1.0 X-Received: by 10.224.26.7 with SMTP id b7mr25568321qac.102.1373419741877; Tue, 09 Jul 2013 18:29:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Tue, 9 Jul 2013 18:29:01 -0700 (PDT) In-Reply-To: References: <1373344871.1831.9.camel@localhost> <1373387098.12637.1.camel@localhost> Date: Tue, 9 Jul 2013 18:29:01 -0700 X-Google-Sender-Auth: 108WzdScYwuorJCWZ2YwF4Ld2pk Message-ID: Subject: Re: Kernel crash during heavy disk access From: Adrian Chadd To: Benjamin Kaduk , Jeff Roberson , Kirk McKusick Content-Type: text/plain; charset=ISO-8859-1 Cc: Eric Camachat , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 01:29:02 -0000 Well, best to tell kirk and jeffr. Jeffr wrote the journaling stuff. .. but I thought they knew there's still problems? -adrian On 9 July 2013 17:48, Benjamin Kaduk wrote: > On Tue, 9 Jul 2013, Adrian Chadd wrote: > >> On 9 July 2013 09:24, Eric Camachat wrote: >>> >>> On Mon, 2013-07-08 at 23:05 -0700, Adrian Chadd wrote: >>>> >>>> Hi, >>>> >>>> Try doing a full, non-journal fsck. >>>> >>>> -adrian >>> >>> >>> Thank you, it fixed the problem! >>> Does it mean journal didn't work? >> >> >> Yup :( > > > So, you are going to tell Kirk about it? > > -Ben From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 05:15:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B84006BE; Wed, 10 Jul 2013 05:15:25 +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 8C52D1337; Wed, 10 Jul 2013 05:15:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6A5FOJr033709; Wed, 10 Jul 2013 01:15:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6A5FOn9033702; Wed, 10 Jul 2013 05:15:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Jul 2013 05:15:24 GMT Message-Id: <201307100515.r6A5FOn9033702@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 05:15:25 -0000 TB --- 2013-07-10 03:53:35 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-10 03:53:35 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-10 03:53:35 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-10 03:53:35 - cleaning the object tree TB --- 2013-07-10 03:54:28 - /usr/local/bin/svn stat /src TB --- 2013-07-10 03:54:37 - At svn revision 253102 TB --- 2013-07-10 03:54:38 - building world TB --- 2013-07-10 03:54:38 - CROSS_BUILD_TESTING=YES TB --- 2013-07-10 03:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-10 03:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-10 03:54:38 - SRCCONF=/dev/null TB --- 2013-07-10 03:54:38 - TARGET=sparc64 TB --- 2013-07-10 03:54:38 - TARGET_ARCH=sparc64 TB --- 2013-07-10 03:54:38 - TZ=UTC TB --- 2013-07-10 03:54:38 - __MAKE_CONF=/dev/null TB --- 2013-07-10 03:54:38 - cd /src TB --- 2013-07-10 03:54:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jul 10 03:54:46 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 10 05:04:22 UTC 2013 TB --- 2013-07-10 05:04:22 - generating LINT kernel config TB --- 2013-07-10 05:04:22 - cd /src/sys/sparc64/conf TB --- 2013-07-10 05:04:22 - /usr/bin/make -B LINT TB --- 2013-07-10 05:04:22 - cd /src/sys/sparc64/conf TB --- 2013-07-10 05:04:22 - /usr/sbin/config -m LINT TB --- 2013-07-10 05:04:22 - building LINT kernel TB --- 2013-07-10 05:04:22 - CROSS_BUILD_TESTING=YES TB --- 2013-07-10 05:04:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-10 05:04:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-10 05:04:22 - SRCCONF=/dev/null TB --- 2013-07-10 05:04:22 - TARGET=sparc64 TB --- 2013-07-10 05:04:22 - TARGET_ARCH=sparc64 TB --- 2013-07-10 05:04:22 - TZ=UTC TB --- 2013-07-10 05:04:22 - __MAKE_CONF=/dev/null TB --- 2013-07-10 05:04:22 - cd /src TB --- 2013-07-10 05:04:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 10 05:04:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-10 05:15:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-10 05:15:24 - ERROR: failed to build LINT kernel TB --- 2013-07-10 05:15:24 - 3807.09 user 642.38 system 4908.98 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 05:39:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B6B6C6B for ; Wed, 10 Jul 2013 05:39:17 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 1F55B1465 for ; Wed, 10 Jul 2013 05:39:16 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id ji1so2666223bkc.38 for ; Tue, 09 Jul 2013 22:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=YbWl6esx5Yl9w5Q7B43p+7G4g4OJbhh66touyGkks8M=; b=fpl2aLr1wLPWUmonsE5FJRtsiSC/VixE1YIK1pNLQshom4C2IsABqjOZ0HDvUECf9V V1pyH5zIu+3ZpXPYPrFpxq00qg4izL2X05CZ+65KuJR70T3W9DvDH6fIrZqW4yk/p8m4 81iP20elZCsB67CiPyBGGVyt7IcFxyWnTAhiqLQuqElRzIE8c1l44tnOhu2VT3BIBUtV rncnoEcMdnyoSAXs/nLzk+ik4TUal6STNBGndEAF4qUeJId+xvYh4S0+3Y+UhFtRSt9x B6E9txxSKN/u2MEYpfLpxGFVuogo8vzWl8RPF9g0BvX7c7M/l6aWRJ3MkqHVKHUCWghM CeCQ== X-Received: by 10.205.10.200 with SMTP id pb8mr4780831bkb.0.1373434756041; Tue, 09 Jul 2013 22:39:16 -0700 (PDT) Received: from ernst.home (p578E11E1.dip0.t-ipconnect.de. [87.142.17.225]) by mx.google.com with ESMTPSA id ch16sm6571617bkb.17.2013.07.09.22.39.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 22:39:15 -0700 (PDT) Date: Wed, 10 Jul 2013 07:39:12 +0200 From: Gary Jennejohn To: Alexander Leidinger Subject: Re: kernel compile broken in latest HEAD Message-ID: <20130710073912.54fedfc8@ernst.home> In-Reply-To: <20130709223356.000005ad@unknown> References: <20130709173233.275469b4@ernst.home> <20130709223356.000005ad@unknown> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 10 Jul 2013 05:39:17 -0000 On Tue, 9 Jul 2013 22:33:56 +0200 Alexander Leidinger wrote: > On Tue, 9 Jul 2013 17:32:33 +0200 > Gary Jennejohn wrote: > > > I just saw this breakage while compiling a kernel on HEAD updated > > minutes ago: > > Is your cc a gcc or clang? My one is clang and I didn't get build > errors when I tested the commit. I was told there are those errors with > gcc. My question in the corresponding thread is so far unanswered. > gcc > Here's what I wrote as a reference: > ---snip--- > Does someone know what this is supposed to result in? > > I would assume as the unions are unnamed and no variable is declared > inside the struct with it, that the size of the struct is the same as > not having those unions inside the structs. > > If this is correct I would assume the correct fix would be to #if-0 > them out. > ---snip--- > > > These line numbers all point at nameless unions. > > > > Seems to me that a union needs a name, otherwise one cannot > > access its contents. > > > > I simply named them all x to get the kernel to compile, which > > succeeded. > > Did you name it x ("union x {...};"), or did you declare a variable > x with it ("union {...} x;")? > the latter -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 06:28:37 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C5E3F55A; Wed, 10 Jul 2013 06:28:37 +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 83C5716F9; Wed, 10 Jul 2013 06:28:36 +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 JAA01202; Wed, 10 Jul 2013 09:28:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UwntC-000HWD-FD; Wed, 10 Jul 2013 09:28:34 +0300 Message-ID: <51DCFEDA.1090901@FreeBSD.org> Date: Wed, 10 Jul 2013 09:27:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Deadlock in nullfs/zfs somewhere References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 06:28:37 -0000 on 09/07/2013 16:03 Adrian Chadd said the following: > Does anyone have any ideas as to what's going on? Please provide output of 'thread apply all bt' from kgdb, then perhaps someone might be able to tell. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 06:57:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 19AF218C for ; Wed, 10 Jul 2013 06:57:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id A4C4A180B for ; Wed, 10 Jul 2013 06:57:17 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id c41so4624442eek.12 for ; Tue, 09 Jul 2013 23:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Ca1s26kkZTS1CyFaWnLKypVFT8Qeao4IUHONoLD5MdI=; b=M9YLA352Ot7rKs8TjRd1ryex7QGwur+4Wgg9FWjKod4tpcOMScX/OeEoUu1XLe6BrY ct43mIpjIPa1Z28YAK1A6iFLVSIEzUfRSm7yBqSNoFiD/5XYINiZ76p+TKt1rh7E82FQ wUklTZB/+UyqXILUCfkwS1P4v4Co/RKMDRD+iJrtR6tXnaoj5sMcvF4wKw7245ZeE8N8 xWFM62MEHojK4ZWTJLFOOIWrsqrOKr36Os1phqa1OsQHNP+L5ymVGD2Au0AS5Pv8hqlP INrkpwLEIBfQ43DHv5/jTQmoJQlNVISwdPZccdzNwxxOzn7XPnh1FoT2G9PDTrO8bJOW 3Dhw== X-Received: by 10.14.251.202 with SMTP id b50mr34482180ees.85.1373439436569; Tue, 09 Jul 2013 23:57:16 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id b7sm57371067eef.16.2013.07.09.23.57.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 23:57:14 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Jul 2013 15:57:01 +0900 From: Yonghyeon PYUN Date: Wed, 10 Jul 2013 15:57:01 +0900 To: Denis D Subject: Re: msk0 watchdog timeout and interrupt storm Message-ID: <20130710065701.GD2753@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 06:57:18 -0000 On Sun, Jul 07, 2013 at 10:10:42PM +0200, Denis D wrote: > Hello Community,I hope someone could help me with this problem. The last days I have tried to find a solution, but haven't found one.The watchdog timeout happens, when I'm going to download something or copy a file on my FTP server. When I start the transfer of the file, I wait a moment and then my down-/upload freezes at something around 500 KB. After waiting a little while or press a key like "return", it comes to the interrupt storm. > interrupt storm detected on "irq51:"; throttling interrupt source. > Here is some information about my system: > ifconfig msk0msk0: flags=8843 metric 0 mtu 1500 > options=c009b > ether bc:ae:c5:5a:ef:ec > inet 192.168.2.30 netmask 0xffffff00 broadcast 192.168.2.255 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > pciconf -lv > mskc0@pci0:3:0:0: class=0x020000 card=0x84391043 chip=0x438111ab rev=0x11 hdr=0x00 > vendor = 'Marvell Technology Group Ltd.' > device = 'Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB]' > class = network > subclass = ethernetvmstat -iinterrupt total rate > irq1: atkbd0 916 2 > irq16: hdac1 97 0 > irq17: ehci0 ehci1+ 8729 21 > irq18: ohci0 ohci1* 67 0 > irq19: ahci1 2883 7 > irq25: hdac0 4 0 > irq51: mskc0 90 0 > irq256: hpet0:t0 30332 75 > Total 43118 107 > My loader.conf: > hw.msk.msi_disable=1 > hw.pci.enable_msi=0 > hw.pci.enable_msix=0 > My rc.conf > hostname="FreeBSD.local.domain" > keymap="german.iso.acc.kbd" > ifconfig_msk0="DHCP"sshd_enable="YES" > moused_enable="YES" > powerd_enable="YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev="AUTO" > I have also tried to change ifconfig_msk0="DHCP" to ifconfig_msk0="SYNCDHCP" but nothing changed.If nothing helps, I will buy a new network card. If you use dual-boot, please try "cold-boot" it. Other OS may have put the PHY into weird state. Cold-boot shall make firmware restore its PHY configuration. > P.S: Can someone delete my other 2 posts? The format of them was horrible and the another one has no subject :( From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 10:33:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F29745D for ; Wed, 10 Jul 2013 10:33:15 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE6C11E5 for ; Wed, 10 Jul 2013 10:33:14 +0000 (UTC) Received: from outgoing.leidinger.net (pD9FBB33F.dip0.t-ipconnect.de [217.251.179.63]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 316CA84408D; Wed, 10 Jul 2013 12:32:59 +0200 (CEST) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id B30D5E12; Wed, 10 Jul 2013 12:32:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1373452376; bh=RvikkPA8o0mm7tTMlt3Xy11hofqXCszL0LW5xvvGWxw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Iv7B5HqFR+ZzcSv6njQb+ZZRBst2u7zaTJrUbYiPvHvrKKdrcBb6etgi+zKCapmYA h/qJLKtgJCKn5UvnInadFCv3YtaKKOOZbup6orywFPQNTFoyb+I2nFCanz/swyLlki M5rIOoP/oL/0a6VBBXrAj2AU+mC+LCgBK/efjiJUQ0UB8VoQDQb0h6b8NZxHH8MNuC tnBNcIonI0moLlFJOzip4YdeiO7rIVcKLeMzAXAewpenEC7W+pIyaRKHWerTkTAz1G h4WgxSc1ni07JrxZX9Jz6FMjpIbRnwt6aXHmX8deCCWu5wSflfdppe9bFvMJGq9o/i 4nnlozeTfVB5A== Date: Wed, 10 Jul 2013 12:32:54 +0200 From: Alexander Leidinger To: Andreas Tobler Subject: Re: kernel compile broken in latest HEAD Message-ID: <20130710123254.00004266@unknown> In-Reply-To: <51DC750C.6090707@fgznet.ch> References: <20130709173233.275469b4@ernst.home> <20130709223356.000005ad@unknown> <51DC750C.6090707@fgznet.ch> X-Mailer: Claws Mail 3.9.1-2-g66aa06 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 316CA84408D.A1788 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.986, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.12, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01, URIBL_BLOCKED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1374057180.59643@iOIHfWy+bX3mKpquN+f62w X-EBL-Spam-Status: No Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 10:33:15 -0000 On Tue, 09 Jul 2013 22:39:40 +0200 Andreas Tobler wrote: > On 09.07.13 22:33, Alexander Leidinger wrote: > > Here's what I wrote as a reference: > > ---snip--- > > Does someone know what this is supposed to result in? > > > > I would assume as the unions are unnamed and no variable is declared > > inside the struct with it, that the size of the struct is the same > > as not having those unions inside the structs. > > > > If this is correct I would assume the correct fix would be to #if-0 > > them out. > > ---snip--- > > I did so and my kernelbuild is happy now. Yes, I do not use this > header at all. The linuxulator uses it for v4l2 compatibility. If you use skype, you use the header. The fix above is wrong (it changes the size of the structs with gcc and with clang). I will commit a fix in a few minutes. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 10:42:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6025495C for ; Wed, 10 Jul 2013 10:42:39 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6B61279 for ; Wed, 10 Jul 2013 10:42:39 +0000 (UTC) Received: from outgoing.leidinger.net (pD9FBB33F.dip0.t-ipconnect.de [217.251.179.63]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 714A18440CF; Wed, 10 Jul 2013 12:42:25 +0200 (CEST) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id D64E8E14; Wed, 10 Jul 2013 12:42:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1373452943; bh=H4tYXhy8V/yClkB6NqOJpbvfMEgKdGShUCtXAuFE9Bw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=AM93o2GuPiMHrHMvPIlad4R9VwsbeqmRHqa5CNpVz2vtV29siXnDhjfGlY/5B/XSK h3wN5ceSNx/7rk95+4LcEvNsQWiiq0h3oBaSrrggs4fr9v3enKAeK0M/ByMzPTVwzo IGqFTnlLN35kO/tik8TCwMtpQS6vItkaIoVMCzACofbnjtXR8LXnuz2Y0sbseEygC8 TLgpLd4Pqa0AltGQ5IaUPjsxIVSSzER2n3K6TU7zFpsbpbOnnprf/JV1dOgn20eWty SmXoI2onQq/87j4adMMp/27V4yIW/6wEcaqtO3ttquxv8R7Lv4uuOm7uo5hEpMAXqz nc4M/i+Zodwqw== Date: Wed, 10 Jul 2013 12:42:21 +0200 From: Alexander Leidinger To: Michael Butler Subject: Re: SVN r252892: videodev2.h update breaks gcc compilation Message-ID: <20130710124221.0000583a@unknown> In-Reply-To: <51D94A2F.30401@protected-networks.net> References: <51D94A2F.30401@protected-networks.net> X-Mailer: Claws Mail 3.9.1-2-g66aa06 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 714A18440CF.A0744 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.993, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.12, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01, URIBL_BLOCKED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1374057746.2344@kbti6D/TRXxbXwx2R24CMw X-EBL-Spam-Status: No Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 10:42:39 -0000 On Sun, 07 Jul 2013 06:59:59 -0400 Michael Butler wrote: > The recent linux header update triggers the following error: > > In file included from /usr/src/sys/compat/linux/linux_ioctl.c:91: > /usr/src/sys/contrib/v4l/videodev2.h:430: warning: declaration does > not declare anything Can you please try a recent -current, I just committed a fix for this. Thanks, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 10:43:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0F1C1A6D for ; Wed, 10 Jul 2013 10:43:10 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C1F5F128A for ; Wed, 10 Jul 2013 10:43:09 +0000 (UTC) Received: from outgoing.leidinger.net (pD9FBB33F.dip0.t-ipconnect.de [217.251.179.63]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 4C7CC8443B2; Wed, 10 Jul 2013 12:43:04 +0200 (CEST) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id B9370E15; Wed, 10 Jul 2013 12:43:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1373452981; bh=KjQeT+02pPSC30tHtKKOCpkqThxJDAdgJcxieni+sww=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DBO7x0/NpxzUqm4twjgCuHfBlZ+6Uwgr6L56JVCYxMi1e4TrDy9+/xmcKOVUSnT8z DyuFaEVB4q9YSFvML6mnS9ISbemk+ZIuaXZop8Mpx2eX30S63pqt4ITzCPwSPQ7Z4D YQ7s/FHxDw4/2opGFYV+6KW+H0lr6c/4oZ+WAu4QffHyDrDPA0R67QcwNumkPhcfop 6VkV+pHi/UdvYW1gOiEFvHyFVmhzqkqsFHGbh3iYDNtGGkAtpQX1PwB2ysrrRPuUYQ t0XbFI5iC7zElFOBbnZDC81CUY3v0bQY5pzRz0ZBpl89+V7XGBLvR2GiGDqJ3JxJCi fXLnqc5jVmuvw== Date: Wed, 10 Jul 2013 12:43:00 +0200 From: Alexander Leidinger To: gljennjohn@googlemail.com Subject: Re: kernel compile broken in latest HEAD Message-ID: <20130710124300.000073fb@unknown> In-Reply-To: <20130709173233.275469b4@ernst.home> References: <20130709173233.275469b4@ernst.home> X-Mailer: Claws Mail 3.9.1-2-g66aa06 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 4C7CC8443B2.A38AD X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.999, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.11, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01, URIBL_BLOCKED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1374057785.29324@q1/6Vbaq+6D6uiYgJeD30A X-EBL-Spam-Status: No Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 10:43:10 -0000 On Tue, 9 Jul 2013 17:32:33 +0200 Gary Jennejohn wrote: > I simply named them all x to get the kernel to compile, which > succeeded. I committed such a fix, can you please verify that it's ok for you? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 10:55:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2A5E63FA for ; Wed, 10 Jul 2013 10:55:51 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id E93721348 for ; Wed, 10 Jul 2013 10:55:50 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sweb; b=26o8EEbRbiqZ+U02P+D kuMD/RTo3PTYsoZTG2YZmCPaNykK+VxDqQ2davgMsHAqBrBNiedwuICoYO5L1Dzt 5fmjgRKsxDI5MMG/FpFg+hbbRSYlYUGDn6L97SMEZ5A0/kuVun8ar9j0iUusBjxC XG3Y2vW9kPNJnOP9mgRH9hvw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sweb; bh=kE3aRJHASQUD0IYOtKKYsfShW //TNzZYzaCS29AGNaw=; b=n6LBmFG25tipXXbPwcaeRYM55Zcg7Qxq+aUiVK52w Ei4ehLM/j9qXGSkMDESRhajFCohaSjRT5eeKwbFRdJ5s8VKjtHq3fdCVj/AWrXaa S6BFT28tuooMCVnw1IwzEONuLFYDNmHTLvg3OmK9ugRjy3Z1ao4IblcYxMsrFaf2 zk= Received: (qmail 34209 invoked from network); 10 Jul 2013 05:49:08 -0500 Received: from unknown (HELO ?10.10.0.24?) (bryan@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Jul 2013 05:49:08 -0500 Message-ID: <51DD3C1F.1000609@shatow.net> Date: Wed, 10 Jul 2013 05:49:03 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org, FreeBSD Current Subject: NFS panic: newnfs_copycred: negative nfsc_ngroups (client HEAD r253033, server 9.1-R) X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 10:55:51 -0000 I received this panic on the client while doing heavy parallel reads/writes over NFS. I only recently moved these files to NFS, so I don't know whether or not it's a recent regression. Client: HEAD r253033 Server: 9.1-R core.txt: http://people.freebsd.org/~bdrewery/nfs.txt fstab of related paths: > tank:/tank/distfiles/freebsd /mnt/distfiles nfs rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv4 0 0 > tank:/usr/packages/ /mnt/all-packages nfs rw,bg,noatime,soft,retrycnt=3,rsize=65536,wsize=65536,readahead=8,nfsv4 0 0 Server: params on these paths: -maproot=root -network 10.10.0.0/16 tcpdump at the time: > 21:43:05.396585 IP 10.10.0.7.4180315003 > 10.10.0.5.2049: 168 getattr fh 0,4/2 > 21:43:05.396589 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48265029:48266477, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396603 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48266477:48267925, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396605 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48266477, win 3916, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396608 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48267925:48269373, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396621 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48269373:48270821, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396624 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48269373, win 3870, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396641 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48270821:48272269, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396653 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48272269:48273717, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396656 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48272269, win 3825, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396659 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48273717:48275165, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396671 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48275165:48276613, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396674 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48275165, win 3780, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396676 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48276613:48278061, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 > 21:43:05.396689 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq 48278061:48279509, ack 4394885, win 29124, options [nop,nop,TS val > Write failed: Broken pipe I have nfsuserd running on both client/server. nfscbd is running. nfs_client_enable=yes in rc.conf. User lookups seem to work fine: > -rw-r--r-- 1 root bryan 1554804 Jul 6 10:50 /mnt/distfiles/pkg-1.1.4.tar.xz I ran a find -ls on these paths and all files return a user/group. I am guessing there is a race condition with files being written and looking up the associated groups. -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 11:22:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75E81906 for ; Wed, 10 Jul 2013 11:22:32 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE401694 for ; Wed, 10 Jul 2013 11:22:31 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id it16so2746168bkc.41 for ; Wed, 10 Jul 2013 04:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=Oga2hqSxb4n9B7/Sn/WGJdFdnUnFJ+57tJdsUJ5gz6I=; b=1Du01OtXHg0/Oby9zLA4IaQTd9dNo4yN0fdCZAAbsS3n/dkI1NTZCObv+bDS/3j4s0 RogO2UWExiT7oBEvIj5WCGDYCrhPqGOtYkMClTTzTwcyLFP4SqLlkHOK+ITbs0S0CxaO 0OTXFYVHYPamMiE/ZAFsWiaAYlph/oh153kXPc9f8AzHO/V+xRoDE9HtT+11z9kk3bqz SX6C4+FBU5p0FfJmTLOWMIjLK91x1TWtSuoQeXl82SVxIqBWAz+xBkdDiNIC3g4RCEry yk1n8FD55bb0uqx/dBJ5jFPM23gqIO1Sd3Zi8RJ4FjrBBDiaPXcMvTAcm2jBaNjY1HP2 v8yg== X-Received: by 10.205.34.14 with SMTP id sq14mr4940215bkb.100.1373455350934; Wed, 10 Jul 2013 04:22:30 -0700 (PDT) Received: from ernst.home (p578E11E1.dip0.t-ipconnect.de. [87.142.17.225]) by mx.google.com with ESMTPSA id ok9sm6902319bkb.8.2013.07.10.04.22.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 04:22:30 -0700 (PDT) Date: Wed, 10 Jul 2013 13:22:27 +0200 From: Gary Jennejohn To: Alexander Leidinger Subject: Re: kernel compile broken in latest HEAD Message-ID: <20130710132227.4e51370e@ernst.home> In-Reply-To: <20130710124300.000073fb@unknown> References: <20130709173233.275469b4@ernst.home> <20130710124300.000073fb@unknown> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 10 Jul 2013 11:22:32 -0000 On Wed, 10 Jul 2013 12:43:00 +0200 Alexander Leidinger wrote: > On Tue, 9 Jul 2013 17:32:33 +0200 > Gary Jennejohn wrote: > > > I simply named them all x to get the kernel to compile, which > > succeeded. > > I committed such a fix, can you please verify that it's ok for you? > Yup, it works. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 11:44:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 73CC5C6A; Wed, 10 Jul 2013 11:44:17 +0000 (UTC) (envelope-from trashcan@odo.in-berlin.de) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.60.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3288417E0; Wed, 10 Jul 2013 11:44:17 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mail.kaan-bock.invalid [10.10.10.1]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bqz803B3JzLFP; Wed, 10 Jul 2013 13:44:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at enfer-du-nord.net Received: from mx1.enfer-du-nord.net ([10.10.10.1]) by mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [10.10.10.1]) (amavisd-new, port 10024) with LMTP id oYkVwAnS9f0t; Wed, 10 Jul 2013 13:44:16 +0200 (CEST) Received: from mx1.enfer-du-nord.net (www.kaan-bock.invalid [10.10.10.2]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bqz7x02qhzLFD; Wed, 10 Jul 2013 13:44:12 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Jul 2013 13:44:12 +0200 From: Michael Grimm To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: =?UTF-8?Q?ipv=36=5Faddrs=5FIF=20aliases=20in=20rc=2Econf=28?= =?UTF-8?Q?=35=29?= In-Reply-To: <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> Message-ID: X-Sender: trashcan@odo.in-berlin.de User-Agent: Roundcube Webmail/0.9.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 11:44:17 -0000 Hi -- [Upcoming code freeze in stable] On 2013-04-13 22:15, Michael Grimm wrote: > On 13.04.2013, at 14:29, Kimmo Paasiala wrote: > [great deal of simplification by ipv6_addrs_IF] > >> Sorry to resurrect this thread but since nothing has happened in about >> three months I have to ask: What can I do to have this commited to >> HEAD? > > +1 > > Nowadays -where IPv6 becomes more and more available by ISPs- I > *really* > would like to see this simplification implemented, soon, very soon. The > current scheme is way to much error prone, and, its a pain in the ass! > > Thanks for the patch, > Michael Will that patch make it into 9.2? If I am not mistaken, that patch isn't in stable yet. Regards, Michael From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 11:46:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0EAFF6F; Wed, 10 Jul 2013 11:46:13 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7A39C1813; Wed, 10 Jul 2013 11:46:13 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5BDC820A45; Wed, 10 Jul 2013 07:46:12 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 10 Jul 2013 07:46:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=mkT660NgTDYLF/wnWGO7lS7nz7o=; b=Eocc0BH2iUdXJo6CvX98I gmqWITB1SNRViYDHfnBGDI3roy6VXMs/L/kLiuV+n/4MbnRpWxOpuwrM41rcZ2HM oL0l+NfkzuZyod+Hrkbt8VQ++aeqwBWA1j522FgO3C4jvc58g9VvrDGBKBy4Lm9d XWNx9IALJLi69JfjbgJ2y4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:subject:references:date :mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=mkT660NgTDYLF/wnWGO7lS7nz7o=; b=t2A5 eF1n9153NjDgDRSd3PFhZCrtotxxtn73BL9NJTkEXKv+yaBB3U80mGGizDdrn11B pr5u1Y05yUeug01XHYl3uI63lsS6lO4HfF0D/J94zMfEpUPdjWg1PgT2T7NHZ+qx GsWwWi6VGJAOKKsaJISwaC+hBxNDPiJZ55mQ1ds= X-Sasl-enc: OuIWAZofUgC6xcl9cBR4kS8Wr7ARvQByZcCNi44Z62bk 1373456772 Received: from tech304.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A42E68021F; Wed, 10 Jul 2013 07:46:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, "Michael Grimm" Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> Date: Wed, 10 Jul 2013 06:46:11 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 11:46:13 -0000 On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm wrote: > Will that patch make it into 9.2? If I am not mistaken, that patch isn't > in stable yet. I would also like to see this patch hit 9.x sooner than later. It's so painful when someone forgets to fix the alias numbering on servers with many, many IPv4 and IPv6 addresses... From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 12:32:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0693D27 for ; Wed, 10 Jul 2013 12:32:26 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id 86D531AE0 for ; Wed, 10 Jul 2013 12:32:25 +0000 (UTC) Received: from localhost ([92.136.146.119]) by mwinf5d61 with ME id ycYJ1l0022anTkU03cYJ7W; Wed, 10 Jul 2013 14:32:19 +0200 Message-ID: <51DD5451.2010801@orange.fr> Date: Wed, 10 Jul 2013 14:32:17 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130624 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: "Stale NFS file handle" for NFS exported UFS from r252435 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@freebsd.org, pfg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 12:32:26 -0000 Hi, Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to r253007, I have hit the following: claude@zorglub$ mount_nfs watson:/home /mnt claude@zorglub$ /bin/ls /mnt/ claude doc.old ports.old sysref distfiles obj portsperso xorg-dev doc ports src xtrafiles claude@zorglub$ /bin/ls /mnt/claude ls: /mnt/claude: Stale NFS file handle claude@zorglub$ /bin/ls /mnt/ports.old CHANGES UPDATING dns multimedia textproc COPYRIGHT accessibility editors net www ... some directories may be listed, for the others the result is "Stale NFS file handle" This exists for a 8.4-STABLE client system, for a 9.1-STABLE client system, and also with a local mount (localhost) on the server system itself. I checked with memsticks of official snapshots (to eliminate the influence of local patches and customized kernels), with the result: FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected Doing a binary search on the kernel source (without any patch) lead to the "culprit": ---------------------------------------------------------------------- Author: pfg Date: Mon Jul 1 03:00:15 2013 New Revision: 252435 URL: http://svnweb.freebsd.org/changeset/base/252435 Log: Change i_gen in UFS to an unsigned type. In UFS, i_gen is a random generated value and there is not way for it to be negative. Actually, the value of i_gen is just used to match bit patterns and it is of not consequence if the values are signed or not. Following other filesystems, set it to unsigned and use it as such, Discussed by: mckusick Reviewed by: mckusick (previous version) MFC after: 4 weeks Modified: head/sys/ufs/ffs/ffs_vfsops.c head/sys/ufs/ufs/dinode.h head/sys/ufs/ufs/inode.h head/sys/ufs/ufs/ufs_extattr.c ---------------------------------------------------------------------- which is entirely UFS (not NFS) related. CCing pfg@ as the committer, and rmacklem@ just in case.. Thanks for your attention Claude Buisson From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 12:56:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D6C8359; Wed, 10 Jul 2013 12:56:30 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2D81BCD; Wed, 10 Jul 2013 12:56:30 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id B53F76208; Wed, 10 Jul 2013 08:56:22 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=gDNL7/nPJ8WixPxik9g8NumpFB7hQ1MvLvFKbW3Ge1qoETKzIxVV6ZvU+r8nxiRcp 8ndSaylpTcG6/7AeoNBZa0rSHw/wHD7lH6R/Lzvd8syhGYO4iBXXyaioJ8M3DYw Message-ID: <51DD59F4.9080707@protected-networks.net> Date: Wed, 10 Jul 2013 08:56:20 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130626 Thunderbird/17.0.7 MIME-Version: 1.0 To: Claude Buisson Subject: Re: "Stale NFS file handle" for NFS exported UFS from r252435 References: <51DD5451.2010801@orange.fr> In-Reply-To: <51DD5451.2010801@orange.fr> X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rmacklem@freebsd.org, FreeBSD Current , pfg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 12:56:30 -0000 On 07/10/13 08:32, Claude Buisson wrote: > Hi, > > Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to > r253007, I have hit the following: > > claude@zorglub$ mount_nfs watson:/home /mnt > claude@zorglub$ /bin/ls /mnt/ > claude doc.old ports.old sysref > distfiles obj portsperso xorg-dev > doc ports src xtrafiles > claude@zorglub$ /bin/ls /mnt/claude > ls: /mnt/claude: Stale NFS file handle > claude@zorglub$ /bin/ls /mnt/ports.old > CHANGES UPDATING dns multimedia textproc > COPYRIGHT accessibility editors net www > ... > > some directories may be listed, for the others the result is "Stale NFS > file handle" +1 I was trying to work out what this was .. thanks for identifying, imb From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 13:18:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FDC89F9; Wed, 10 Jul 2013 13:18:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by mx1.freebsd.org (Postfix) with ESMTP id 03C7B1CB2; Wed, 10 Jul 2013 13:18:34 +0000 (UTC) Received: from [78.35.164.14] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UwuHk-0000H8-QS; Wed, 10 Jul 2013 15:18:20 +0200 Date: Wed, 10 Jul 2013 15:18:22 +0200 From: Fabian Keil To: Andre Oppermann Subject: Re: Improved SYN Cookies: Looking for testers Message-ID: <20130710151821.5a8cf38a@fabiankeil.de> In-Reply-To: <51DA68B8.6070201@freebsd.org> References: <51DA68B8.6070201@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/bEiWjWD8oQNb.ag.VQbG9gv"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 13:18:35 -0000 --Sig_/bEiWjWD8oQNb.ag.VQbG9gv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > We have a SYN cookie implementation for quite some time now but it > has some limitations with current realities for window scaling and > SACK encoding the in the few available bits. >=20 > This patch updates and improves SYN cookies mainly by: >=20 > a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN > (initial sequence number) without the use of timestamp bits. >=20 > b) switching to the very fast and cryptographically strong SipHash-2-4 > hash MAC algorithm to protect the SYN cookie against forgery. >=20 > The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). >=20 > Please find it here for testing: >=20 > http://people.freebsd.org/~andre/syncookie-20130708.diff I've been using the patch for a couple of days and didn't notice any issues so far. Privoxy's regression tests continue to work as expected as well. BTW, I think kern/173309 could be closed. Fabian --Sig_/bEiWjWD8oQNb.ag.VQbG9gv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHdXx4ACgkQBYqIVf93VJ2/hwCgtKxRfpacubgmb4uvcQWAhKCW 8HAAnj6vE4HccN9hmWSFsBOE7+VMtXPB =gv2W -----END PGP SIGNATURE----- --Sig_/bEiWjWD8oQNb.ag.VQbG9gv-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 13:54:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C809851 for ; Wed, 10 Jul 2013 13:54:08 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by mx1.freebsd.org (Postfix) with ESMTP id 04FB81EF3 for ; Wed, 10 Jul 2013 13:54:07 +0000 (UTC) Received: from localhost ([92.136.146.119]) by mwinf5d23 with ME id ydtz1l00U2anTkU03dtzoH; Wed, 10 Jul 2013 15:54:00 +0200 Message-ID: <51DD6777.90803@orange.fr> Date: Wed, 10 Jul 2013 15:53:59 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130624 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435 References: <51DD5451.2010801@orange.fr> In-Reply-To: <51DD5451.2010801@orange.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@freebsd.org, pfg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 13:54:08 -0000 On 07/10/2013 14:32, Claude Buisson wrote: > Hi, > > Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to r253007, I > have hit the following: > > claude@zorglub$ mount_nfs watson:/home /mnt > claude@zorglub$ /bin/ls /mnt/ > claude doc.old ports.old sysref > distfiles obj portsperso xorg-dev > doc ports src xtrafiles > claude@zorglub$ /bin/ls /mnt/claude > ls: /mnt/claude: Stale NFS file handle > claude@zorglub$ /bin/ls /mnt/ports.old > CHANGES UPDATING dns multimedia textproc > COPYRIGHT accessibility editors net www > ... > > some directories may be listed, for the others the result is "Stale NFS file handle" > > This exists for a 8.4-STABLE client system, for a 9.1-STABLE client system, and > also with a local mount (localhost) on the server system itself. > > I checked with memsticks of official snapshots (to eliminate the influence of > local patches and customized kernels), with the result: > > FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected > > FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected > > Doing a binary search on the kernel source (without any patch) lead to the > "culprit": > > ---------------------------------------------------------------------- > Author: pfg > Date: Mon Jul 1 03:00:15 2013 > New Revision: 252435 > URL: http://svnweb.freebsd.org/changeset/base/252435 > > Log: > Change i_gen in UFS to an unsigned type. > > In UFS, i_gen is a random generated value and there is not way for > it to be negative. Actually, the value of i_gen is just used to > match bit patterns and it is of not consequence if the values are > signed or not. > > Following other filesystems, set it to unsigned and use it as such, > > Discussed by: mckusick > Reviewed by: mckusick (previous version) > MFC after: 4 weeks > > Modified: > head/sys/ufs/ffs/ffs_vfsops.c > head/sys/ufs/ufs/dinode.h > head/sys/ufs/ufs/inode.h > head/sys/ufs/ufs/ufs_extattr.c > ---------------------------------------------------------------------- > > which is entirely UFS (not NFS) related. > Reverting 252435 + 252437 and rebuilding the kernel seems to give back a working system. Claude Buisson From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 13:58:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62DC6A89; Wed, 10 Jul 2013 13:58:11 +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 24D161F54; Wed, 10 Jul 2013 13:58:10 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UwuuI-003yZu-34>; Wed, 10 Jul 2013 15:58:10 +0200 Received: from e179143131.adsl.alicedsl.de ([85.179.143.131] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UwuuH-003t8L-Vw>; Wed, 10 Jul 2013 15:58:10 +0200 Date: Wed, 10 Jul 2013 15:58:09 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , freebsd-toolchain@freebsd.org Subject: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity Message-ID: <20130710155809.0f589c22@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ywAEzP3/20OqfEtueqUVkry"; protocol="application/pgp-signature" X-Originating-IP: 85.179.143.131 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 13:58:11 -0000 --Sig_/ywAEzP3/20OqfEtueqUVkry Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Whe I try to compile the sources of a port in spe (devel/pocl), which is now out as RC6, I receive this error shown below: [...] ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error: conversion from 'int' to 'boolvec_t' (aka 'boolvec') is ambiguous boolvec_t isinf() const { return std::isinf(v); } ^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: candidate constructor boolvec(bvector_t x): v(x) {} ^ ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate constructor boolvec(bool a): v(a) {} [...] Compilation is performed on the most recent CURRENT with CLANG 3.3 and devel/llvm (which is obviously stuck with 3.2 for now) and option switches -std=3Dc++11 -stdlib=3Dlibc++. As I was told, in standard C++11, isnan(), isinf() and fellows now should return "bool", not int as this seems obviously the case as the error documents and I was able to check with a small program. Is this a bug in FreeBSD's implementation of libc++? Or am I doing something wrong? I'm new to C++/C++11. Some advice or explanation could be helpful. regards, Oliver --Sig_/ywAEzP3/20OqfEtueqUVkry Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJR3WhxAAoJEOgBcD7A/5N8LkAIAJfH+p2e3+BNB2QiNYny1NEZ tVST4i7a7D9IW9HpcPReovP+kewFvOifG0tfJ+fMm3CazCswrYx6NE/D73rb3ELv /FTYLMjxAJ9+MgLKeT2KfMlgOF+6iItcwF8q4HoDtP+frfBMcwU9eurncxul8uS+ IkJ5GkiN/n0vmSn59OJ5URfON4BrsB/PhMi5v6MGTKBURbrn/30tBvFHUmOtVB6C nfDOHRh3DkpOMtv34S4+EMo6D5CRBAmGtqat6L8aGuRpkFlEXXGaptGjwjIcOJ06 ExyswMDXiIbzx990y9r22iASNeu/wnQhCwz6WBG/DzJYQfJ+GH0tsfUEar9Yp/g= =MfJY -----END PGP SIGNATURE----- --Sig_/ywAEzP3/20OqfEtueqUVkry-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 14:23:05 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58256847; Wed, 10 Jul 2013 14:23:05 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0B51102; Wed, 10 Jul 2013 14:23:04 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6AEN3OE099299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Jul 2013 14:23:04 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_207DEF59-C596-4AAA-9DCB-2EC9FC626995"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: David Chisnall In-Reply-To: <20130710155809.0f589c22@thor.walstatt.dyndns.org> Date: Wed, 10 Jul 2013 15:22:58 +0100 Message-Id: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> To: "O. Hartmann" X-Mailer: Apple Mail (2.1503) Cc: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 14:23:05 -0000 --Apple-Mail=_207DEF59-C596-4AAA-9DCB-2EC9FC626995 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 10 Jul 2013, at 14:58, "O. Hartmann" = wrote: >=20 > Whe I try to compile the sources of a port in spe (devel/pocl), which > is now out as RC6, I receive this error shown below: >=20 > [...] > ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error: > conversion from 'int' to 'boolvec_t' (aka 'boolvec') is > ambiguous boolvec_t isinf() const { return std::isinf(v); } > ^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: > candidate constructor boolvec(bvector_t x): v(x) {} > ^ > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate > constructor boolvec(bool a): v(a) {} > [...] >=20 > Compilation is performed on the most recent CURRENT with CLANG 3.3 and > devel/llvm (which is obviously stuck with 3.2 for now) and option > switches -std=3Dc++11 -stdlib=3Dlibc++. >=20 > As I was told, in standard C++11, isnan(), isinf() and fellows now > should return "bool", not int as this seems obviously the case as the > error documents and I was able to check with a small program. >=20 > Is this a bug in FreeBSD's implementation of libc++? Or am I doing > something wrong? >=20 > I'm new to C++/C++11. >=20 >=20 > Some advice or explanation could be helpful. I believe that this is also causing some failures in the libc++ test = suite and is due to some interaction between our headers and the libc++ = headers, but I don't see where it is. Our isnan implementation is a really ugly macro that looks like this: #define>isnan(x) \ ((sizeof (x) =3D=3D sizeof (float)) ? __isnanf(x) \ : (sizeof (x) =3D=3D sizeof (double)) ? isnan(x) \ : __isnanl(x)) The definition in the libc++ cmath header is: #ifdef isnan template _LIBCPP_ALWAYS_INLINE bool __libcpp_isnan(_A1 __x) _NOEXCEPT { return isnan(__x); } #undef isnan This should work correctly. However... I wonder if you are including math.h instead of ? That would = show the result that you appear to be seeing, which looks like the = result of using the isnan() macro rather than the isnan() function. If = you have included then the isnan() macro will have been defined. David --Apple-Mail=_207DEF59-C596-4AAA-9DCB-2EC9FC626995 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR3W5DAAoJEKx65DEEsqIdpMcQAJFPGPHktElFQHRQ0VMRFTqI qhoWL0A0W2UBKaYcXX9OTzRjoE3jVYRKsj9/3ZDJuZ2z02o5lHa1Wir8dfGpTK05 MSoB30IWoHNP5dr6x/EiIB6xCuGckvSXPuJ6Jpmns2c7UP907pHPlInrtCUtqqOL jKf5IsURUn7CxGAWLmDAa+RY1B4NjmWiIpmxrrSHNGk7NX4IYPRjKb1T2esrxUqi gVY2QhGzwupaVjUqrPxaSLmwim0LWgwLSrk8oyMy/BXA/s0S33MJTqc3BnEMV6ZZ xpCD8ct9ELGRfGXUyvu2n8Te9Sp8ZXKGnVhu8IAopqkI+0GsoNPNr8ogEiDZZCrk II6CQ/5tCnvDdcETW2Gwe60WZtq5qTyqyYns4AM1+dam4TcQTLoVyD4eVFSlIhdP AOLgNBOieNg0lkKzDHbmR7HgKD90sMTT6kC3sCFmqOc57kbOOuYDpsP/UQFeNrhH 4oG2tRH8OUiu9Kuz79Y5ollCVeDawhnvWdHFv8mVTRTR0GtuKQttwmKoevHM/csG pWiDxuqXa+vsf55cCnMRLM/dWPd3iJnS9pNMgQpO6SstWTUJuBJb75Qhuo/S5+Tl OABSctzzRwoAzx2zb+NPgms3jOjeTdHuZNaYY5ttxEDfz6qQVZT73eiImgdIsm+y CnJF7AollbHrh49w/dsb =8y6+ -----END PGP SIGNATURE----- --Apple-Mail=_207DEF59-C596-4AAA-9DCB-2EC9FC626995-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 15:11:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D6D188C0 for ; Wed, 10 Jul 2013 15:11:41 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm15-vm3.bullet.mail.ne1.yahoo.com (nm15-vm3.bullet.mail.ne1.yahoo.com [98.138.91.145]) by mx1.freebsd.org (Postfix) with ESMTP id 88FD215DE for ; Wed, 10 Jul 2013 15:11:41 +0000 (UTC) Received: from [98.138.226.180] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 15:05:20 -0000 Received: from [98.138.226.56] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 15:05:20 -0000 Received: from [127.0.0.1] by smtp207.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 15:05:20 -0000 X-Yahoo-Newman-Id: 676785.93332.bm@smtp207.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5qJitI4VM1mKu6E6zPrZ5gCMawctHDVEdiRPL2l4iFrVKqc 57kdiNu1nJMcJpn3ZFP7.ySxRGZDJKFxdUXf85Mhe3s3L16.izzc2D2_kQlU ScyEinPf544eMfWoHCWHG1v0sY3b.I8OatlQqmOAlSW6zj7du6V4wwyNhG7L gy4Y8yxiWaJZa8UWFF5Asr38Og69KubKQu0qNOqdv5FdJkM7UEPAv1qpliGx M5bqCelAb2OT9tocw1V3jSxJghpogSQWGmR839V075BkEdsvqAlMcfDVYVtH qIK1PkYIsxuUVQ9111c34uaTcdYtWKo8UoBuTcbS0MvlZ8s2W6TWj2A_ir8G zczgLSvOhTAu110.sUkCFUQ30a9wuKySGQVhKknx1zkJbYNcheU101TBTAXe mRbVMrPILgB5K87EfvIO5di_TZZfIaYxFd_r1LR_f3rXgg_wkbE1_sUOXtiC T2wqZ1MBRQ_GkUYsPQH5JeTf6aKWbIS1FqUS05mWkxwTsU4lGaqBCR8mUtaG W31Pz3GpmLwMz0ueh4393NoBky7JAumDXwJRnlziIuGew5Rj0UcawMTYjKIH Hi1_mOAhIFF_xWQ_Y9dFRnFSU1wUln2mfXRKO23TlYID1D7OXkp.jRDE0vFg syYzJKQQdTVv_ij.vNMB00KN9npgBsgwdKCsFICHg_l1yDT11nba2ZMLqDYo SeV0ivV79bTImKD9AGwWpbXoOLe2sUrn3 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp207.mail.ne1.yahoo.com with SMTP; 10 Jul 2013 08:05:20 -0700 PDT Message-ID: <51DD782E.7090503@FreeBSD.org> Date: Wed, 10 Jul 2013 10:05:18 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130611 Thunderbird/17.0.6 MIME-Version: 1.0 To: Claude Buisson Subject: Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435 References: <51DD5451.2010801@orange.fr> <51DD6777.90803@orange.fr> In-Reply-To: <51DD6777.90803@orange.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 15:11:41 -0000 Hello guys; Thank for finding this, however ... On 10.07.2013 08:53, Claude Buisson wrote: > On 07/10/2013 14:32, Claude Buisson wrote: >> Hi, >> >> Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to >> r253007, I >> have hit the following: >> >> claude@zorglub$ mount_nfs watson:/home /mnt >> claude@zorglub$ /bin/ls /mnt/ >> claude doc.old ports.old sysref >> distfiles obj portsperso xorg-dev >> doc ports src xtrafiles >> claude@zorglub$ /bin/ls /mnt/claude >> ls: /mnt/claude: Stale NFS file handle >> claude@zorglub$ /bin/ls /mnt/ports.old >> CHANGES UPDATING dns multimedia textproc >> COPYRIGHT accessibility editors net www >> ... >> >> some directories may be listed, for the others the result is "Stale >> NFS file handle" >> >> This exists for a 8.4-STABLE client system, for a 9.1-STABLE client >> system, and >> also with a local mount (localhost) on the server system itself. >> >> I checked with memsticks of official snapshots (to eliminate the >> influence of >> local patches and customized kernels), with the result: >> >> FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected >> >> FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected >> >> Doing a binary search on the kernel source (without any patch) lead >> to the >> "culprit": >> >> ---------------------------------------------------------------------- >> Author: pfg >> Date: Mon Jul 1 03:00:15 2013 >> New Revision: 252435 >> URL: http://svnweb.freebsd.org/changeset/base/252435 >> >> Log: >> Change i_gen in UFS to an unsigned type. >> >> In UFS, i_gen is a random generated value and there is not way for >> it to be negative. Actually, the value of i_gen is just used to >> match bit patterns and it is of not consequence if the values are >> signed or not. >> >> Following other filesystems, set it to unsigned and use it as such, >> >> Discussed by: mckusick >> Reviewed by: mckusick (previous version) >> MFC after: 4 weeks >> >> Modified: >> head/sys/ufs/ffs/ffs_vfsops.c >> head/sys/ufs/ufs/dinode.h >> head/sys/ufs/ufs/inode.h >> head/sys/ufs/ufs/ufs_extattr.c >> ---------------------------------------------------------------------- >> >> which is entirely UFS (not NFS) related. >> > > Reverting 252435 + 252437 and rebuilding the kernel seems to give back > a working > system. > > Claude Buisson > While I understand this change caused the issue and I am willing to revert it, I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I presume glusterfs) have unsigned i_gen. Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 15:16:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 73B5FAB2 for ; Wed, 10 Jul 2013 15:16:07 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id D9ADF1638 for ; Wed, 10 Jul 2013 15:16:06 +0000 (UTC) Received: from localhost ([92.136.146.119]) by mwinf5d10 with ME id yfG21l0022anTkU03fG2Au; Wed, 10 Jul 2013 17:16:05 +0200 Message-ID: <51DD7AB1.4090202@orange.fr> Date: Wed, 10 Jul 2013 17:16:01 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130624 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pedro Giffuni Subject: Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435 References: <51DD5451.2010801@orange.fr> <51DD6777.90803@orange.fr> <51DD782E.7090503@FreeBSD.org> In-Reply-To: <51DD782E.7090503@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 15:16:07 -0000 On 07/10/2013 17:05, Pedro Giffuni wrote: > Hello guys; > > Thank for finding this, however ... > > > While I understand this change caused the issue and I am willing to > revert it, > I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I > presume > glusterfs) have unsigned i_gen. > I have the same thinking (and was rather astonished by the success of my try at reverting it): there is something somewhere in the NFS code which have not been synced with the UFS change. It is the reason I CC'ed rmacklem@ > Pedro. > Claude Buisson From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 15:41:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CEAB08B5 for ; Wed, 10 Jul 2013 15:41:14 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm19-vm4.bullet.mail.ne1.yahoo.com (nm19-vm4.bullet.mail.ne1.yahoo.com [98.138.91.179]) by mx1.freebsd.org (Postfix) with ESMTP id 6E77D1876 for ; Wed, 10 Jul 2013 15:41:14 +0000 (UTC) Received: from [98.138.90.55] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 15:34:52 -0000 Received: from [98.138.226.61] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 15:34:52 -0000 Received: from [127.0.0.1] by smtp212.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 15:34:52 -0000 X-Yahoo-Newman-Id: 252160.24413.bm@smtp212.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vzua5N0VM1kqy5MKYFNA06UBZwOrvL6kYZIA6VUR1szkD2w yrwVdnV8lab_FYCDZor6y_kVfEN4VvqNNz2sOWiM35ZZT2B6kAenVcMme1XR SgDBoIROyPs3cimuzDi7ioGbVSac7R8k8y4yfRcz8r.8ggdxYcTeo8IirJLu T_nD2ZhwrDmuctP0EDEBWfvruHB5nuqvJB9wgwItIUFJni0upGINM14QZwVP 6pygJmNTBYNZ.EVKHaARSZ9mNcWAd9Is5wVKslFWpu.XUvsIJWMBsKnhDFEM J_5zX.hvg8qK.LbNaS0uC6.Rpf8Fokws22.0XYm8p9zpuA3R1IxR6QQdYbDE dRk17g5_idwu83d8T.rJ7itANFLCb.PR5xNTkRsgS.8eKlLKRnsHN3E7U38w peYCVTH5g2XV_HdruJLAoamBh3k1vginXKhiGFj7XftvQ5.u0thnxSyCYhLo slD99vok11p11u7jrombyyX1PmlRsWXuwEWJidLueYxhw3Ec8ghN.Zcxr2tS .lIsn4W0blXZ9zrq46I468V_91DrVoY6TNnp_MiPWSlbm0iiXT4PlQg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp212.mail.ne1.yahoo.com with SMTP; 10 Jul 2013 08:34:52 -0700 PDT Message-ID: <51DD7F1A.4010907@FreeBSD.org> Date: Wed, 10 Jul 2013 10:34:50 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130611 Thunderbird/17.0.6 MIME-Version: 1.0 To: Claude Buisson Subject: Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435 References: <51DD5451.2010801@orange.fr> <51DD6777.90803@orange.fr> <51DD782E.7090503@FreeBSD.org> <51DD7AB1.4090202@orange.fr> In-Reply-To: <51DD7AB1.4090202@orange.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 15:41:14 -0000 On 10.07.2013 10:16, Claude Buisson wrote: > On 07/10/2013 17:05, Pedro Giffuni wrote: >> Hello guys; >> >> Thank for finding this, however ... >> > > > >> >> While I understand this change caused the issue and I am willing to >> revert it, >> I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I >> presume >> glusterfs) have unsigned i_gen. >> > > I have the same thinking (and was rather astonished by the success of > my try at > reverting it): there is something somewhere in the NFS code which have > not been > synced with the UFS change. > > It is the reason I CC'ed rmacklem@ > There is an ongoing port of glusterfs, and glusterfs is known to use both NFS and fuse so I think we would have this problem sooner or later. I hope it's easy to find: I did a search for i_gen with opengrok before making this change and couldn't find any user. Fortunately I had no plans to merge the change for 9.2. Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 15:52:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9EB75ED6; Wed, 10 Jul 2013 15:52:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 563C419B9; Wed, 10 Jul 2013 15:52:46 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id ta17so8598914obb.8 for ; Wed, 10 Jul 2013 08:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DQ/dOzjE4CCJ9/a1IBWmFd96ovOGOT2n6xceTmrbVzQ=; b=HO7ZMK73SOc/HKuxmhUxNrUuVkHy7v2L1KdUGlLnwp50xwsEeupeXNCqTq7ymuRbZY WEwYgryq+HfWuVbYa1FpsP4vIzSVYQIuHGoG8l64fuBXrLKSIsfH7VRupdctQ6c8/ECW NQyScFoYpwUO9gx+w4oBMxEbFdd33g1Ho7NyZDdODXEKb9ln97GYb6xTRrgr/gHPnE4+ TyTqoy/1aa/31tYMthQkw9307Ztz14i05hhEEoyaelUCymE+pWymrjSdepU3+A//mDuZ eS+HWPZHYY6Qpt23DPIjhhoSqldZbxOyRVyxQu70wLcYRPw3zkGwsVa/klmix+eHSBDz 5MoQ== MIME-Version: 1.0 X-Received: by 10.182.171.7 with SMTP id aq7mr27791558obc.103.1373471565665; Wed, 10 Jul 2013 08:52:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Wed, 10 Jul 2013 08:52:45 -0700 (PDT) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> Date: Wed, 10 Jul 2013 08:52:45 -0700 X-Google-Sender-Auth: FEKe3C32sctKmByrR5bobS1Cxw8 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kevin Oberman To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , "freebsd-stable@freebsd.org Stable" , Michael Grimm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 15:52:46 -0000 On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < > trashcan@odo.in-berlin.de> wrote: > > Will that patch make it into 9.2? If I am not mistaken, that patch isn't >> in stable yet. >> > > I would also like to see this patch hit 9.x sooner than later. It's so > painful when someone forgets to fix the alias numbering on servers with > many, many IPv4 and IPv6 addresses... > Please, please, please, please, ...! Freeze is only two days away, so time for 9.2 is almost over and I can see no good reason NOT to get this done. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 16:33:22 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 32699DFE; Wed, 10 Jul 2013 16:33:22 +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 E55371C58; Wed, 10 Jul 2013 16:33:21 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UwxKS-0013Yv-Ph>; Wed, 10 Jul 2013 18:33:20 +0200 Received: from e179143131.adsl.alicedsl.de ([85.179.143.131] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UwxKS-0047Op-Kf>; Wed, 10 Jul 2013 18:33:20 +0200 Date: Wed, 10 Jul 2013 18:33:15 +0200 From: "O. Hartmann" To: David Chisnall Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity Message-ID: <20130710183315.725dfde0@thor.walstatt.dyndns.org> In-Reply-To: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/bmcp6YFDEKEE.tdh.y_2A=c"; protocol="application/pgp-signature" X-Originating-IP: 85.179.143.131 Cc: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 16:33:22 -0000 --Sig_/bmcp6YFDEKEE.tdh.y_2A=c Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 10 Jul 2013 15:22:58 +0100 David Chisnall wrote: > Hi, >=20 > On 10 Jul 2013, at 14:58, "O. Hartmann" > wrote: >=20 > >=20 > > Whe I try to compile the sources of a port in spe (devel/pocl), > > which is now out as RC6, I receive this error shown below: > >=20 > > [...] > > ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error: > > conversion from 'int' to 'boolvec_t' (aka 'boolvec') > > is ambiguous boolvec_t isinf() const { return std::isinf(v); } > > ^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note: > > candidate constructor boolvec(bvector_t x): v(x) {} > > ^ > > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate > > constructor boolvec(bool a): v(a) {} > > [...] > >=20 > > Compilation is performed on the most recent CURRENT with CLANG 3.3 > > and devel/llvm (which is obviously stuck with 3.2 for now) and > > option switches -std=3Dc++11 -stdlib=3Dlibc++. > >=20 > > As I was told, in standard C++11, isnan(), isinf() and fellows now > > should return "bool", not int as this seems obviously the case as > > the error documents and I was able to check with a small program. > >=20 > > Is this a bug in FreeBSD's implementation of libc++? Or am I doing > > something wrong? > >=20 > > I'm new to C++/C++11. > >=20 > >=20 > > Some advice or explanation could be helpful. >=20 > I believe that this is also causing some failures in the libc++ test > suite and is due to some interaction between our headers and the > libc++ headers, but I don't see where it is. >=20 > Our isnan implementation is a really ugly macro that looks like this: >=20 > #define>isnan(x) \ > ((sizeof (x) =3D=3D sizeof (float)) ? __isnanf(x) \ > : (sizeof (x) =3D=3D sizeof (double)) ? isnan(x) \ > : __isnanl(x)) >=20 >=20 > The definition in the libc++ cmath header is: >=20 > #ifdef isnan >=20 > template > _LIBCPP_ALWAYS_INLINE > bool > __libcpp_isnan(_A1 __x) _NOEXCEPT > { > return isnan(__x); > } >=20 > #undef isnan >=20 > This should work correctly. >=20 > However... >=20 > I wonder if you are including math.h instead of ? That would > show the result that you appear to be seeing, which looks like the > result of using the isnan() macro rather than the isnan() function. > If you have included then the isnan() macro will have been > defined. >=20 > David >=20 Hi David, thanks for the fast response. The code I was told to check with is this: #include #include #include int main(void) { std::cout << typeid(isnan(1.0)).name() << "\n"; } If I compile it with=20 c++ -o testme -std=3Dc++11 -stdlib=3Dlibc++ source.cc and run the binary, the result is "i" which I interpret as "INT". My OS is at=20 FreeBSD 10.0-CURRENT #4 r253138: Wed Jul 10 09:52:16 CEST 2013 Oliver --Sig_/bmcp6YFDEKEE.tdh.y_2A=c Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJR3YzQAAoJEOgBcD7A/5N8ipIH/RlVZV2UXHNWv/F1Zx7kkAJK 7JFbay3QwLnoLOScXsQB9EoaXbh4ha91P1krgAccg39/esWXeBwdGRkcPe03oYkU BHHfN2RKTIERO71daPL7Y5nan3z9IYY8q0KlnMU7Xf5t/B/CMYXKyASv53s0eyNU tcblIzHHmdVwT1AfEszhBr70umS6SyIqUqlot5L3uqJF+2CTDeHjw7hj8shUN60W Jd/kC8F2zcCEC8UjwEDRDL8556e5NOIuNown6+VOhBCSAv2fiiYQe4hKgJuEfCPx hOALmY6K0uxcF/SlLfxX3fd2QzaAs8ShCiNvvi1Vz+nppCV8ytNRiwf1+xqVtLQ= =vG0c -----END PGP SIGNATURE----- --Sig_/bmcp6YFDEKEE.tdh.y_2A=c-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 16:40:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F63F230 for ; Wed, 10 Jul 2013 16:40:31 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm25-vm0.bullet.mail.ne1.yahoo.com (nm25-vm0.bullet.mail.ne1.yahoo.com [98.138.91.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB181CAE for ; Wed, 10 Jul 2013 16:40:30 +0000 (UTC) Received: from [98.138.101.130] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 16:34:54 -0000 Received: from [98.138.226.31] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 16:34:54 -0000 Received: from [127.0.0.1] by smtp202.mail.ne1.yahoo.com with NNFMP; 10 Jul 2013 16:34:54 -0000 X-Yahoo-Newman-Id: 93961.14573.bm@smtp202.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3GeI2nEVM1kZc2MiPYe8EJ0SBLKwnWqikgUVptSmxylrBGy jisLimFfd2uB_ohsWWL9kTmnIxUzMGvlIExbL58M3BfSqSJzrpsiExRphaPf MIaEaPxOWKpAmoyIYZ3ve.ykhiiyQgEsPJnSor7A3pQWJOoPb5jBFZG4ymyI ufgFAJQAebRORo4V5eUDTbKTlAeukcekLu8LWIsrl4A4Ii04d7T8AyFyhJjM pQv5HLJdXeJqH_m8k0A1mU_QCAkWRmxzFScGwgdWbCx5gfSe49gHfIPGWwpJ ysgJEetWgTANxGsS_hryt1h.O0ebiNIbp_48JbsGjok9atZnB5i42c46ZpoB uhpbE2jDQSVR9bWGa7oE4Keb.Z6sr_ItuYZle8e_xQOpzZgxff9jQQUeY87b zwJMVo9J_sjlLSxYk9Sb6qb8hvvXH5Gws8DuuAUdDKJ_iejdeVd2F8wiNC8I sbiQy0fGG5ZXjfFl1FA_cK2Ch_curlRbuur.iy0a.A.LIsCQ_8CTq_88.d7O xeQ6UCzYlKgUQgMhXyUO0rWTEDAYmevyTnZjBM5vdqeP_Byr.tZJzQ_U5zWU - X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp202.mail.ne1.yahoo.com with SMTP; 10 Jul 2013 09:34:54 -0700 PDT Message-ID: <51DD8D2B.60509@FreeBSD.org> Date: Wed, 10 Jul 2013 11:34:51 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Claude Buisson Subject: Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435 References: <51DD5451.2010801@orange.fr> <51DD6777.90803@orange.fr> <51DD782E.7090503@FreeBSD.org> <51DD7AB1.4090202@orange.fr> In-Reply-To: <51DD7AB1.4090202@orange.fr> Content-Type: multipart/mixed; boundary="------------080203060808070404040503" Cc: rmacklem@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 16:40:31 -0000 This is a multi-part message in MIME format. --------------080203060808070404040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10.07.2013 10:16, Claude Buisson wrote: > On 07/10/2013 17:05, Pedro Giffuni wrote: >> Hello guys; >> >> Thank for finding this, however ... >> > > > >> >> While I understand this change caused the issue and I am willing to >> revert it, >> I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I >> presume >> glusterfs) have unsigned i_gen. >> > > I have the same thinking (and was rather astonished by the success of > my try at > reverting it): there is something somewhere in the NFS code which have > not been > synced with the UFS change. > > It is the reason I CC'ed rmacklem@ > >> Pedro. >> > > Claude Buisson > I found a missing type change. Can you try the attached patch? Cheers, Pedro. --------------080203060808070404040503 Content-Type: text/plain; charset=UTF-8; name="patch-unsigned-ufid_gen" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-unsigned-ufid_gen" Index: sys/ufs/ufs/inode.h =================================================================== --- sys/ufs/ufs/inode.h (revision 253159) +++ sys/ufs/ufs/inode.h (working copy) @@ -180,7 +180,7 @@ u_int16_t ufid_len; /* Length of structure. */ u_int16_t ufid_pad; /* Force 32-bit alignment. */ uint32_t ufid_ino; /* File number (ino). */ - int32_t ufid_gen; /* Generation number. */ + uint32_t ufid_gen; /* Generation number. */ }; #endif /* _KERNEL */ --------------080203060808070404040503-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 16:50:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5C3965A7; Wed, 10 Jul 2013 16:50:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 01FA71D35; Wed, 10 Jul 2013 16:50:20 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id n1so3704244qcx.8 for ; Wed, 10 Jul 2013 09:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AmCt1GzwaZCCpyOCYz8zhrSjI1VPhCiCainfFADeGy4=; b=VC88wQR6AF4PHIiVxA7JEWQPw5P+WXBMPKdfacboTdLVj5DxtuPSOVOrWLpya6n7OW Xah/bOjPBXkp3deY5zg7gBriAHfvrk/Da7PMRsstQikirQZseamM+8c61nHKIUeXKk0o 5Mgff9tKEpMZW7ukE9mYT3ZHVA6DjlhuT7jM3TsQFymSIlKIwDEhD0O9EuR0AnTf9gKh j8y65AFAezKXoonwOva8iGPyh11M5Ea22yVPkUAh1Co/F2t0GjSCmuEHsxXDjOzon6qK 9qtEv5PzDJhMxm7h812WeWzlFR9/MZG15LeHJu/8Q5xuVmzvmHqZVRqNINmX/Qb4hj3A aIeA== MIME-Version: 1.0 X-Received: by 10.224.127.73 with SMTP id f9mr28788036qas.4.1373475020543; Wed, 10 Jul 2013 09:50:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Wed, 10 Jul 2013 09:50:19 -0700 (PDT) In-Reply-To: <51DCFEDA.1090901@FreeBSD.org> References: <51DCFEDA.1090901@FreeBSD.org> Date: Wed, 10 Jul 2013 09:50:19 -0700 X-Google-Sender-Auth: QMfOZsPHqNrttdI8Zn7jI9WzjJw Message-ID: Subject: Re: Deadlock in nullfs/zfs somewhere From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 16:50:21 -0000 On 9 July 2013 23:27, Andriy Gapon wrote: > on 09/07/2013 16:03 Adrian Chadd said the following: >> Does anyone have any ideas as to what's going on? > > Please provide output of 'thread apply all bt' from kgdb, then perhaps someone > might be able to tell. Done - http://people.freebsd.org/~adrian/ath/20130710-vm0-zfs-hang.txt adrian From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 16:51:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DC32730; Wed, 10 Jul 2013 16:51: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 322E61D50; Wed, 10 Jul 2013 16:51:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6AGpQqC062374; Wed, 10 Jul 2013 12:51:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6AGpQMj062354; Wed, 10 Jul 2013 16:51:26 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Jul 2013 16:51:26 GMT Message-Id: <201307101651.r6AGpQMj062354@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:51:34 -0000 TB --- 2013-07-10 15:29:52 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-10 15:29:52 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-10 15:29:52 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-10 15:29:52 - cleaning the object tree TB --- 2013-07-10 15:30:44 - /usr/local/bin/svn stat /src TB --- 2013-07-10 15:30:57 - At svn revision 253133 TB --- 2013-07-10 15:30:58 - building world TB --- 2013-07-10 15:30:58 - CROSS_BUILD_TESTING=YES TB --- 2013-07-10 15:30:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-10 15:30:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-10 15:30:58 - SRCCONF=/dev/null TB --- 2013-07-10 15:30:58 - TARGET=sparc64 TB --- 2013-07-10 15:30:58 - TARGET_ARCH=sparc64 TB --- 2013-07-10 15:30:58 - TZ=UTC TB --- 2013-07-10 15:30:58 - __MAKE_CONF=/dev/null TB --- 2013-07-10 15:30:58 - cd /src TB --- 2013-07-10 15:30:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jul 10 15:31:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 10 16:40:27 UTC 2013 TB --- 2013-07-10 16:40:27 - generating LINT kernel config TB --- 2013-07-10 16:40:27 - cd /src/sys/sparc64/conf TB --- 2013-07-10 16:40:27 - /usr/bin/make -B LINT TB --- 2013-07-10 16:40:27 - cd /src/sys/sparc64/conf TB --- 2013-07-10 16:40:27 - /usr/sbin/config -m LINT TB --- 2013-07-10 16:40:27 - building LINT kernel TB --- 2013-07-10 16:40:27 - CROSS_BUILD_TESTING=YES TB --- 2013-07-10 16:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-10 16:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-10 16:40:27 - SRCCONF=/dev/null TB --- 2013-07-10 16:40:27 - TARGET=sparc64 TB --- 2013-07-10 16:40:27 - TARGET_ARCH=sparc64 TB --- 2013-07-10 16:40:27 - TZ=UTC TB --- 2013-07-10 16:40:27 - __MAKE_CONF=/dev/null TB --- 2013-07-10 16:40:27 - cd /src TB --- 2013-07-10 16:40:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 10 16:40:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-10 16:51:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-10 16:51:26 - ERROR: failed to build LINT kernel TB --- 2013-07-10 16:51:26 - 3799.99 user 644.03 system 4893.99 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 17:04:20 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2DDED36; Wed, 10 Jul 2013 17:04:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6972D1DE8; Wed, 10 Jul 2013 17:04:20 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6AH4IpI000238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Jul 2013 17:04:18 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_EB9CE248-0AA2-4B95-B0D9-AEB68202583F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: David Chisnall In-Reply-To: <20130710183315.725dfde0@thor.walstatt.dyndns.org> Date: Wed, 10 Jul 2013 18:04:16 +0100 Message-Id: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> To: "O. Hartmann" X-Mailer: Apple Mail (2.1503) Cc: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 17:04:20 -0000 --Apple-Mail=_EB9CE248-0AA2-4B95-B0D9-AEB68202583F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10 Jul 2013, at 17:33, "O. Hartmann" = wrote: > Hi David, >=20 > thanks for the fast response. >=20 > The code I was told to check with is this: >=20 > #include > #include > #include >=20 > int > main(void) > { >=20 > std::cout << typeid(isnan(1.0)).name() << "\n"; >=20 > } >=20 >=20 > If I compile it with=20 >=20 > c++ -o testme -std=3Dc++11 -stdlib=3Dlibc++ source.cc >=20 > and run the binary, the result is "i" which I interpret as "INT". I believe there is a bug, which is that the math.h things are being = exposed but shouldn't be, however it is not the bug that you think it = is. Try this line instead: std::cout << typeid(std::isnan(1.0)).name() << "\n"; We have a libm function, isnan(), and a libc++ function, std::isnan(). = The former is detected if you do not specify a namespace. I am not sure = what will happen if you do: #include #include #include using namespace std; int main(void) { cout << typeid(isnan(1.0)).name() << "\n"; } This is considered bad form, but does happen in some code. I am not = certain what the precedence rules are in this case and so I don't know = what happens. To properly fix this, we'd need to namespace the libm functions when = including math.h in C++. This would also include fixing tweaking the = macros. =20 A fix for your code is to ensure isnan() and isinf() are explicitly = namespaced. Potentially, this may also work: using std::isinf; using std::isnan; David --Apple-Mail=_EB9CE248-0AA2-4B95-B0D9-AEB68202583F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR3ZQRAAoJEKx65DEEsqId2pgQALR81QLfm7K7mE+qxwrS9/dr pcs2iSLUAX6ZnHGyhENAHOWBrpYofWFAtjlOmOcKjs3cPHq5H3dw5CgSEDqke+iB AlNeg1HC5iuIiwzlYGuXBr4cvbZ3oEDv0I+qCUS7T4Puidv5BHik+dcqbpJzgi9b J3k5AMhTYOI834qV7VJkTmZ74U/okJgywy5ebYsBx4OicPg8LTFONwSnGzHhimpC mjki3KlosYX8x9mErxdLBnkoMRuEYcBHO3XnJKK3fesC8eAH9Drr9wWaScHjsW59 OrjQ5sGd/TOMyhZIVmr0rtWRl+X06J3TXA3W+Ama6VuwDeXI5yZM5Udvd+RTxDs8 jMcZROkUOnDUn8LZEkP7X47rUe5WxSmvclhLh4yW1NEa8vnTQ4V4vFFH/Dmr6YNi kz14k6hsdpx3EzAH45AI1povQnkKGocpVyWa+DRdE65PlQCsp4HibjCgp7Q9o3dw 6SqAKw2o01925yCMIBZEdhawOjlhFFijfgbceK+KRusZukl/0D9pWmtRKphkpVF3 tbl/mygYkW4OKCxLvoVUmrXsqMXnjkqcdI7ozrTM6GDDryTkt3vK8Rd0ToEH6b4e U7lCkmo84YhS2BCc3riEiGLqJcNYjv6p4UkLlieVUv0+YrlGHgMKJUovW5ppJhBI WKOZwmL/ntfhB0IpCl6M =pI2H -----END PGP SIGNATURE----- --Apple-Mail=_EB9CE248-0AA2-4B95-B0D9-AEB68202583F-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 17:09:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F99214F for ; Wed, 10 Jul 2013 17:09:36 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) by mx1.freebsd.org (Postfix) with ESMTP id 151AB1E46 for ; Wed, 10 Jul 2013 17:09:35 +0000 (UTC) Received: from localhost ([92.136.146.119]) by mwinf5d16 with ME id yh9T1l00C2anTkU03h9UY9; Wed, 10 Jul 2013 19:09:28 +0200 Message-ID: <51DD9547.6080504@orange.fr> Date: Wed, 10 Jul 2013 19:09:27 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130624 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pedro Giffuni Subject: Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435 References: <51DD5451.2010801@orange.fr> <51DD6777.90803@orange.fr> <51DD782E.7090503@FreeBSD.org> <51DD7AB1.4090202@orange.fr> <51DD8D2B.60509@FreeBSD.org> In-Reply-To: <51DD8D2B.60509@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 17:09:36 -0000 On 07/10/2013 18:34, Pedro Giffuni wrote: > I found a missing type change. Can you try the attached patch? > SUCCESS !! > Cheers, > > Pedro. > Thanks (and apologies to rmacklem !) Claude Buisson From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 18:32:08 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 46FD387B; Wed, 10 Jul 2013 18:32:08 +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 038DD12E3; Wed, 10 Jul 2013 18:32:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UwzBO-001rKc-RC>; Wed, 10 Jul 2013 20:32:06 +0200 Received: from e179143131.adsl.alicedsl.de ([85.179.143.131] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UwzBO-0003BP-MM>; Wed, 10 Jul 2013 20:32:06 +0200 Date: Wed, 10 Jul 2013 20:32:00 +0200 From: "O. Hartmann" To: David Chisnall Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity Message-ID: <20130710203200.5359fd18@thor.walstatt.dyndns.org> In-Reply-To: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/a3Zxzw.Wnu5iEEcQW081qGU"; protocol="application/pgp-signature" X-Originating-IP: 85.179.143.131 Cc: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 18:32:08 -0000 --Sig_/a3Zxzw.Wnu5iEEcQW081qGU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 10 Jul 2013 18:04:16 +0100 David Chisnall wrote: > On 10 Jul 2013, at 17:33, "O. Hartmann" > wrote: >=20 > > Hi David, > >=20 > > thanks for the fast response. > >=20 > > The code I was told to check with is this: > >=20 > > #include > > #include > > #include > >=20 > > int > > main(void) > > { > >=20 > > std::cout << typeid(isnan(1.0)).name() << "\n"; > >=20 > > } > >=20 > >=20 > > If I compile it with=20 > >=20 > > c++ -o testme -std=3Dc++11 -stdlib=3Dlibc++ source.cc > >=20 > > and run the binary, the result is "i" which I interpret as "INT". >=20 > I believe there is a bug, which is that the math.h things are being > exposed but shouldn't be, however it is not the bug that you think it > is. Try this line instead: >=20 > std::cout << typeid(std::isnan(1.0)).name() << "\n"; >=20 > We have a libm function, isnan(), and a libc++ function, > std::isnan(). The former is detected if you do not specify a > namespace. I am not sure what will happen if you do: >=20 > #include > #include > #include > using namespace std; >=20 > int > main(void) > { >=20 > cout << typeid(isnan(1.0)).name() << "\n"; >=20 > } >=20 > This is considered bad form, but does happen in some code. I am not > certain what the precedence rules are in this case and so I don't > know what happens. >=20 > To properly fix this, we'd need to namespace the libm functions when > including math.h in C++. This would also include fixing tweaking the > macros. =20 >=20 > A fix for your code is to ensure isnan() and isinf() are explicitly > namespaced. Potentially, this may also work: >=20 > using std::isinf; > using std::isnan; >=20 > David >=20 I tried in the test code I provided using=20 #include #include #include int main(void) { std::cout << typeid(std::isnan(1.0)).name() << "\n"; } now std::isnan(). The result is the same, it flags "INT". Using=20 #include #include #include using namespace std; int main(void) { std::cout << typeid(std::isnan(1.0)).name() << "\n"; } which is considered "bad coding" also results in "INT" (it gives "i"). So, is this woth a PR? Oliver --Sig_/a3Zxzw.Wnu5iEEcQW081qGU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJR3ailAAoJEOgBcD7A/5N86YsH+wZrHf5AyIHKAXV6iWe3FAvK Zlazcyk6Jy8SPyoel0oLr/Ox8oLYw1i6uy1eAZA63EgS7k5LDVHsEDXctn3PMiDN UML3OsqP+e6Ch9Ohkhelk5HIuhqCum4Pt4YGWTKbbEfVj1v4v6NvXscCmlO1CSKn 256QCaX92DQIaKzrdQCotfdgHoUuzPvSwXdHwAslbTKOVBSBmRz0DCZaJvmSx8zt vTqHSvVBApDEUG1JCI4jN8E46GVjNpa2GzzOSwh16tQWR4Dixdo9uM95+FmlkL9D 8egZuGkEwPqjMuxSYe1qMtpP5MrlN6N0SvZL5MCtJ7Qv790/cCbqLG9XNkmf9po= =AzRw -----END PGP SIGNATURE----- --Sig_/a3Zxzw.Wnu5iEEcQW081qGU-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 19:34:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81C33C09; Wed, 10 Jul 2013 19:34:24 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9471755; Wed, 10 Jul 2013 19:34:24 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r6AJYIIR014432; Wed, 10 Jul 2013 12:34:18 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201307101934.r6AJYIIR014432@chez.mckusick.com> To: Adrian Chadd Subject: Re: Kernel crash during heavy disk access In-reply-to: Date: Wed, 10 Jul 2013 12:34:18 -0700 From: Kirk McKusick X-Mailman-Approved-At: Wed, 10 Jul 2013 20:07:06 +0000 Cc: Benjamin Kaduk , Jeff Roberson , Eric Camachat , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 19:34:24 -0000 > Date: Tue, 9 Jul 2013 18:29:01 -0700 > Subject: Re: Kernel crash during heavy disk access > From: Adrian Chadd > To: Benjamin Kaduk , Jeff Roberson , > Kirk McKusick > Cc: Eric Camachat , current@freebsd.org > > Well, best to tell kirk and jeffr. > > Jeffr wrote the journaling stuff. > > .. but I thought they knew there's still problems? > > -adrian Jeff has fixed all the journaling issues for which we have some way of reproducing them. We do still have some reports that there are "problems" but only a vague description and nothing that we can use to reproduce them on our systems. One of the inherit characteristics of any type of journaling is that once it thinks that it has fixed something, it never goes back and checks it again later. So, if there is some inconsistency that gets into your filesystem through media error or an earlier journaling bug, it will stay there and continue to plague you until a full fsck is run to clean it up. So, if you are getting filesystem related crashes, the first thing you should do is a full (fsck -f) check to make sure that you are starting from a clean state. After that, if you find that the journaling is not keeping it consistent, please send Jeff and me a report of what you are doing, what problems it creates, and most importantly transcript of a run of `fsck_ffs -d' first using the journal and then a second time with a full check (fsck_ffs -f -d) so that we can try to analyse what is going wrong. Note that you need to run fsck_ffs explicitly because the fsck front end will not pass the -d (debug output) flag through to fsck_ffs. Kirk McKusick > On 9 July 2013 17:48, Benjamin Kaduk wrote: >> On Tue, 9 Jul 2013, Adrian Chadd wrote: >> >>> On 9 July 2013 09:24, Eric Camachat wrote: >>>> >>>> On Mon, 2013-07-08 at 23:05 -0700, Adrian Chadd wrote: >>>>> >>>>> Hi, >>>>> >>>>> Try doing a full, non-journal fsck. >>>>> >>>>> -adrian >>>> >>>> >>>> Thank you, it fixed the problem! >>>> Does it mean journal didn't work? >>> >>> >>> Yup :( >> >> >> So, you are going to tell Kirk about it? >> >> -Ben From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 20:13:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 55349B11; Wed, 10 Jul 2013 20:13:15 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6C09E1960; Wed, 10 Jul 2013 20:13:14 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUGADG/3VFR8aPm/2dsb2JhbABagwkywXGBExd0giMBAQVWIxALGAkWDwkDAgECASceBg0BBQIBAYgPuACPYwcJg2wDkA6BLYdIkCGBWIE7Og Received: from 230.163-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.163.230]) by relay.skynet.be with ESMTP; 10 Jul 2013 22:13:06 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id r6AKD53P023353; Wed, 10 Jul 2013 22:13:06 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Message-ID: <51DDC04B.6040209@FreeBSD.org> Date: Wed, 10 Jul 2013 22:12:59 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130701 Thunderbird/17.0.7 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> In-Reply-To: <20130710203200.5359fd18@thor.walstatt.dyndns.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2EQINXAXUJPBVPTPMIQWW" Cc: freebsd-standards@FreeBSD.org, FreeBSD CURRENT , David Chisnall , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 20:13:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EQINXAXUJPBVPTPMIQWW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-10 20:32, O. Hartmann wrote: > On Wed, 10 Jul 2013 18:04:16 +0100 > David Chisnall wrote: >=20 >> On 10 Jul 2013, at 17:33, "O. Hartmann" >> wrote: >> >>> Hi David, >>> >>> thanks for the fast response. >>> >>> The code I was told to check with is this: >>> >>> #include >>> #include >>> #include >>> >>> int >>> main(void) >>> { >>> >>> std::cout << typeid(isnan(1.0)).name() << "\n"; >>> >>> } >>> >>> >>> If I compile it with=20 >>> >>> c++ -o testme -std=3Dc++11 -stdlib=3Dlibc++ source.cc >>> >>> and run the binary, the result is "i" which I interpret as "INT". >> >> I believe there is a bug, which is that the math.h things are being >> exposed but shouldn't be, however it is not the bug that you think it >> is. Try this line instead: >> >> std::cout << typeid(std::isnan(1.0)).name() << "\n"; >> >> We have a libm function, isnan(), and a libc++ function, >> std::isnan(). The former is detected if you do not specify a >> namespace. I am not sure what will happen if you do: >> >> #include >> #include >> #include >> using namespace std; >> >> int >> main(void) >> { >> >> cout << typeid(isnan(1.0)).name() << "\n"; >> >> } >> >> This is considered bad form, but does happen in some code. I am not >> certain what the precedence rules are in this case and so I don't >> know what happens. >> >> To properly fix this, we'd need to namespace the libm functions when >> including math.h in C++. This would also include fixing tweaking the >> macros. =20 >> >> A fix for your code is to ensure isnan() and isinf() are explicitly >> namespaced. Potentially, this may also work: >> >> using std::isinf; >> using std::isnan; >> >> David >> >=20 > I tried in the test code I provided using=20 >=20 >=20 > #include > #include > #include >=20 > int > main(void) > { >=20 > std::cout << typeid(std::isnan(1.0)).name() << "\n"; >=20 > } >=20 > now std::isnan(). >=20 > The result is the same, it flags "INT". >=20 > Using=20 >=20 > #include > #include > #include >=20 > using namespace std; >=20 > int > main(void) > { >=20 > std::cout << typeid(std::isnan(1.0)).name() << "\n"; >=20 > } >=20 > which is considered "bad coding" also results in "INT" (it gives "i"). >=20 > So, is this woth a PR? isnan is overloaded. There's "int isnan(double)" in math.h and "bool isnan(arithmetic)" in cmath. When you call isnan(1.0), isnan(double) is selected. I think isnan(double) and isinf(double) in math.h should only be visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. For C99 and higher there should only be the isnan/isinf macros. CCed standards@. ------enig2EQINXAXUJPBVPTPMIQWW 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.20 (FreeBSD) iF4EAREIAAYFAlHdwFEACgkQfoCS2CCgtisMQwD9FoF5bcEWaWyVmEC5YXZKGLWd BYB0w68AI3sn0TyNdM0A/iFHD46Iybj5t3tc51SM9HPxom1uMg8HgBwj+shZgyt0 =n5uK -----END PGP SIGNATURE----- ------enig2EQINXAXUJPBVPTPMIQWW-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 20:25:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F09D11C3; Wed, 10 Jul 2013 20:25:30 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) by mx1.freebsd.org (Postfix) with ESMTP id C4B6F19FC; Wed, 10 Jul 2013 20:25:30 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r6AKPUra014863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 10 Jul 2013 16:25:30 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.5/8.14.5/Submit) id r6AKPUU6014860; Wed, 10 Jul 2013 16:25:30 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20957.49978.73666.392417@khavrinen.csail.mit.edu> Date: Wed, 10 Jul 2013 16:25:30 -0400 From: Garrett Wollman To: Tijl Coosemans Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity In-Reply-To: <51DDC04B.6040209@FreeBSD.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 10 Jul 2013 16:25:30 -0400 (EDT) Cc: FreeBSD CURRENT , freebsd-standards@freebsd.org, freebsd-toolchain@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 20:25:31 -0000 < said: > I think isnan(double) and isinf(double) in math.h should only be > visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. > For C99 and higher there should only be the isnan/isinf macros. I believe you are correct. POSIX.1-2008 (which is aligned with C99) consistently calls isnan() a "macro", and gives a pseudo-prototype of int isnan(real-floating x); -GAWollman From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 22:40:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 41E26F18; Wed, 10 Jul 2013 22:40:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id EA9321F91; Wed, 10 Jul 2013 22:40:20 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 5so4134756qeb.3 for ; Wed, 10 Jul 2013 15:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oUgBviiZnvPfBRNmSn5BJRP2ptPpVVN+STqSSDxE9lg=; b=iRQGahVssO5Lpdt86iZbcoakltWtAwQ2kIm0KGpMIc309cbUU6tI7dX59yd+WNewXP i/ZinWQNgnv2FKw1kPvfi2OZfXyCG3frlrxSqO7TIlFXWnb3KAH7G5CbgabrhEW/XsrB u39kFdnFX+X+xeTjnI7b/pnTHqRWXmO2gMbcQjEkV0dsNQeT8tV39s8mZpMLFAd6Rqyj lnYeU2bQP4OKi24ZfLqhVD80ydfylZhs4/3yQrzv3nNKcRy9BRV7GwoV7nkN/SjE5Xpa EBeFedpe9IppwBZhMCYftVHERKiKAmTyBaMXF4qnj2WLnjOtD/tN2Z5ImyAi0RTOWpLn Ewfw== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr27253261qeb.6.1373496020493; Wed, 10 Jul 2013 15:40:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Wed, 10 Jul 2013 15:40:20 -0700 (PDT) In-Reply-To: <201307101934.r6AJYIIR014432@chez.mckusick.com> References: <201307101934.r6AJYIIR014432@chez.mckusick.com> Date: Wed, 10 Jul 2013 15:40:20 -0700 X-Google-Sender-Auth: Clqpjuz3P35E8G_QOeR5UuayGu0 Message-ID: Subject: Re: Kernel crash during heavy disk access From: Adrian Chadd To: Kirk McKusick Content-Type: text/plain; charset=ISO-8859-1 Cc: Benjamin Kaduk , Jeff Roberson , Eric Camachat , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 22:40:21 -0000 I still get issues with latest stable/9 and panics during or just after a bunch of disk IO. I can try to reproduce this if you'd like. -adrian From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 23:36:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E904DAAC for ; Wed, 10 Jul 2013 23:36:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id B2D02116F for ; Wed, 10 Jul 2013 23:36:23 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id f11so3888201qae.17 for ; Wed, 10 Jul 2013 16:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=dqEipT5hLdN2gF0Mm3cS3Mfwdkpd18wFP7LgaBLJSgU=; b=CY7OfaV3ik1tW7GECeC+oZhR7h0QIYzMZdQzyVYiKK7YDPUGSolSJAIi5m1HOEAvQ/ L4e/wyoC907nHkjsAX5+RiMuJ9TkuiNDjZVeCEts06omaBhKlzHXab8iPHgJ4tIABzgA TmxxeLTfpkfp/uZ3F0IWmvR3sE2eewDlfNGd9EBaoL6Dm0KeOXsjnqJiubwE8kWIeoC3 ricD+bcTegEdrGQLtsAIJKTGNc5k7ybP725zfXOew0Yb5PmY23Eg5jHnT4OcYEdxVOa0 iUi7z5xDDXHH33u8+H6EiQ3xboTHn6EzfFNK4o8r+kKzoYt3950WqxZNbVU8m1YMYn9q pAiQ== MIME-Version: 1.0 X-Received: by 10.224.26.7 with SMTP id b7mr29988370qac.102.1373499383272; Wed, 10 Jul 2013 16:36:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Wed, 10 Jul 2013 16:36:23 -0700 (PDT) Date: Wed, 10 Jul 2013 16:36:23 -0700 X-Google-Sender-Auth: P3uDhsmF-4Tl9W0BwNv6i8pmabo Message-ID: Subject: hacking - aio_sendfile() From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jul 2013 23:36:24 -0000 Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. I'd like some feedback and possibly some help in stress testing it to make sure it's functioning well. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 04:18:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 710B8244; Thu, 11 Jul 2013 04:18: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 476311F03; Thu, 11 Jul 2013 04:18:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6B4I4j8072893; Thu, 11 Jul 2013 00:18:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6B4I4k8072864; Thu, 11 Jul 2013 04:18:04 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Jul 2013 04:18:04 GMT Message-Id: <201307110418.r6B4I4k8072864@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 04:18:05 -0000 TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-11 02:56:02 - cleaning the object tree TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src TB --- 2013-07-11 02:57:06 - At svn revision 253161 TB --- 2013-07-11 02:57:07 - building world TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 02:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 02:57:07 - SRCCONF=/dev/null TB --- 2013-07-11 02:57:07 - TARGET=sparc64 TB --- 2013-07-11 02:57:07 - TARGET_ARCH=sparc64 TB --- 2013-07-11 02:57:07 - TZ=UTC TB --- 2013-07-11 02:57:07 - __MAKE_CONF=/dev/null TB --- 2013-07-11 02:57:07 - cd /src TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 11 02:57:14 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 11 04:07:01 UTC 2013 TB --- 2013-07-11 04:07:01 - generating LINT kernel config TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT TB --- 2013-07-11 04:07:01 - building LINT kernel TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 04:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 04:07:01 - SRCCONF=/dev/null TB --- 2013-07-11 04:07:01 - TARGET=sparc64 TB --- 2013-07-11 04:07:01 - TARGET_ARCH=sparc64 TB --- 2013-07-11 04:07:01 - TZ=UTC TB --- 2013-07-11 04:07:01 - __MAKE_CONF=/dev/null TB --- 2013-07-11 04:07:01 - cd /src TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-11 04:18:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-11 04:18:04 - ERROR: failed to build LINT kernel TB --- 2013-07-11 04:18:04 - 3801.57 user 646.56 system 4921.87 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 04:21:43 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C63413FF; Thu, 11 Jul 2013 04:21:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 49F871F3E; Thu, 11 Jul 2013 04:21:42 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id A59C2D40A1A; Thu, 11 Jul 2013 14:21:22 +1000 (EST) Date: Thu, 11 Jul 2013 14:21:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Wollman Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity In-Reply-To: <20957.49978.73666.392417@khavrinen.csail.mit.edu> Message-ID: <20130711130043.R920@besplex.bde.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=GSpoo125mhwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mlUDQFikY8EA:10 a=6I5d2MoRAAAA:8 a=dJdWW8WEajGmMdPzLgYA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 X-Mailman-Approved-At: Thu, 11 Jul 2013 04:44:48 +0000 Cc: Tijl Coosemans , FreeBSD CURRENT , freebsd-standards@FreeBSD.org, freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 04:21:43 -0000 On Wed, 10 Jul 2013, Garrett Wollman wrote: > < said: > >> I think isnan(double) and isinf(double) in math.h should only be >> visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. >> For C99 and higher there should only be the isnan/isinf macros. > > I believe you are correct. POSIX.1-2008 (which is aligned with C99) > consistently calls isnan() a "macro", and gives a pseudo-prototype of > > int isnan(real-floating x); Almost any macro may be implemented as a function, if no conforming program can tell the difference. It is impossible for technical reasons to implement isnan() as a macro (except on weird implementations where all real-floating types are physically the same). In the FreeBSD implementation, isnan() is a macro, but it is also a function, and the macro expands to the function in double precision: % #define isnan(x) \ % ((sizeof (x) == sizeof (float)) ? __isnanf(x) \ % : (sizeof (x) == sizeof (double)) ? isnan(x) \ % : __isnanl(x)) I don't see how any conforming program can access the isnan() function directly. It is just as protected as __isnan() would be. (isnan)() gives the function (the function prototype uses this), but conforming programs can't do that since the function might not exist. Maybe some non-conforming program like autoconfig reads or libm.a and creates a bug for C++. The FreeBSD isnan() implementation would be broken by removing the isnan() function from libm.a or ifdefing it in . Changing the function to __isnan() would cause compatibility problems. The function is intentionally named isnan() to reduce compatibility problems. OTOH, the all of the extern sub-functions that are currently used should bever never be used, since using them gives a very low quality of implementation: - the functions are very slow - the functions have names that confuse compilers and thus prevent compilers from replacing them by builtins. Currently, only gcc automatically replaces isnan() by __builtin_isnan(). This only works in double precision. So the FreeBSD implementation only works right in double precision too, only with gcc, __because__ it replaces the macro isnan(x) by the function isnan(x). The result is inline expansion, the same as if the macro isnan() is replaced by __builtin_isnan(). clang never does this automatic replacement, so it generates calls to the slow library functions. Other things go wrong for gcc in other precisions: - if is not included, then isnan(x) gives __builtin_isnan((double)x). This sort of works on x86, but is low quality since it is broken for signaling NaNs (see below). One of the main reasons reason for the existence of the classification macros is that simply converting the arg to a common type and classifying the result doesn't always work. - if is not included, then spelling the API isnanf() or isnanl() gives correct results but a warning about these APIs not being declared. These APIs are nonstandard but are converted to __builtin_isnan[fl] by gcc. - if is included, then: - if the API is spelled isnan(), then the macro converts to __isnanf() or __isnanl(). gcc doesn't understand these, and the slow extern functions are used. - if the API is spelled isnanf() or isnanl(), then the result is correct and the warning magically goes away. declares isnanf(), but gcc apparently declares both iff is included. gcc also optimizes isnanl() on a float arg to __builtin_isnanf(). - no function version can work in some cases, because any function version may have unwanted side effects. This is another of the main reason for the existence of these and other macros. The main unwanted side effect is signaling for signaling NaNs. C99 doesn't really support signaling NaNs, even with the IEC 60559 extensions, so almost anything is allowed for them. But IEEE 854 is fairly clear that isnan() and classification macros shouldn't raise any exceptions. IEEE 854 is even clearer that copying values without changing their representation should (shall?) not cause exceptions. But on i387, just loading a float or double value changes its representation and generates an exception for signaling NaNs, while just loading a long double value conforms to IEEE 854 and doesn't change its representation or generate an exception. Passing of args to functions may or may not load the values. ABIs may require a change of representation. On i387, passing of double args should go through the FPU for efficiency reasons, and this changes the representation twice to not even get back to the original (for signaling NaNs, it generates an exception and sets the quiet bit in the result; thus a classification function can never see a signaling NaN in double precision). So a high quality inplementation must not use function versions, and it must also use builtins that don't even load the values into normal FP registers if this might cause an exception or change the values. Both gcc's and clang's builtins are broken on i387 (i386 or amd64 -m32) since the do load the value. In view of all these bugs, the best available implementation of isnan(x) is ((x) != (x)) (using an unportable statement-expression to avoid multiple evaluation). The known bugs in this implementation are: - it will load the value and thus give unwanted exceptions for signaling NaNs in some cases. But compiler builtins are no better. (IEEE 854 has a lot to say about exceptions for comparison operators, and the builtin comparison operators exist in C99 for related reasons. IIRC, the comparison operators are useless with IEEE 854 conformance, since ordinary comparison operators then do the right thing. The details are unclear, but I couldn't find any cases where gcc or clang on x86 do the wrong thing or do different things for the builtin comparison operators. For ((x) != (x)), they generate an "unordered" comparison and this is the right thing for isnan(). Their builtin isnan()s generate exactly the same code as for ((x) != (x)).) - it may be broken by flags like -ffast-math that turn off IEEE conformance. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 05:38:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5EF56592; Thu, 11 Jul 2013 05:38:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by mx1.freebsd.org (Postfix) with ESMTP id C9AF61130; Thu, 11 Jul 2013 05:38:49 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id j13so6770657wgh.24 for ; Wed, 10 Jul 2013 22:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=/rjXVEQN3PvsreVJO/7puvt1DxY4ZYr83v/IrrQoPVM=; b=UQSnQ3oXIltOQVFl2UfsJbqSi1dzYN4MARiUofXp7E6wO3cPGcUOIu4EUqnXkSvJQ/ sFp2XP8Tb0pb7pFZuWQZHAYOfWQZU8nMj921/7Gc8LzNOpyJ8r2YL5zCIUBIARNG/Cwp M/e/XPCI7Izg5YHq9hcr8fz/JuzP0fPO1DrHCk4N2Q5oOVnMeaJAXJrLjGw3ycadFPqZ pxSELp3w8vJnPQ4DOaDtnBqf56swKfnY2dqYRuxsmU37WUJHDoUWunlKHnG9ShFAv9sR OhvabhcYx3+LGHTtvF73Qu/qI6j/yI0FjHW/JxD2txpNBQP8IEhHIK0SBpc7pZX/5uC8 +GZw== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr20506279wjb.0.1373521127708; Wed, 10 Jul 2013 22:38:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 10 Jul 2013 22:38:47 -0700 (PDT) In-Reply-To: <201307110418.r6B4I4k8072864@freebsd-current.sentex.ca> References: <201307110418.r6B4I4k8072864@freebsd-current.sentex.ca> Date: Wed, 10 Jul 2013 22:38:47 -0700 X-Google-Sender-Auth: YbuXQP3RI6D-NruXa2KQ80j8Q3E Message-ID: Subject: Re: [head tinderbox] failure on sparc64/sparc64 From: Adrian Chadd To: current@freebsd.org, sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 05:38:50 -0000 I don't get why this is dying. any ideas? adrian On 10 July 2013 21:18, FreeBSD Tinderbox wrote: > TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on freebsd-current.se= ntex.ca > TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/spar= c64 > TB --- 2013-07-11 02:56:02 - cleaning the object tree > TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src > TB --- 2013-07-11 02:57:06 - At svn revision 253161 > TB --- 2013-07-11 02:57:07 - building world > TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-07-11 02:57:07 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-07-11 02:57:07 - SRCCONF=3D/dev/null > TB --- 2013-07-11 02:57:07 - TARGET=3Dsparc64 > TB --- 2013-07-11 02:57:07 - TARGET_ARCH=3Dsparc64 > TB --- 2013-07-11 02:57:07 - TZ=3DUTC > TB --- 2013-07-11 02:57:07 - __MAKE_CONF=3D/dev/null > TB --- 2013-07-11 02:57:07 - cd /src > TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Thu Jul 11 02:57:14 UTC 2013 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> World build completed on Thu Jul 11 04:07:01 UTC 2013 > TB --- 2013-07-11 04:07:01 - generating LINT kernel config > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT > TB --- 2013-07-11 04:07:01 - building LINT kernel > TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-07-11 04:07:01 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-07-11 04:07:01 - SRCCONF=3D/dev/null > TB --- 2013-07-11 04:07:01 - TARGET=3Dsparc64 > TB --- 2013-07-11 04:07:01 - TARGET_ARCH=3Dsparc64 > TB --- 2013-07-11 04:07:01 - TZ=3DUTC > TB --- 2013-07-11 04:07:01 - __MAKE_CONF=3D/dev/null > TB --- 2013-07-11 04:07:01 - cd /src > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I= /src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_g= lobal.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D100= --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedany -msoft= -float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee8021= 1_mesh.c > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I= /src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_g= lobal.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D100= --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedany -msoft= -float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee8021= 1_monitor.c > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I= /src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_g= lobal.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D100= --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedany -msoft= -float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee8021= 1_node.c > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I= /src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_g= lobal.h -fno-common -finline-limit=3D15000 --param inline-unit-growth=3D100= --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedany -msoft= -float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee8021= 1_output.c > /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': > /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshc= ntl_ae10' has no member named 'mc_global' > /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshc= ntl_ae10' has no member named 'mc_global' > /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshc= ntl_ae10' has no member named 'mc_global' > *** Error code 1 > > Stop. > make: stopped in /obj/sparc64.sparc64/src/sys/LINT > *** Error code 1 > > Stop. > make: stopped in /src > *** Error code 1 > > Stop in /src. > TB --- 2013-07-11 04:18:04 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-07-11 04:18:04 - ERROR: failed to build LINT kernel > TB --- 2013-07-11 04:18:04 - 3801.57 user 646.56 system 4921.87 real > > > http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.fu= ll > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 06:17:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A980496; Thu, 11 Jul 2013 06:17:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id F20A7130D; Thu, 11 Jul 2013 06:17:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6B6HrPH039484; Thu, 11 Jul 2013 09:17:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6B6HrPH039484 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6B6Hr6x039483; Thu, 11 Jul 2013 09:17:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Jul 2013 09:17:53 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: hacking - aio_sendfile() Message-ID: <20130711061753.GK91021@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wMW4snQFzBrk6QzR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 06:17:58 -0000 --wMW4snQFzBrk6QzR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: > Hiya, >=20 > I've started writing an aio_sendfile() syscall. >=20 > http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff >=20 > Yes, the diff is against -HEAD and not stable/9. >=20 > It's totally horrible, hackish and likely bad. I've only done some > very, very basic testing to ensure it actually works; i haven't at all > stress tested it out yet. It's also very naive - I'm not at all doing > any checks to see whether I can short-cut to do the aio there and > then; I'm always queuing the sendfile() op through the worker threads. > That's likely stupid and inefficient in a lot of cases, but it at > least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. Your implementation easily causes exhaustion of the aio thread pool, blocking the whole aio subsystem. It is known that our aio does not work for sockets for the same reason. I object against adding more code with the same defect. Proper route seems to rewrite aio for sockets using the upcalls. The same should be done for sendfile, if sendfile is given aio flavor. >=20 > I'd like some feedback and possibly some help in stress testing it to > make sure it's functioning well. >=20 > Thanks, >=20 >=20 > -adrian > _______________________________________________ > 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" --wMW4snQFzBrk6QzR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3k4RAAoJEJDCuSvBvK1B+eUP+QFLTmvVepk5pm4zBtz0D0T3 FduAgbi4cUknborLn/ATcn09TuxeBCxxj224nOlnUYqi7Es7AXvYcs3UG3Y9jbZ8 Y+vhDvdGGW8o3Kb7h6bv0EnZVvOkFXx9A6+gVi4y9icGA8WP2mqHNhQynJHIjJbn Ej2Ud0jPE4dyJeosMoHwGR40l+ESQ9Jb+ObBehNspyJBo6kY3aWXg6Rq6v2qdIwT ZHv5e8ALO84CvxgUtFKZ0x+c50+qcks9R+ZZvBgqG3PS4RvEt0SKNy3aAi6bT5Y5 uBHYf0iWsTg4Bt7MJCLef0fb/Dw3FwkZfsK57h4w8HGwQpik9j8HpeZnVFH49x4h 5CvHECbRTdahnhs/iAv3c9HM2jVh5R9hmlGF46vET+wseIbObZByX/Fr8Va1ULly 79oxHc7BH+t5Hqu9xgyn3MCRnAf3455k3FDGSB9T7cJVeLv/yqpuPwRwvo/VhIaJ O4AP9nXO+z2Jp+6ZhCxRv7mpZ4X/GNtvM5botA5khkUfxJdTdJY8W+bFUqUyiNDN iVZvXcU5mHYIiQnkEQNLFYJRLpuO3BSJWBX+vXJWQUJcQSx8Ppf4U62wRw60/9R8 bEdhH5MFhHe1nArUdMoslBirnXVR0czxbCJgeSOu4boue6ayCI+055lxiJZlGyn5 HzvcvH4c/c54bAAXnat7 =TocX -----END PGP SIGNATURE----- --wMW4snQFzBrk6QzR-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 07:05:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9BA772C1; Thu, 11 Jul 2013 07:05:50 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1CF1665; Thu, 11 Jul 2013 07:05:50 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id 10so7167102pdc.5 for ; Thu, 11 Jul 2013 00:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FKsf+ZA31JWpntc04levwe/7O6w8BgV8m7NIuVmrR5Y=; b=MOy69P6tKXK9OSqrz0XXVVAdWWTzn601IYCgAYTIpxZui876o2vtpWbUVt+jLHpGVM t3uxRazi2hBNS9+5kiBMxrbrVW1C98vBHwKeaOBTLOEIhP4vxMsWMVOTOo0bJ4rlI4Q+ lJYbtnMFBr0C/6MmJ6hOqz804NXhuIb2b/Ks2R+5gtc6vf/25jiGwy813NvtbcUZxy0+ VFKx0oRDCU5429CBk69dB6TdkLi/qX+JJn4WcGtTyVaz1Kb19R663pGhl7IFmyyaNGyA IeEEMoIvoerqcncjXXNLIU3jUhqEFL4jts+Sv2ro5ATTcqamidL+ImOodDtC3B+t8aTD 0Uag== X-Received: by 10.68.69.108 with SMTP id d12mr34574604pbu.187.1373526349544; Thu, 11 Jul 2013 00:05:49 -0700 (PDT) Received: from itx (c-24-6-45-85.hsd1.ca.comcast.net. [24.6.45.85]) by mx.google.com with ESMTPSA id cx3sm38056902pbb.30.2013.07.11.00.05.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 11 Jul 2013 00:05:48 -0700 (PDT) Date: Thu, 11 Jul 2013 00:05:41 -0700 From: Navdeep Parhar To: Adrian Chadd Subject: Re: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20130711070541.GA21264@itx> Mail-Followup-To: Adrian Chadd , current@freebsd.org, sparc64@freebsd.org References: <201307110418.r6B4I4k8072864@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org, sparc64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 07:05:50 -0000 On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: > I don't get why this is dying. any ideas? Maybe because sparc64's ucontext.h is getting pulled in, and it has this: #define mc_flags mc_global[0] Regards, Navdeep > > > > adrian > > On 10 July 2013 21:18, FreeBSD Tinderbox wrote: > > TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on freebsd-current.sentex.ca > > TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > > TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/sparc64 > > TB --- 2013-07-11 02:56:02 - cleaning the object tree > > TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src > > TB --- 2013-07-11 02:57:06 - At svn revision 253161 > > TB --- 2013-07-11 02:57:07 - building world > > TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=YES > > TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=/obj > > TB --- 2013-07-11 02:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2013-07-11 02:57:07 - SRCCONF=/dev/null > > TB --- 2013-07-11 02:57:07 - TARGET=sparc64 > > TB --- 2013-07-11 02:57:07 - TARGET_ARCH=sparc64 > > TB --- 2013-07-11 02:57:07 - TZ=UTC > > TB --- 2013-07-11 02:57:07 - __MAKE_CONF=/dev/null > > TB --- 2013-07-11 02:57:07 - cd /src > > TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld > >>>> Building an up-to-date make(1) > >>>> World build started on Thu Jul 11 02:57:14 UTC 2013 > >>>> Rebuilding the temporary build tree > >>>> stage 1.1: legacy release compatibility shims > >>>> stage 1.2: bootstrap tools > >>>> stage 2.1: cleaning up the object tree > >>>> stage 2.2: rebuilding the object tree > >>>> stage 2.3: build tools > >>>> stage 3: cross tools > >>>> stage 4.1: building includes > >>>> stage 4.2: building libraries > >>>> stage 4.3: make dependencies > >>>> stage 4.4: building everything > >>>> World build completed on Thu Jul 11 04:07:01 UTC 2013 > > TB --- 2013-07-11 04:07:01 - generating LINT kernel config > > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT > > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > > TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT > > TB --- 2013-07-11 04:07:01 - building LINT kernel > > TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=YES > > TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=/obj > > TB --- 2013-07-11 04:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2013-07-11 04:07:01 - SRCCONF=/dev/null > > TB --- 2013-07-11 04:07:01 - TARGET=sparc64 > > TB --- 2013-07-11 04:07:01 - TARGET_ARCH=sparc64 > > TB --- 2013-07-11 04:07:01 - TZ=UTC > > TB --- 2013-07-11 04:07:01 - __MAKE_CONF=/dev/null > > TB --- 2013-07-11 04:07:01 - cd /src > > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>>> Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 > >>>> stage 1: configuring the kernel > >>>> stage 2.1: cleaning up the object tree > >>>> stage 2.2: rebuilding the object tree > >>>> stage 2.3: build tools > >>>> stage 3.1: making dependencies > >>>> stage 3.2: building everything > > [...] > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c > > /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': > > /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' > > /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' > > /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' > > *** Error code 1 > > > > Stop. > > make: stopped in /obj/sparc64.sparc64/src/sys/LINT > > *** Error code 1 > > > > Stop. > > make: stopped in /src > > *** Error code 1 > > > > Stop in /src. > > TB --- 2013-07-11 04:18:04 - WARNING: /usr/bin/make returned exit code 1 > > TB --- 2013-07-11 04:18:04 - ERROR: failed to build LINT kernel > > TB --- 2013-07-11 04:18:04 - 3801.57 user 646.56 system 4921.87 real > > > > > > http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full > > _______________________________________________ > > freebsd-sparc64@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 07:07:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BCB5249B; Thu, 11 Jul 2013 07:07:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 0B832169B; Thu, 11 Jul 2013 07:07:34 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id z11so6760155wgg.22 for ; Thu, 11 Jul 2013 00:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=eE7zMR4lqvLhE2WvpW6Sc5vEop+l8XlZsWy9TwJfvSg=; b=rvaHF6We8snNkUHW7hRHU5I9LxEf2Cz3Yc9bUcBk4StBlhxC7tjzU4HdaOsSq7KQ+0 weo5qHPHY8PcW0qjzWZUWvSASsCJieAUUn5ZIKZe09n1NFw4ZBu7nU7GZi7oh3n9NGU3 8qyQShNJ0gpQhI2RnlVQL3xsHS4X1it9k+Ea4Tdrl7Sb6ewZk5c9wEiWZajVbb7wB3+C ef/4XkRDlV4PklVedm6o0WN/kH5IBMP7Tccarvcmbfs15Yzh4EA8Jt79xnWhQaANnDQZ zD/cIQdXxP9eTHozo7OK6Ipq/nLlwXpPxbAgCZWotVAu+CG3nlgreIQvecotFchauz7K 1XgA== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr20676840wjb.0.1373526454030; Thu, 11 Jul 2013 00:07:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 11 Jul 2013 00:07:33 -0700 (PDT) In-Reply-To: <20130711070541.GA21264@itx> References: <201307110418.r6B4I4k8072864@freebsd-current.sentex.ca> <20130711070541.GA21264@itx> Date: Thu, 11 Jul 2013 00:07:33 -0700 X-Google-Sender-Auth: Y5geByi29EzRhdjQs5bCMkwLJ7c Message-ID: Subject: Re: [head tinderbox] failure on sparc64/sparc64 From: Adrian Chadd To: Adrian Chadd , current@freebsd.org, sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 07:07:35 -0000 On 11 July 2013 00:05, Navdeep Parhar wrote: > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: >> I don't get why this is dying. any ideas? > > Maybe because sparc64's ucontext.h is getting pulled in, and it has > this: > > #define mc_flags mc_global[0] Ugh, we should fix this. When did this happen? -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 07:08:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D8365F6; Thu, 11 Jul 2013 07:08:54 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 0E8E616C0; Thu, 11 Jul 2013 07:08:54 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id 10so7112861pdi.39 for ; Thu, 11 Jul 2013 00:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ATRbPk2+5Sk+PvPdpz6cJCjoc49AonQUhBJrLtDCbj4=; b=Ipqsde6CWt1uXN3rrAtLdwy8dnc4pKsWL9CW5Lhm31keqA1MT4nm9NcsiqefngFyYB DR+kfN4f5h6Vwi6TxQldnQJAXJ3qtHQ1e34S+hf1F99HVYyaSo2LK6TQ0KiZi7OEUcx7 WM8CQCxfZfLB/jOMI7t1GyH+5hMuj4HxMJUbztm1DszwLmMoJ/bb/ymr+GU4MmlAy2GE YUdTgBZlJgoX3SWJiawiCBcNEPEci282wv5ZHgG4Efrqj+RAGpVof+ldu4fXJ7YUWXq5 uZZQhuDRvVr9K7z04QmXsEXokrJ+TqP/AtZKswkHpMwGlHcQ2PqhBqw5JH87HAq01chv 6aPw== X-Received: by 10.66.246.133 with SMTP id xw5mr33780747pac.114.1373526533847; Thu, 11 Jul 2013 00:08:53 -0700 (PDT) Received: from itx (c-24-6-45-85.hsd1.ca.comcast.net. [24.6.45.85]) by mx.google.com with ESMTPSA id sq5sm40489101pab.11.2013.07.11.00.08.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 11 Jul 2013 00:08:52 -0700 (PDT) Date: Thu, 11 Jul 2013 00:08:46 -0700 From: Navdeep Parhar To: Adrian Chadd Subject: Re: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20130711070846.GA21279@itx> Mail-Followup-To: Adrian Chadd , current@freebsd.org, sparc64@freebsd.org References: <201307110418.r6B4I4k8072864@freebsd-current.sentex.ca> <20130711070541.GA21264@itx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org, sparc64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 07:08:54 -0000 On Thu, Jul 11, 2013 at 12:07:33AM -0700, Adrian Chadd wrote: > On 11 July 2013 00:05, Navdeep Parhar wrote: > > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: > >> I don't get why this is dying. any ideas? > > > > Maybe because sparc64's ucontext.h is getting pulled in, and it has > > this: > > > > #define mc_flags mc_global[0] > > Ugh, we should fix this. When did this happen? You tell me. I was just running cscope in my spare time ;-) From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 08:15:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34609B77; Thu, 11 Jul 2013 08:15:48 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mx1.freebsd.org (Postfix) with ESMTP id E14A119DB; Thu, 11 Jul 2013 08:15:47 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id E105813E3; Thu, 11 Jul 2013 10:15:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (scan.wasikowski.net [IPv6:2001:6a0:1cb::b]) (amavisd-new, port 10026) with ESMTP id PV2iGYNjasY2; Thu, 11 Jul 2013 10:15:38 +0200 (CEST) Received: from [192.168.138.150] (83-144-115-210.static.chello.pl [83.144.115.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.wasikowski.net (Postfix) with ESMTPSA id 7F61713DF; Thu, 11 Jul 2013 10:15:38 +0200 (CEST) Message-ID: <51DE69AA.7060003@wasikowski.net> Date: Thu, 11 Jul 2013 10:15:38 +0200 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <50D1C553.9060100@wasikowski.net> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "freebsd-stable@freebsd.org Stable" , Michael Grimm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 08:15:48 -0000 W dniu 2013-07-10 17:52, Kevin Oberman pisze: > On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > >> On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < >> trashcan@odo.in-berlin.de> wrote: >> >> Will that patch make it into 9.2? If I am not mistaken, that patch isn't >>> in stable yet. >>> >> >> I would also like to see this patch hit 9.x sooner than later. It's so >> painful when someone forgets to fix the alias numbering on servers with >> many, many IPv4 and IPv6 addresses... >> > > Please, please, please, please, ...! > > Freeze is only two days away, so time for 9.2 is almost over and I can see > no good reason NOT to get this done. +1 to that, please commit it. -- best regards, Lukasz Wasikowski From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 08:36:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A643F4C2 for ; Thu, 11 Jul 2013 08:36:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9871AD0 for ; Thu, 11 Jul 2013 08:36:27 +0000 (UTC) Received: (qmail 87857 invoked from network); 11 Jul 2013 09:27:04 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 09:27:04 -0000 Message-ID: <51DE6E86.6080707@freebsd.org> Date: Thu, 11 Jul 2013 10:36:22 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fabian Keil Subject: Re: Improved SYN Cookies: Looking for testers References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> In-Reply-To: <20130710151821.5a8cf38a@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 08:36:28 -0000 On 10.07.2013 15:18, Fabian Keil wrote: > Andre Oppermann wrote: > >> We have a SYN cookie implementation for quite some time now but it >> has some limitations with current realities for window scaling and >> SACK encoding the in the few available bits. >> >> This patch updates and improves SYN cookies mainly by: >> >> a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN >> (initial sequence number) without the use of timestamp bits. >> >> b) switching to the very fast and cryptographically strong SipHash-2-4 >> hash MAC algorithm to protect the SYN cookie against forgery. >> >> The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). >> >> Please find it here for testing: >> >> http://people.freebsd.org/~andre/syncookie-20130708.diff > > I've been using the patch for a couple of days and didn't notice any > issues so far. Privoxy's regression tests continue to work as expected > as well. Thanks for testing and reporting back. Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1 as well to bypass the syn cache entirely? It will give a bit of debug log output which is it telling you mostly about rounding to the next nearest index value. You can send the output privately to me to spot unexpected outliers, if any. > BTW, I think kern/173309 could be closed. OK. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 08:37:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8DF566B for ; Thu, 11 Jul 2013 08:37:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 45BF91AED for ; Thu, 11 Jul 2013 08:37:20 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w57so6801661wes.15 for ; Thu, 11 Jul 2013 01:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mRwaJHMnUkVy+eXCZ0f5LmS1FzOPxrFBAEaWtRz5dDk=; b=QBbM0gGNWWu19KTVme9P4QA2K9IM+ORQeHzidM0p+cZO7bQlXjjylUpRat6z7O6HG0 Vo192sczx+qzi5jxyLwKF+MUnABJXBY0iqMiKAW5kP7CordnwbjSbJGtzkKFdxJFMO8f Tx7pijHQYkdEcfWY2C9aklE3+R5CLCfXcNsv17+y4Wn8KVkbYHMlJMc52qIJO5cMwi1L izEmF42ZLQ+/ZhsteeTvrJtXIwqpHFjgbJwOcnZsopvTxjxkvMLUNaSyM6yo5RHXmIDp dCv2c+XuLVo1Vz/01tsU8ZPDBihh0YzBtBmVLM19bATvardEtniD1qtHH0aJKuXKHGce sVnQ== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr19555715wij.30.1373531839261; Thu, 11 Jul 2013 01:37:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 11 Jul 2013 01:37:19 -0700 (PDT) In-Reply-To: <20130711061753.GK91021@kib.kiev.ua> References: <20130711061753.GK91021@kib.kiev.ua> Date: Thu, 11 Jul 2013 01:37:19 -0700 X-Google-Sender-Auth: qliHbYyk-RYdp-FWb6vNXB0xcBQ Message-ID: Subject: Re: hacking - aio_sendfile() From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 08:37:20 -0000 Hiya, I'm more interested in the API than the implementation at the moment. Yes, you're right - it should eventually be driven using disk io completion upcalls which triggers the push of data into the socket buffer. I totally agree. I'm hacking up some libevent-ish looking thing that uses kqueue and wraps aio, read, write, and other event types into something I can easily shoehorn this stuff into. I'll then throughly test it (and other options) out. You're right, it's likely going to end up with a whole lot of aio threads sitting there waiting for disk IO to complete - and at that point, I'll start hacking at sendfile() to split it into two halves and have it driven by a completion call from g_up or wherever, triggering the socket write side of things. There are some other questions too - like whether the IO completion should just queue socket IO (and have it potentially block in the TCP code) or whether it should funnel completions into a per-CPU aio completion thread which does the socket write bit. That way disk IO completion isn't going to be blocked by longer-held locks in the networking stack. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 08:47:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C180B31; Thu, 11 Jul 2013 08:47:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id F04E31B5A; Thu, 11 Jul 2013 08:47:48 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6B8kLGo001311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Jul 2013 08:46:23 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: David Chisnall In-Reply-To: <20130711130043.R920@besplex.bde.org> Date: Thu, 11 Jul 2013 09:46:17 +0100 Message-Id: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1503) Cc: Garrett Wollman , Tijl Coosemans , FreeBSD CURRENT , freebsd-standards@FreeBSD.org, freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 08:47:49 -0000 --Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bruce, You're joining in this discussion starting in the middle, so you = probably missed the earlier explanation. On 11 Jul 2013, at 05:21, Bruce Evans wrote: > I don't see how any conforming program can access the isnan() function > directly. It is just as protected as __isnan() would be. (isnan)() > gives the function (the function prototype uses this), but conforming > programs can't do that since the function might not exist. Maybe some > non-conforming program like autoconfig reads or libm.a and > creates a bug for C++. The cmath header defines a template function isnan that invokes the = isnan macro, but then undefines the isnan macro. This causes a problem = because when someone does something along the lines of using namespace = std then they end up with two functions called isnan and the compiler = gets to pick the one to use. Unfortunately, std::isnan() returns a = bool, whereas isnan() returns an int. =20 The C++ headers are not required to be conforming C code, because they = are not C, and our math.h causes namespace pollution in C++ when = included from . > The FreeBSD isnan() implementation would be broken by removing the > isnan() function from libm.a or ifdefing it in . Changing the > function to __isnan() would cause compatibility problems. The = function > is intentionally named isnan() to reduce compatibility problems. On OS X this is avoided because their isnan() macro expands to call one = of the __-prefixed inline functions (which adopt your suggestion of = being implemented as x !=3D x, for all types). I am not sure that this = is required for standards conformance, but it is certainly cleaner. = Your statement that having the function not called isnan() causes = compatibility problems is demonstrably false, as neither OS X nor glibc = has a function called isnan() and, unlike us, they do not experience = problems with this macro. =20 It would also be nice to implement these macros using _Generic when = compiling in C11 mode, as it will allow the compiler to produce more = helpful warning messages. I would propose this implementation: #if __has_builtin(__builtin_isnan) #define isnan(x) __builtin_isnan(x) #else static __inline int __isnanf(float __x) { return (__x !=3D __x); } static __inline int __isnand(double __x) { return (__x !=3D __x); } static __inline int __isnanl(long double __x) { return (__x !=3D __x); } #if __STDC_VERSION__ >=3D 201112L #define isnan(x) _Generic((x), \ float: __isnanf(x), \ double: __isnand(x), \ long double: __isnanl(x)) #else #define isnan(x) \ ((sizeof (x) =3D=3D sizeof (float)) ? __isnanf(x) \ : (sizeof (x) =3D=3D sizeof (double)) ? __isnand(x) \ : __isnanl(x)) #endif #endif For a trivial example of why this is an improvement in terms of error = reporting, consider this trivial piece of code: int is(int x) { return isnan(x); } With our current implementation, this compiles and links without any = warnings, although it will have somewhat interesting results at run = time. With the __builtin_isnan() version, clang reports this error: isnan.c:35:15: error: floating point classification requires argument of floating point type (passed in 'int') return isnan(x); ^ (and then some more about the macro expansion) With the C11 version, it reports this error: isnan.c:35:15: error: controlling expression type 'int' not compatible = with any generic association type return isnan(x); ^ David --Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR3nDZAAoJEKx65DEEsqIdT0UP/R3/DJeYYumScK0sTI0u0f/K zr03X2Nn8rHa4xk8avxANTaYYK8QfutKvViv11G1JH/gTGMNh8LxxdoRhsVx4bOe rAjYY+NDplfLqKTBva+zf25FiQNOn08NnOZDd9l0ApyAK1u2J2dp7Q9yqZbRU7Kj bACBptR3dREJzSZgIbQcJ5WE3BDsBztW0Az3/WcyDtmILmZ8psVLs+R39qe4yjeV NxNQRDJuJmccxi8Jx6sjQaUrXVLZ4VWc0Cbr7+0SasHY1avtqoHr6H5pt3ltUtfF Ld0wQHG8MUuuqZd9j1tQDHSKWmjeDQdOwu8IjEbGP/IXjJI/lK93+K07qMgQPp5G DJzPoSxJEKTVudNVBuv8sA6iToWMli9ZI/h4YL0Lc0G5vOwLbPHcX1ctEb+g118z 676x26Xdr/vawe0rddCUW2z+CVHj7q1eKY37Za9xVlmchUYWMMzqE8m9MdlQGvmi y60IDPDcwCiIoZZQ2VbE+wqrgWevEi0nASFttrgqrS7HEBy/rszm8Cdy1wZqUKSe xi2CwevaMWSfTc9MIwGId5y89UjQ5bSzAPBFWonFZkd/KDN6rRQ1LZvyVrMuZMlX q/6/2ksNXFHzonOw66/913m+JjYYEaSjmndL0w30qN5HKdNw8C6d+Y9EMrQRMK1A cjNdMjwrwk2pdBNsVo1d =FIry -----END PGP SIGNATURE----- --Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 09:36:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0A5F3C78; Thu, 11 Jul 2013 09:36:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 75DE01DD7; Thu, 11 Jul 2013 09:36:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6B9aUQO080417; Thu, 11 Jul 2013 12:36:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6B9aUQO080417 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6B9aUEw080416; Thu, 11 Jul 2013 12:36:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Jul 2013 12:36:30 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: hacking - aio_sendfile() Message-ID: <20130711093630.GL91021@kib.kiev.ua> References: <20130711061753.GK91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4oFiy8uZhEhZB7V2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 09:36:42 -0000 --4oFiy8uZhEhZB7V2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 11, 2013 at 01:37:19AM -0700, Adrian Chadd wrote: > Hiya, >=20 > I'm more interested in the API than the implementation at the moment. >=20 > Yes, you're right - it should eventually be driven using disk io > completion upcalls which triggers the push of data into the socket > buffer. I totally agree. >=20 > I'm hacking up some libevent-ish looking thing that uses kqueue and > wraps aio, read, write, and other event types into something I can > easily shoehorn this stuff into. I'll then throughly test it (and > other options) out. You're right, it's likely going to end up with a > whole lot of aio threads sitting there waiting for disk IO to complete > - and at that point, I'll start hacking at sendfile() to split it into > two halves and have it driven by a completion call from g_up or > wherever, triggering the socket write side of things. >=20 > There are some other questions too - like whether the IO completion > should just queue socket IO (and have it potentially block in the TCP > code) or whether it should funnel completions into a per-CPU aio > completion thread which does the socket write bit. That way disk IO > completion isn't going to be blocked by longer-held locks in the > networking stack. No, it is not disk I/O which is problematic there. It is socket I/O e.g. wait for the socket buffers lomark in the kern_sendfile() which causes unbounded sleep. Look for the sbwait() call, both in the kern_sendfile() itself, and in the pru_send methods of the protocols, e.g. in sosend_generic(). The wait scope controlled by the other side of connection and allow it to completely block the aio subsystem. Disk I/O is supposed to finish in the finite time. --4oFiy8uZhEhZB7V2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3nydAAoJEJDCuSvBvK1B4GkP/32Hyjeqm6RYGgcKW1fBYuaA mo0Eh2zwkYxAr+c3NPj0Tcd/c06cc+bwjbTbtlL1uiyNZNvK1Hb8LnlatfxkubGs 9TZ+T1NzyPJae4uPGMZMcegOVJoeDh9liAcbkTGj6gwoMklAbTGwVYQc9Xs1FhiY hP/D8/ITrnRiltFi7OwAtpqJGjRvz34iSl9viroZcv9+K8uGNobCXuiE2J35eh/p a2F13Lt6kiPSlynkaL6xwabchTgtsAOjNNvtFAeR5D4125nWGijFU9cpU/iFobpH 3BZZ6WbgMTNhxXEqjEbtTKx8YyUEjrRE+p0MoJ2RpgjKXtnhxTtneLyjHiC2Xmam Uk/1IdIhyUnexqBFcN/wGAq36Bd95/+VpwzrIDeWM3E8UoMrtn6oLnV5lbC+oFRA J6FceZIuk6d7RYFLo5tQGzZ+Nuwi95VpO6gT8hCfWxbGVJ3WX72aWlq5qC2tmIT5 TyCDLYAFmFE6sna3xgwLVwnUlGdyV10kSWJLY3VITv3oFn9H9I335+sQBdujpcd+ HflR111vRUabZ3H0FJ7c0wO+jNBPhxYw97K7ckqZsN9ww+vaHPPObImi/oEGVafL W0PYcMFZ1mMfh4xq5GPjrAwz2o4uVe0ub3opadWfx/s2DvYhr82uMgZRtDLlF+s8 BczIcfB67jsn8SxETBRW =xjg4 -----END PGP SIGNATURE----- --4oFiy8uZhEhZB7V2-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 09:37:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45BAED9C; Thu, 11 Jul 2013 09:37:36 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3411DF2; Thu, 11 Jul 2013 09:37:35 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4GAGZ73lFR8aPm/2dsb2JhbABagwnCT4EGF3SCIwEBBAFWIwULCw4KCSUPAigeBg0BBQIBAYgFCrccj2EHg3UDkA6BLZdpgViBOzo Received: from 230.163-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.163.230]) by relay.skynet.be with ESMTP; 11 Jul 2013 11:37:26 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id r6B9bP9C007983; Thu, 11 Jul 2013 11:37:25 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Message-ID: <51DE7CD0.60306@FreeBSD.org> Date: Thu, 11 Jul 2013 11:37:20 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130701 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bruce Evans Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> In-Reply-To: <20130711130043.R920@besplex.bde.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2EUTOIBMOAOLMNPWCAKBE" Cc: Garrett Wollman , FreeBSD CURRENT , freebsd-standards@FreeBSD.org, freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 09:37:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EUTOIBMOAOLMNPWCAKBE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-11 06:21, Bruce Evans wrote: > On Wed, 10 Jul 2013, Garrett Wollman wrote: >> < said: >>> I think isnan(double) and isinf(double) in math.h should only be >>> visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. >>> For C99 and higher there should only be the isnan/isinf macros. >> >> I believe you are correct. POSIX.1-2008 (which is aligned with C99) >> consistently calls isnan() a "macro", and gives a pseudo-prototype of >> >> int isnan(real-floating x); >=20 > Almost any macro may be implemented as a function, if no conforming > program can tell the difference. It is impossible for technical reason= s > to implement isnan() as a macro (except on weird implementations where > all real-floating types are physically the same). In the FreeBSD > implementation, isnan() is a macro, but it is also a function, and > the macro expands to the function in double precision: >=20 > % #define isnan(x) \ > % ((sizeof (x) =3D=3D sizeof (float)) ? __isnanf(x) \ > % : (sizeof (x) =3D=3D sizeof (double)) ? isnan(x) \ > % : __isnanl(x)) The C99 standard says isnan is a macro. I would say that only means defined(isnan) is true. Whether that macro then expands to function calls or not is not important. > I don't see how any conforming program can access the isnan() function > directly. It is just as protected as __isnan() would be. (isnan)() > gives the function (the function prototype uses this), but conforming > programs can't do that since the function might not exist. I don't think the standard allows a function to be declared with the same= name as a standard macro (it does allow the reverse: define a macro with the same name as a standard function). I believe the following code is C99 conforming but it currently does not compile with our math.h: ------ #include =20 int (isnan)(int a, int b, int c) { return (a + b + c); } ------ ------enig2EUTOIBMOAOLMNPWCAKBE 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.20 (FreeBSD) iF4EAREIAAYFAlHefNQACgkQfoCS2CCgtisTnwD7BfDDEcW43Z/knFNt/gk133gK oHU9NLmi8d4J9J5MIlQA/jpqMQEQHsree+HBmQmG+RWL1sBDXxit5pXk28CVamlC =faze -----END PGP SIGNATURE----- ------enig2EUTOIBMOAOLMNPWCAKBE-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 09:39:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 777EEF03 for ; Thu, 11 Jul 2013 09:39:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 132681E0B for ; Thu, 11 Jul 2013 09:39:00 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id w56so6746499wes.39 for ; Thu, 11 Jul 2013 02:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3sk6ECivSwmOz1fQyfjx1+QVZfP1SNtkzI6z+NxXLEY=; b=RHBAyeGwbKhO76WiDGLzFjKX44bzAH+02aOWqHUj9Lg2lkXG3aaAXtRWUDxNvhPykW MB9JOgMmn06RYpzFKcqOQjDaHPipEhv6yg7TrenOayTvKFN0ikjYVCyI9ira5rAa4GWK T3i0DdMh0p8kEBMPExNC6i7d3vZDLQnwv7OoMzMSYhrSzIvC6n0H6Pi2igmd2Dn1I2xx GiQpvAFk1V03eUV9nwYAuV8OsPtkGh5ssrZCwhSQ1pSiPACqHwVS00gkYpkaoJM026fR f2dYuz17uOaCy3CvbLZwhOIbgT9fYb3sTewEhsNIZx67wNlUlGBH3BGmSuO9zFQEo1ij 78QA== MIME-Version: 1.0 X-Received: by 10.180.82.196 with SMTP id k4mr21967188wiy.0.1373535540168; Thu, 11 Jul 2013 02:39:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 11 Jul 2013 02:39:00 -0700 (PDT) In-Reply-To: <20130711093630.GL91021@kib.kiev.ua> References: <20130711061753.GK91021@kib.kiev.ua> <20130711093630.GL91021@kib.kiev.ua> Date: Thu, 11 Jul 2013 02:39:00 -0700 X-Google-Sender-Auth: dHf6hPnV7p0GzH6RAzHmxrY4XyI Message-ID: Subject: Re: hacking - aio_sendfile() From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 09:39:01 -0000 On 11 July 2013 02:36, Konstantin Belousov wrote: > No, it is not disk I/O which is problematic there. It is socket I/O > e.g. wait for the socket buffers lomark in the kern_sendfile() which > causes unbounded sleep. Look for the sbwait() call, both in the > kern_sendfile() itself, and in the pru_send methods of the protocols, > e.g. in sosend_generic(). The wait scope controlled by the other side of > connection and allow it to completely block the aio subsystem. > > Disk I/O is supposed to finish in the finite time. Even if the destination socket is marked as NONBLOCK? -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 09:56:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D65212AE; Thu, 11 Jul 2013 09:56:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 661F71EDC; Thu, 11 Jul 2013 09:56:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6B9uFZV084522; Thu, 11 Jul 2013 12:56:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6B9uFZV084522 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6B9uF63084521; Thu, 11 Jul 2013 12:56:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Jul 2013 12:56:15 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: hacking - aio_sendfile() Message-ID: <20130711095615.GM91021@kib.kiev.ua> References: <20130711061753.GK91021@kib.kiev.ua> <20130711093630.GL91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5A5licVS1j+RWz1s" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 09:56:23 -0000 --5A5licVS1j+RWz1s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote: > On 11 July 2013 02:36, Konstantin Belousov wrote: >=20 > > No, it is not disk I/O which is problematic there. It is socket I/O > > e.g. wait for the socket buffers lomark in the kern_sendfile() which > > causes unbounded sleep. Look for the sbwait() call, both in the > > kern_sendfile() itself, and in the pru_send methods of the protocols, > > e.g. in sosend_generic(). The wait scope controlled by the other side of > > connection and allow it to completely block the aio subsystem. > > > > Disk I/O is supposed to finish in the finite time. >=20 > Even if the destination socket is marked as NONBLOCK? You mean, would a sleep for the socket buffer space cause aio thread block is the socket is put in nonblocking mode ? Or something else ? No, it would not block the thread. But I cannot consider the aio_sendfile(2) implementation useful if it requires non-blocking socket. Also, what about other thread changing the socket to blocking mode while sendfile is in flight ? --5A5licVS1j+RWz1s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3oE/AAoJEJDCuSvBvK1BQoAQAKhbJwA4NzJFbCkYUGgnO2CY 0c0NTia6bqUhHNCHhWPDyhHE5J0JpyUQLmARA1mSzLpwzy/g/b62gcm2tyxHt625 iYmbzT1sU0AOuWjLhM7KjWo3ekKkueniQEY78kXbNAYCVt7Fa8XXyz5t4UcDQFBv IR6xqdsaq12Sk/nL7d6S6g/vAkaE2tTr71KxUskhFzi61SRdIpT3sV/Moy/C3UxE +6ZUvpliN90oen2/iudVC6Yao0y4kma/4cFTVznHZ4hB8SlzdxSvH5CHZH3sr8Q8 73f4agB+b2W3SUH/746CTmZBFYXsHDmvZyIqsf1VjG4toJq4dYKiyK9WhQs1tYNE V63pE1OWWi1Aa7k5XpwFff0wDAQwzI245r2+Gi6Axt2Id6+LUTR56jEFjggH/3z2 go2aBf8FJVBAfi6TUldhusKLynpMV0cwU3Xp427mnAF5dw5w4yOlSCTo/TIarreH RQFJn5arECjb1IFfZzXZx4wXPTSH/UbEdaa2W2NYsPfFPg6SKRIP9nG3uriMOaOP MONvakr95uVmc4j2ElJ9rCg4apNp/eFEucwB1gVLcXPFiUn/APUDMpaxxDAJuTWG cCwCzpx/MaLGW5vvp5C2vZ5lWE53y5a7Ew2ozM/Q70U/2meB6mmj67X7k4XB0BgN bgXXLx2/4txXNW4E6Ott =d5Be -----END PGP SIGNATURE----- --5A5licVS1j+RWz1s-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 10:17:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05554751; Thu, 11 Jul 2013 10:17:29 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 827351FDE; Thu, 11 Jul 2013 10:17:27 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r6BAHKt7007658; Thu, 11 Jul 2013 14:17:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r6BAHKVX007657; Thu, 11 Jul 2013 14:17:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 11 Jul 2013 14:17:20 +0400 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: hacking - aio_sendfile() Message-ID: <20130711101720.GZ67810@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 10:17:29 -0000 Adrian, On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: A> I've started writing an aio_sendfile() syscall. A> A> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff A> A> Yes, the diff is against -HEAD and not stable/9. A> A> It's totally horrible, hackish and likely bad. I've only done some A> very, very basic testing to ensure it actually works; i haven't at all A> stress tested it out yet. It's also very naive - I'm not at all doing A> any checks to see whether I can short-cut to do the aio there and A> then; I'm always queuing the sendfile() op through the worker threads. A> That's likely stupid and inefficient in a lot of cases, but it at A> least gets the syscall up and working. A> A> I'd like some feedback and possibly some help in stress testing it to A> make sure it's functioning well. Apart from problem pointed out by Kostik, there is a race between aio thread starting with aio_process_sendfile() and file descriptor (or socket descriptor) going away. Thus, kern_sendfile() needs to be split into two parts: kern_sendfile_pre() and kern_sendfile() that should contain only the sending cycle. The kern_sendfile_pre() should contain: fgetvp_read(uap->fd, &vp) vm_object_reference_locked(vp->v_object) Referencing the socket is probably also required. Current synchronous code doesn't do it. The do_sendfile() function should call kern_sendfile_pre() and then kern_sendfile(). The aio code should perform kern_sendfile_pre() in the new syscall itself in context of calling process, and kern_sendfile() in async context. P.S. Some time ago I have started hacking on the above. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 10:54:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CC3CFCEF; Thu, 11 Jul 2013 10:54:48 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 692481145; Thu, 11 Jul 2013 10:54:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id 35A2E2B432B6; Thu, 11 Jul 2013 12:54:38 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHc9e1CXyTOt; Thu, 11 Jul 2013 12:54:37 +0200 (SAST) Received: from clue.co.za (41-135-71-48.dsl.mweb.co.za [41.135.71.48]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 746642B43276; Thu, 11 Jul 2013 12:54:37 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UxEWB-0000il-21; Thu, 11 Jul 2013 12:54:35 +0200 To: John Baldwin From: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 In-Reply-To: <201307091202.24493.jhb@freebsd.org> References: <201307091202.24493.jhb@freebsd.org> <20130704082113.GJ91021@kib.kiev.ua> X-Attribution: BOFH Date: Thu, 11 Jul 2013 12:54:35 +0200 Message-Id: Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 10:54:48 -0000 John Baldwin wrote: > On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: > > Konstantin Belousov wrote: > > > > > > Care to provide any useful information ? > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- > handbook/kerneldebug-deadlocks.html > > > > Well, the system doesn't deadlock it's perfectly useable so long > > as you don't touch the file that's wedged. A lot of the time the > > userland process is unkillable, but often it is killable. How do > > I get from from the PID to where the FS is stuck in the kernel? > > Use kgdb. 'proc ', then 'bt'. So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. (kgdb) proc 5176 only supported for core file target In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 09:52:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9EC5C248 for ; Thu, 11 Jul 2013 09:52:18 +0000 (UTC) (envelope-from jackson@donadel.com.br) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id 275481EBA for ; Thu, 11 Jul 2013 09:52:17 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id t13so6563463lbd.1 for ; Thu, 11 Jul 2013 02:52:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=/K0OMSSdq6xa8DcQlMT9MGSHYhBUc2KoOdyV3/syR8s=; b=oryWtnDXEUQ4PSxfWSj7Ikk7JxVRk+iYTeFTZfQ14e/pNOhWhi855VDE0v1YCGRtQe aE872uRwo7xoew8h6CsnSLd+nt+1W1KwbvJbzh+htwen/7uv9bHTRvCHqAcQiMNI5OJ/ 1p+7MnDvB2yrfdmD2uWg4H2fdubgh1ChnWQzTCPkoCXAPMsmk9rGmtzbdEFNbLY2AGSH E/gWuibxWDl6j/3vRJdDmoeh0ZaUaXFRVoxVHVsD0WB1IV2f2t2CEFqgXW9rC2236OdH 8W0YqhCyUYvi1khltg5wLNbyhmp7k9qmzgAqfMFctKFZkmGdLq0HxBGCJUMhQoCP9LRy vFrA== MIME-Version: 1.0 X-Received: by 10.152.29.41 with SMTP id g9mr16887286lah.44.1373536331195; Thu, 11 Jul 2013 02:52:11 -0700 (PDT) Received: by 10.114.80.5 with HTTP; Thu, 11 Jul 2013 02:52:11 -0700 (PDT) X-Originating-IP: [189.11.154.208] In-Reply-To: <20130711070846.GA21279@itx> References: <201307110418.r6B4I4k8072864@freebsd-current.sentex.ca> <20130711070541.GA21264@itx> <20130711070846.GA21279@itx> Date: Thu, 11 Jul 2013 06:52:11 -0300 Message-ID: Subject: Re: [head tinderbox] failure on sparc64/sparc64 From: Jackson Donadel To: Adrian Chadd , current@freebsd.org, sparc64@freebsd.org X-Gm-Message-State: ALoCoQlhXDm4sDXWLCkwaWXjaOUih6XNWLQ7wsL0fJzBOyPrke00R+RudN2iGr/xtBIWMyVGf/8K X-Mailman-Approved-At: Thu, 11 Jul 2013 11:47:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 09:52:18 -0000 I think it=B4s in your kernel config file LINT. In your log we can read this >>>> Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 I had the same issue with current yesterday. 2013/7/11 Navdeep Parhar > On Thu, Jul 11, 2013 at 12:07:33AM -0700, Adrian Chadd wrote: > > On 11 July 2013 00:05, Navdeep Parhar wrote: > > > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: > > >> I don't get why this is dying. any ideas? > > > > > > Maybe because sparc64's ucontext.h is getting pulled in, and it has > > > this: > > > > > > #define mc_flags mc_global[0] > > > > Ugh, we should fix this. When did this happen? > > You tell me. I was just running cscope in my spare time ;-) > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 12:11:08 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EB7E34C5; Thu, 11 Jul 2013 12:11:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 35E6718C5; Thu, 11 Jul 2013 12:11:07 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 90CC93C2C4C; Thu, 11 Jul 2013 22:11:01 +1000 (EST) Date: Thu, 11 Jul 2013 22:11:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Chisnall Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity In-Reply-To: Message-ID: <20130711202908.L84170@besplex.bde.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=K8x6hFqI c=1 sm=1 a=GSpoo125mhwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mlUDQFikY8EA:10 a=AJ7DxV0eBxafINBosPIA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 X-Mailman-Approved-At: Thu, 11 Jul 2013 12:18:18 +0000 Cc: freebsd-toolchain@FreeBSD.org, Garrett Wollman , FreeBSD CURRENT , Bruce Evans , Tijl Coosemans , freebsd-standards@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 12:11:09 -0000 On Thu, 11 Jul 2013, David Chisnall wrote: > You're joining in this discussion starting in the middle, so you probably missed the earlier explanation. I was mainly addressing a C99 point. I know little about C++ or C11. > On 11 Jul 2013, at 05:21, Bruce Evans wrote: > >> I don't see how any conforming program can access the isnan() function >> directly. It is just as protected as __isnan() would be. (isnan)() >> gives the function (the function prototype uses this), but conforming >> programs can't do that since the function might not exist. Maybe some >> non-conforming program like autoconfig reads or libm.a and >> creates a bug for C++. > > The cmath header defines a template function isnan that invokes the isnan macro, but then undefines the isnan macro. This causes a problem because when someone does something along the lines of using namespace std then they end up with two functions called isnan and the compiler gets to pick the one to use. Unfortunately, std::isnan() returns a bool, whereas isnan() returns an int. > > The C++ headers are not required to be conforming C code, because they are not C, and our math.h causes namespace pollution in C++ when included from . is also not required to be conforming C code, let alone C++ code, so there is only a practical requirement that it works when included in the C++ implementation. >> The FreeBSD isnan() implementation would be broken by removing the >> isnan() function from libm.a or ifdefing it in . Changing the >> function to __isnan() would cause compatibility problems. The function >> is intentionally named isnan() to reduce compatibility problems. > > On OS X this is avoided because their isnan() macro expands to call one of the __-prefixed inline functions (which adopt your suggestion of being implemented as x != x, for all types). I am not sure that this is required for standards conformance, but it is certainly cleaner. Your statement that having the function not called isnan() causes compatibility problems is demonstrably false, as neither OS X nor glibc has a function called isnan() and, unlike us, they do not experience problems with this macro. The compatibility that I'm talking about is with old versions of FreeBSD. isnan() is still in libc as a function since that was part of the FreeBSD ABI and too many things depended on getting it from there. It was recently removed from libc.so, but is still in libm.a. This causes some implementation problems in libm that are still not completely solved. I keep having to edit msun/src/s_isnan.c the msun sources are more portable. Mostly I need to kill the isnan() there so that it doesn't get in the way of the one in libc. This mostly works even if there is none in libc, since the builtins result in neither being used. isnanf() is more of a problem, since it is mapped to __isnanf() and there is no builtin for __isnanf(). The old functions have actually been removed from libc.a too. They only in libc_pic.a. libc.a still has isnan.o, but that is bogus since isnan.o is now empty. > It would also be nice to implement these macros using _Generic when compiling in C11 mode, as it will allow the compiler to produce more helpful warning messages. I would propose this implementation: > #if __has_builtin(__builtin_isnan) This won't work for me, since I develop and test msun with old compilers that don't support __has_builtin(). Much the same set of compilers also don't have enough FP builtins. It also doesn't even work. clang has squillions of builtins that aren't really builtines so they reduce to libcalls. gcc has fewer builtins, but still many that reduce to libcalls. An example is fma(). __has_builtin(__builtin_fma) is true for clang on amd64 (freefall), but at least freefalls's CPU doesn't support fma in hardware, so the builtin can't really work, and in fact it doesn't -- it reduces to a libcall. This might change if the hardware supports fma, but then __has_builtin(__builtin_fma) would be even more useless for telling if fma is worth using. C99 has macros FP_FAST_FMA[FL] whose implementation makes them almost equally useless. For example, ia64 has fma in hardware and the implementation defines all of FP_FAST_FMA[FL] for ia64. But fma is implemented as an extern function, partly because there is no way to tell if __builtin_fma is any good (but IIRC, __builtin_fma is no good on ia64 either, since it reduces to the same extern function). The extern function is slow (something like 20 cycles instead of 1 for the fma operation). But if you ignore the existence of the C99 fma API and just write expressions of the form (a*x + b), then gcc on ia64 will automatically use the hardware fma, although this is technically wrong in some fenv environments. For gcc-4.2.1, __has_builtin(__builtin_fma) is a syntax error. I test with gcc-3.x. It is also missing __builtin_isnan(). The msun implementation knows that isnan() and other classification macros are too slow to actually use, and rarely uses them. Sometimes it is inherent that it can do better, because it already knows the bits in the macros and can test the bits directly. I have had limited tests with arranging access macros so that loads of the bits can be shared. > #define isnan(x) __builtin_isnan(x) > #else > static __inline int > __isnanf(float __x) > { > return (__x != __x); > } Here we can do better in most cases by hard-coding this without the ifdef. > static __inline int > __isnand(double __x) > { > return (__x != __x); > } __isnand() is a strange name, and doesn't match compiler conventions for builtins. Compilers use __builtin_isnan() and map this to the libcall __isnan(). > static __inline int > __isnanl(long double __x) > { > return (__x != __x); > } > #if __STDC_VERSION__ >= 201112L > #define isnan(x) _Generic((x), \ > float: __isnanf(x), \ > double: __isnand(x), \ > long double: __isnanl(x)) Does _Generic() have no side effects, like sizeof()? > #else > #define isnan(x) \ > ((sizeof (x) == sizeof (float)) ? __isnanf(x) \ > : (sizeof (x) == sizeof (double)) ? __isnand(x) \ > : __isnanl(x)) > #endif > #endif Both cases need to use __builtin_isnan[fl]() and depend on compiler magic to have any chance of avoiding side effects from loads and parameter passing. Generic stuff doesn't seem to work right for either isnan() or __builtin_isnan(), though it could for at least the latter. According to a quick grep of strings $(which clang), __builtin_classify() is generic but __builtin_isnan*() isn't (the former has no type suffixes but the latter does, and testing shows that the latter doesn't work without the suffices). It is the most useful FP builtins like __builtin_fabs*() that aren't generic. C99 probably prevents fabs*() being generic, but I think any builtin can be generic, and the isnan() macro is specified to be generic, so if compilers understood it directly their builtin for it needs to be and can be generic. > For a trivial example of why this is an improvement in terms of error reporting, consider this trivial piece of code: > > int is(int x) > { > return isnan(x); > } > > With our current implementation, this compiles and links without any warnings, although it will have somewhat interesting results at run time. With the __builtin_isnan() version, clang reports this error: > > isnan.c:35:15: error: floating point classification requires argument of > floating point type (passed in 'int') > return isnan(x); > ^ > (and then some more about the macro expansion) > > With the C11 version, it reports this error: > > isnan.c:35:15: error: controlling expression type 'int' not compatible with any > generic association type > return isnan(x); > ^ The error message for the __builtin_isnan() version is slightly better up to where it says more. The less-unportable macro can do more classification and detect problems at compile time using __typeof(). isnan(integer) = 0 with no warnings is quite good though. Integers are never NaNs, and converting an integer to a floating point type should never give a NaN. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 12:50:04 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C49D460; Thu, 11 Jul 2013 12:50:04 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id F083C1B1B; Thu, 11 Jul 2013 12:50:03 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6BCo1km015361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Jul 2013 12:50:02 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_C84CB7FF-D855-40EC-9DD9-FD206EB11660"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: David Chisnall In-Reply-To: <20130711202908.L84170@besplex.bde.org> Date: Thu, 11 Jul 2013 13:49:57 +0100 Message-Id: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1503) Cc: David Chisnall , freebsd-toolchain@FreeBSD.org, Garrett Wollman , FreeBSD CURRENT , Tijl Coosemans , freebsd-standards@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 12:50:04 -0000 --Apple-Mail=_C84CB7FF-D855-40EC-9DD9-FD206EB11660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Jul 2013, at 13:11, Bruce Evans wrote: > is also not required to be conforming C code, let alone C++ = code, > so there is only a practical requirement that it works when included > in the C++ implementation. Working with the C++ implementation is the problem that we are trying to = solve. > The compatibility that I'm talking about is with old versions of = FreeBSD. > isnan() is still in libc as a function since that was part of the = FreeBSD > ABI and too many things depended on getting it from there. It was = recently > removed from libc.so, but is still in libm.a. This causes some > implementation problems in libm that are still not completely solved. = I > keep having to edit msun/src/s_isnan.c the msun sources are more = portable. > Mostly I need to kill the isnan() there so that it doesn't get in the > way of the one in libc. This mostly works even if there is none in = libc, > since the builtins result in neither being used. isnanf() is more of = a > problem, since it is mapped to __isnanf() and there is no builtin for > __isnanf(). The old functions have actually been removed from libc.a > too. They only in libc_pic.a. libc.a still has isnan.o, but that is = bogus > since isnan.o is now empty. I don't see a problem with changing the name of the function in the = header and leaving the old symbol in libm for legacy code. =20 >> It would also be nice to implement these macros using _Generic when = compiling in C11 mode, as it will allow the compiler to produce more = helpful warning messages. I would propose this implementation: >=20 >> #if __has_builtin(__builtin_isnan) >=20 > This won't work for me, since I develop and test msun with old = compilers > that don't support __has_builtin(). Much the same set of compilers = also > don't have enough FP builtins. Please look in cdefs.h, which defines __has_builtin(x) to 0 if we the = compiler does not support it. It is therefore safe to use = __has_builtin() in any FreeBSD header. > It also doesn't even work. clang has squillions of builtins that > aren't really builtines so they reduce to libcalls. Which, again, is not a problem for code outside of libm. If libm needs = different definitions of these macros then that's fine, but they should = be private to libm, not installed as public headers. > The msun implementation knows that isnan() and other classification > macros are too slow to actually use, and rarely uses them. =20 Which makes any concerns that only apply to msun internals irrelevant = from the perspective of discussing what goes into this header. >> #define isnan(x) __builtin_isnan(x) >> #else >> static __inline int >> __isnanf(float __x) >> { >> return (__x !=3D __x); >> } >=20 > Here we can do better in most cases by hard-coding this without the = ifdef. They will generate the same code. Clang expands the builtin in the LLVM = IR to a fcmp uno, so will generate the correct code even when doing fast = math optimisations. >> static __inline int >> __isnand(double __x) >> { >> return (__x !=3D __x); >> } >=20 > __isnand() is a strange name, and doesn't match compiler conventions = for > builtins. Compilers use __builtin_isnan() and map this to the libcall > __isnan(). That's fine. >> static __inline int >> __isnanl(long double __x) >> { >> return (__x !=3D __x); >> } >> #if __STDC_VERSION__ >=3D 201112L >> #define isnan(x) _Generic((x), \ >> float: __isnanf(x), \ >> double: __isnand(x), \ >> long double: __isnanl(x)) >=20 > Does _Generic() have no side effects, like sizeof()? Yes. >> #else >> #define isnan(x) \ >> ((sizeof (x) =3D=3D sizeof (float)) ? __isnanf(x) \ >> : (sizeof (x) =3D=3D sizeof (double)) ? __isnand(x) \ >> : __isnanl(x)) >> #endif >> #endif >=20 > Both cases need to use __builtin_isnan[fl]() and depend on compiler > magic to have any chance of avoiding side effects from loads and > parameter passing. > Generic stuff doesn't seem to work right for either isnan() or > __builtin_isnan(), though it could for at least the latter. According > to a quick grep of strings $(which clang), __builtin_classify() is > generic but __builtin_isnan*() isn't (the former has no type suffixes > but the latter does, and testing shows that the latter doesn't work > without the suffices). =20 I'm not sure what you were testing: $ cat isnan2.c=20 int test(float f, double d, long double l) { return __builtin_isnan(f) | __builtin_isnan(d) | __builtin_isnan(l); } $ clang isnan2.c -S -emit-llvm -o - -O1 ... %cmp =3D fcmp uno float %f, 0.000000e+00 %cmp1 =3D fcmp uno double %d, 0.000000e+00 %or4 =3D or i1 %cmp, %cmp1 %cmp2 =3D fcmp uno x86_fp80 %l, 0xK00000000000000000000 ... As you can see, it parses them as generics and generates different IR = for each. I don't believe that there's a way that these would be = translated back into libcalls in the back end. >> For a trivial example of why this is an improvement in terms of error = reporting, consider this trivial piece of code: >>=20 >> int is(int x) >> { >> return isnan(x); >> } >>=20 >> With our current implementation, this compiles and links without any = warnings, although it will have somewhat interesting results at run = time. With the __builtin_isnan() version, clang reports this error: >>=20 >> isnan.c:35:15: error: floating point classification requires argument = of >> floating point type (passed in 'int') >> return isnan(x); >> ^ >> (and then some more about the macro expansion) >>=20 >> With the C11 version, it reports this error: >>=20 >> isnan.c:35:15: error: controlling expression type 'int' not = compatible with any >> generic association type >> return isnan(x); >> ^ >=20 > The error message for the __builtin_isnan() version is slightly better = up > to where it says more. I agree. > The less-unportable macro can do more classification and detect = problems > at compile time using __typeof(). Yes, that would be an improvement, however all of our current = type-generic macros in math.h use sizeof(). > isnan(integer) =3D 0 with no warnings is quite good though. Integers = are > never NaNs, and converting an integer to a floating point type should > never give a NaN. I disagree. isnan(integer) is almost certainly a mistake and so should = be a compile-time error. If it is intentional, it relies on = non-standard behaviour and so should be discouraged. David --Apple-Mail=_C84CB7FF-D855-40EC-9DD9-FD206EB11660 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR3qn2AAoJEKx65DEEsqIdl20P/1LQgcJ0nXFNpCOq37dEkMlY hPc/5+f0g+2U27WGbaiEjwT1lD+Up598h3TmgZqlUsALGLVZ650tDlbHG6eF77US zCmMuCbnWJcTitLaSBaIpvT8HBF5NrfHssPr5AXMaaO66AssKedgnL72GbCHz0CK izxO+p4Wq+kQcG1WfXwhUJZrpCmCYZO1sdBztKN4e6EbI8RRUhM1ySce69yN3/nm BlQbSJQqHttn35+Va9E3t02uXfZivtYjdxPphROymTMgfe4d9MJu85BZqZsrPkxm AglIzrnIdFFkCz9bICrFX8/NNXhEHMHNlzGEhCOf9QUZWLrdiIyhI7FibOs/mtUi RUxeiNupnXso32o0B2gcokm/swUkwiszjDfIyT8K/I3taBHyyrVEmZu2wZ40AZRx TjI5a6pe/Phcq+5PmGFp90NXkONyQ7aCOPPRcWYVictw60BYy7AJDp/Iwa+X6rFI ij3LSPONv+FUOYuJyNct9VIfT2zBHE71Q6LRPzto6PO50gsfVVUsBBl6eXL0ULz/ nWOCckUYHkVciPvdZkP/dV9z5t043KAJMdhkclpsY/h1eVZ9eNPj3T403RzLiWSW hF7+t+dhOP5CkZ2wRe2ONDq6T/mLULaWhVWu5Rgp9VNFk62tWoqSdt2ZsybAjxjT u5vg2zAg+cYrujbX8AN9 =A/T6 -----END PGP SIGNATURE----- --Apple-Mail=_C84CB7FF-D855-40EC-9DD9-FD206EB11660-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 13:23:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A67ED1F3 for ; Thu, 11 Jul 2013 13:23:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 852041CCA for ; Thu, 11 Jul 2013 13:23:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D07EBB983; Thu, 11 Jul 2013 09:23:17 -0400 (EDT) From: John Baldwin To: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 Date: Thu, 11 Jul 2013 09:23:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307091202.24493.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307110923.06548.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 11 Jul 2013 09:23:17 -0400 (EDT) Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 13:23:18 -0000 On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: > John Baldwin wrote: > > On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: > > > Konstantin Belousov wrote: > > > > > > > > Care to provide any useful information ? > > > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- > > handbook/kerneldebug-deadlocks.html > > > > > > Well, the system doesn't deadlock it's perfectly useable so long > > > as you don't touch the file that's wedged. A lot of the time the > > > userland process is unkillable, but often it is killable. How do > > > I get from from the PID to where the FS is stuck in the kernel? > > > > Use kgdb. 'proc ', then 'bt'. > > So, I setup a remote kbgd session, but I still can't figure out how > to get at the information we need. > > (kgdb) proc 5176 > only supported for core file target > > In the mean time, I'll just force it to make a core dump from ddb. > However, I can't reacreate the issue while the mirror (gmirror) is > rebuilding, so we'll have to wait for that to finish. Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the running kernel without having to stop it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 13:02:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA8C8B13; Thu, 11 Jul 2013 13:02:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 482CF1BFD; Thu, 11 Jul 2013 13:02:24 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id CA90F780326; Thu, 11 Jul 2013 23:02:11 +1000 (EST) Date: Thu, 11 Jul 2013 23:02:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Tijl Coosemans Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity In-Reply-To: <51DE7CD0.60306@FreeBSD.org> Message-ID: <20130711221303.A84846@besplex.bde.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <51DE7CD0.60306@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=GSpoo125mhwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mlUDQFikY8EA:10 a=6I5d2MoRAAAA:8 a=0ey3mXvhcGIDxT-u3RAA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 X-Mailman-Approved-At: Thu, 11 Jul 2013 13:34:53 +0000 Cc: Garrett Wollman , FreeBSD CURRENT , freebsd-standards@freebsd.org, Bruce Evans , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 13:02:25 -0000 On Thu, 11 Jul 2013, Tijl Coosemans wrote: > On 2013-07-11 06:21, Bruce Evans wrote: >> On Wed, 10 Jul 2013, Garrett Wollman wrote: >>> < said: >>>> I think isnan(double) and isinf(double) in math.h should only be >>>> visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. >>>> For C99 and higher there should only be the isnan/isinf macros. >>> >>> I believe you are correct. POSIX.1-2008 (which is aligned with C99) >>> consistently calls isnan() a "macro", and gives a pseudo-prototype of >>> >>> int isnan(real-floating x); >> >> Almost any macro may be implemented as a function, if no conforming >> program can tell the difference. It is impossible for technical reasons >> to implement isnan() as a macro (except on weird implementations where >> all real-floating types are physically the same). In the FreeBSD >> implementation, isnan() is a macro, but it is also a function, and >> the macro expands to the function in double precision: >> >> % #define isnan(x) \ >> % ((sizeof (x) == sizeof (float)) ? __isnanf(x) \ >> % : (sizeof (x) == sizeof (double)) ? isnan(x) \ >> % : __isnanl(x)) > > The C99 standard says isnan is a macro. I would say that only means > defined(isnan) is true. Whether that macro then expands to function > calls or not is not important. I think it means only that defined(isnan) is true. isnan() can still be a function (declared or just in the compile-time namespace somewhere, or in a library object). It is reserved in the compile-time namespace, and the standard doesn't cover library objects, so conforming applications can't reference either except via the isnan() macro (if that has its strange historical implementation). >> I don't see how any conforming program can access the isnan() function >> directly. It is just as protected as __isnan() would be. (isnan)() >> gives the function (the function prototype uses this), but conforming >> programs can't do that since the function might not exist. > > I don't think the standard allows a function to be declared with the same > name as a standard macro (it does allow the reverse: define a macro with > the same name as a standard function). I believe the following code is > C99 conforming but it currently does not compile with our math.h: > > ------ > #include > > int (isnan)(int a, int b, int c) { > return (a + b + c); > } > ------ I think isnan is just reserved, so you can't redefine it an any way. I think the reverse is even less allowed. Almost any standard function may be implemented as a macro, and then any macro definition of it would conflict with the previous macro even more than with a previous prototype. E.g.: /* Header. */ void exit(int); #define exit(x) __exit(x) /* Application. */ #undef exit /* non-conforming */ #define exit(x) my_exit(x) /* conflicts without the #undef */ Now suppose the header doesn't define exit(). #define exit(x) my_exit(x) This hides the protoype but doesn't automatically cause problems, especially if exit() is not used after this point. But this is still non-conforming, since exit() is reserved. Here are some relevant parts of C99 (n869.txt): %%% -- Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as macro and as an identifier with file scope in the same name space if any of its associated headers is included. [#2] No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined. [#3] If the program removes (with #undef) any macro definition of an identifier in the first group listed above, the behavior is undefined. %%% Without any include of a header that is specified to declare exit(), file scope things are permitted for it, including defining it and making it a static function, but not making it an extern function. isnan is reserved for use as a macro and as an identifier with file scope by the first clause above. Thus (isnan) cannot even be defined as a static function. But (isnan) is not reserved in inner scopes. I thought that declarations like "int (isnan);" are impossible since they look like syntax errors, but this syntax seems to be allowed an actually work with gcc-3.3.3 and TenDRA-5.0.0. So you can have variables with silly names like (isnan) and (getchar) :-). However, (NULL) for a variable name doesn't work, and (isnan) is a syntax error for struct member names. The compilers may be correct in allowing (isnan) but not (NULL) for variables. isnan happens to be function-like, so the parentheses are special for (isnan), but the parentheses are not special for (NULL). cpp confirms this -- NULL inside of parentheses still gets expanded. The above quote of C99 can cover both since it just says that isnan is reserved for use as a macro. In (isnan), the parentheses prevent isnan being interpreted as a macro so the reservation doesn't apply. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 14:33:44 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8DEA042A; Thu, 11 Jul 2013 14:33:44 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4444F10AB; Thu, 11 Jul 2013 14:33:43 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6BEXZMt028134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Jul 2013 14:33:36 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_F8478B29-A983-4EC7-89DB-B3DA02262956"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: David Chisnall In-Reply-To: <20130711202908.L84170@besplex.bde.org> Date: Thu, 11 Jul 2013 15:33:34 +0100 Message-Id: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1503) Cc: Garrett Wollman , Tijl Coosemans , "freebsd-toolchain@FreeBSD.org" , "freebsd-standards@FreeBSD.org" , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 14:33:44 -0000 --Apple-Mail=_F8478B29-A983-4EC7-89DB-B3DA02262956 Content-Type: multipart/mixed; boundary="Apple-Mail=_AEC87547-9126-4EA9-8106-07500F2E3C05" --Apple-Mail=_AEC87547-9126-4EA9-8106-07500F2E3C05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Jul 2013, at 13:11, Bruce Evans wrote: > The error message for the __builtin_isnan() version is slightly better = up > to where it says more. >=20 > The less-unportable macro can do more classification and detect = problems > at compile time using __typeof(). The attached patch fixes the related test cases in the libc++ test = suite. Please review. This does not use __builtin_isnan(), but it does: - Stop exposing isnan and isinf in the header. We already have __isinf = in libc, so this is used instead. - Call the static functions for isnan __inline__isnan*() so that they = don't conflict with the ones in libm. - Add an __fp_type_select() macro that uses either __Generic(), = __builtin_choose_expr() / __builtin_choose_expr(), or sizeof() = comparisons, depending on what the compiler supports. - Refactor all of the type-generic macros to use __fp_type_select(). =20 David --Apple-Mail=_AEC87547-9126-4EA9-8106-07500F2E3C05 Content-Disposition: attachment; filename=isnan.diff Content-Type: application/octet-stream; name="isnan.diff" Content-Transfer-Encoding: 7bit Index: src/math.h =================================================================== --- src/math.h (revision 253148) +++ src/math.h (working copy) @@ -80,28 +80,39 @@ #define FP_NORMAL 0x04 #define FP_SUBNORMAL 0x08 #define FP_ZERO 0x10 + +#if __STDC_VERSION__ >= 201112L +#define __fp_type_select(x, f, d, ld) _Generic((x), \ + float: f(x), \ + double: d(x), \ + long double: ld(x)) +#elif __GNUC_PREREQ__(5, 1) +#define __fp_type_select(x, f, d, ld) __builtin_choose_expr( \ + __builtin_types_compatible_p(__typeof (x), long double), ld(x), \ + __builtin_choose_expr( \ + __builtin_types_compatible_p(__typeof (x), double), d(x), \ + __builtin_choose_expr( \ + __builtin_types_compatible_p(__typeof (x), float), f(x), (void)0))) +#else +#define __fp_type_select(x, f, d, ld) \ + ((sizeof (x) == sizeof (float)) ? f(x) \ + : (sizeof (x) == sizeof (double)) ? d(x) \ + : ld(x)) +#endif + + + #define fpclassify(x) \ - ((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \ - : (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \ - : __fpclassifyl(x)) + __fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyd) +#define isfinite(x) \ + __fp_type_select(x, __isfinitef, __isfinite, __isfinitel) +#define isinf(x) \ + __fp_type_select(x, __isinff, __isinf, __isinfl) +#define isnan(x) \ + __fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl) +#define isnormal(x) \ + __fp_type_select(x, __isnormalf, __isnormal, __isnormall) -#define isfinite(x) \ - ((sizeof (x) == sizeof (float)) ? __isfinitef(x) \ - : (sizeof (x) == sizeof (double)) ? __isfinite(x) \ - : __isfinitel(x)) -#define isinf(x) \ - ((sizeof (x) == sizeof (float)) ? __isinff(x) \ - : (sizeof (x) == sizeof (double)) ? isinf(x) \ - : __isinfl(x)) -#define isnan(x) \ - ((sizeof (x) == sizeof (float)) ? __isnanf(x) \ - : (sizeof (x) == sizeof (double)) ? isnan(x) \ - : __isnanl(x)) -#define isnormal(x) \ - ((sizeof (x) == sizeof (float)) ? __isnormalf(x) \ - : (sizeof (x) == sizeof (double)) ? __isnormal(x) \ - : __isnormall(x)) - #ifdef __MATH_BUILTIN_RELOPS #define isgreater(x, y) __builtin_isgreater((x), (y)) #define isgreaterequal(x, y) __builtin_isgreaterequal((x), (y)) @@ -119,10 +130,8 @@ #define isunordered(x, y) (isnan(x) || isnan(y)) #endif /* __MATH_BUILTIN_RELOPS */ -#define signbit(x) \ - ((sizeof (x) == sizeof (float)) ? __signbitf(x) \ - : (sizeof (x) == sizeof (double)) ? __signbit(x) \ - : __signbitl(x)) +#define signbit(x) \ + __fp_type_select(x, __signbitf, __signbit, __signbitl) typedef __double_t double_t; typedef __float_t float_t; @@ -175,6 +184,7 @@ int __isfinite(double) __pure2; int __isfinitel(long double) __pure2; int __isinff(float) __pure2; +int __isinf(double) __pure2; int __isinfl(long double) __pure2; int __isnanf(float) __pure2; int __isnanl(long double) __pure2; @@ -185,6 +195,23 @@ int __signbitf(float) __pure2; int __signbitl(long double) __pure2; +static __inline int +__inline_isnanf(float __x) +{ + return (__x != __x); +} +static __inline int +__inline_isnan(double __x) +{ + return (__x != __x); +} +static __inline int +__inline_isnanl(long double __x) +{ + return (__x != __x); +} + + double acos(double); double asin(double); double atan(double); @@ -227,8 +254,6 @@ double fma(double, double, double); double hypot(double, double); int ilogb(double) __pure2; -int (isinf)(double) __pure2; -int (isnan)(double) __pure2; double lgamma(double); long long llrint(double); long long llround(double); --Apple-Mail=_AEC87547-9126-4EA9-8106-07500F2E3C05-- --Apple-Mail=_F8478B29-A983-4EC7-89DB-B3DA02262956 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR3sI+AAoJEKx65DEEsqId32IQAJZK9h5IrteHBj43ympoqEz4 XqfWOje7QIB1nMI10pOdT2oGMjF18ea7g/YMnYZ5PrHtMNlreuYqX/DkoeYvg7Lk WA2cROCI3CgIveTuODn0zfZGAd/vMlOKOm7Vw5s96vzHH/Ow8kVPbAOzd+bfmCSk xGKSi8pOHhFqBXufb269cy1Pjlh78cdY3/mEtxGFrpVxO3IZP6o844UiAicicQ+1 aqggtQH+BK7UfJN2uwGiuLjxjJmCfJR2MNqqA86q3XeACMOh52wd49w2CWt2cNrv AP5SMizT5G6gt+Qvvev5aN+1EZM7pTTSTfMtfCJyhP6iqmRPQ5yISj1A/qIzPaPd 5Qqj+xa0Y87OTf1E5xihIpZa3OileGA9nvJPLiUejLM67rjmCoA8Yea3yKoxR/58 EY6L+ZsLSJiXihO/mdTavVmHpc9u+DEO6BWo94dycciNE6KXOrFspQe6SyAgCPZ2 bqorYrrT+wWBKAox5cjGwBnkibSCdqXCZiPo/lPreZQRKgGHWgxuOSXj705fAumT 1Gg2rIbvfXWVoDlKUnXhHcmiAkRJL8hQsN/KOBTP5zOXA9xCd2LSnWSEBy5nJXha lnoBga9xG1cNlLaSMwRNd3WlSLtA5sW8ldz/wWJlaHh4zMijBwoip9VpFiLrVSi7 f4Mj5wRDY9oZclRi3PHa =v+Kg -----END PGP SIGNATURE----- --Apple-Mail=_F8478B29-A983-4EC7-89DB-B3DA02262956-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 14:45:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F71C76C; Thu, 11 Jul 2013 14:45:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id 050EA1144; Thu, 11 Jul 2013 14:45:20 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id e11so7012512wgh.18 for ; Thu, 11 Jul 2013 07:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gXQgnu3fjmEyjHCw5ziWp+KUkJefYsKjM+HhWMiXFhs=; b=dmP2mjHdQwgO6uVpse4v+jhObhYl5aorijtKRw4fAHfompF6YthZNPfeVaxbq3+J2B ocFoktqPJfQ6a5ENsTJBkzRpKRMKx5R3nl2iZ4HbBip/iMwtB7UOKC130JGDUmu7slVJ Pq4+L45yfBTYWs/EwjRAkgKv+7oL1bE1t7FPx7XuNa8FYKGb6bE3s6yY2jDNEZ3rjG/Z Vxb3UBjRH2+SyIdD1VGobndXAwjht2EU86VhWyeUbnzC+d4gqr9xR+rmFkL4rBQIR2fB vlBliwJpuCgHaKbOMd6yAZN+gJkT+WzFfzqAahS7wb5m4euu3khhAou8njSlCZ5KKx1O 4EGA== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr20771825wjs.79.1373553920141; Thu, 11 Jul 2013 07:45:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 11 Jul 2013 07:45:19 -0700 (PDT) In-Reply-To: <20130711101720.GZ67810@FreeBSD.org> References: <20130711101720.GZ67810@FreeBSD.org> Date: Thu, 11 Jul 2013 07:45:19 -0700 X-Google-Sender-Auth: DU3KH1FtBTygDfvpsNXsH963f7s Message-ID: Subject: Re: hacking - aio_sendfile() From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 14:45:21 -0000 I reference the source/dest FDs in the queue method. Is that not good enough? -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 14:51:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C818F9A9; Thu, 11 Jul 2013 14:51:21 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3737A11A3; Thu, 11 Jul 2013 14:51:20 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r6BEpJZQ009044; Thu, 11 Jul 2013 18:51:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r6BEpJvt009043; Thu, 11 Jul 2013 18:51:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 11 Jul 2013 18:51:19 +0400 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: hacking - aio_sendfile() Message-ID: <20130711145119.GA8839@glebius.int.ru> References: <20130711101720.GZ67810@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 14:51:21 -0000 On Thu, Jul 11, 2013 at 07:45:19AM -0700, Adrian Chadd wrote: A> I reference the source/dest FDs in the queue method. Is that not good enough? I see. Should probably work, but needs testing. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 15:11:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9890B4A9; Thu, 11 Jul 2013 15:11:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2F11323; Thu, 11 Jul 2013 15:11:11 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id w59so6944762wes.24 for ; Thu, 11 Jul 2013 08:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5GrbIpLRfcEB+FsmLDSh3nYSlQqrwjW6ZsgDQGxZuto=; b=0UPLiQN4fuHVy0Zj7o5fddfEenIWu2Gh87Ry73hydLT9zBbOfAgu7BpUIfkTapIeaH 4b5snfvZpO8lmYIhoqnj4PHdyZOyvKuYXoI16gwFth5BzG3MEXqdpWLRJm0xQc6PRSfS TnVTvWsuufxMFL1SYwMqqdP6S5y9B8Oe7NVseZSt8Iu9HmRFyum9JMAPtidXu2TahedD 9/lvPUbVYAZ5Z/nsZco1ErfvEUdepYCcSBFgr3DVABErz7LQmbMm1/nc5I3pr9Osd9yq A8QJ6jz/AuvxDC3mP+KMEb/wiYf2u6mN3CerusJTDMsRL8rPuwrY5B57oHOoOCqr6Jr7 jAKQ== MIME-Version: 1.0 X-Received: by 10.180.82.196 with SMTP id k4mr22784884wiy.0.1373555471259; Thu, 11 Jul 2013 08:11:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 11 Jul 2013 08:11:11 -0700 (PDT) In-Reply-To: <20130711145119.GA8839@glebius.int.ru> References: <20130711101720.GZ67810@FreeBSD.org> <20130711145119.GA8839@glebius.int.ru> Date: Thu, 11 Jul 2013 08:11:11 -0700 X-Google-Sender-Auth: 1AqSpzJj5qF4mObylESV0SjVl1s Message-ID: Subject: Re: hacking - aio_sendfile() From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 15:11:12 -0000 On 11 July 2013 07:51, Gleb Smirnoff wrote: > On Thu, Jul 11, 2013 at 07:45:19AM -0700, Adrian Chadd wrote: > A> I reference the source/dest FDs in the queue method. Is that not good enough? > > I see. Should probably work, but needs testing. It's terrible - I'd think I should pass the file ref's into kern_sendfile() so I'm sure that the process hasn't close/dup'ed an FD in its place in the meantime. Is that better? -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 15:28:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA0589B; Thu, 11 Jul 2013 15:28:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 51C0B146B; Thu, 11 Jul 2013 15:28:34 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id C96DBD409AA; Fri, 12 Jul 2013 01:28:28 +1000 (EST) Date: Fri, 12 Jul 2013 01:28:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Chisnall Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity In-Reply-To: Message-ID: <20130711232150.G85090@besplex.bde.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Q6eKePKa c=1 sm=1 a=GSpoo125mhwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mlUDQFikY8EA:10 a=muatdVjo9zT8fA-HE-QA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 X-Mailman-Approved-At: Thu, 11 Jul 2013 15:46:44 +0000 Cc: freebsd-toolchain@freebsd.org, Garrett Wollman , FreeBSD CURRENT , Bruce Evans , Tijl Coosemans , freebsd-standards@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 15:28:35 -0000 On Thu, 11 Jul 2013, David Chisnall wrote: > On 11 Jul 2013, at 13:11, Bruce Evans wrote: > >> is also not required to be conforming C code, let alone C++ code, >> so there is only a practical requirement that it works when included >> in the C++ implementation. > > Working with the C++ implementation is the problem that we are trying to solve. > >> The compatibility that I'm talking about is with old versions of FreeBSD. >> isnan() is still in libc as a function since that was part of the FreeBSD >> ABI and too many things depended on getting it from there. It was recently >> ... > > I don't see a problem with changing the name of the function in the header and leaving the old symbol in libm for legacy code. I don't even see why old code needs the symbol. Old code should link to old compat libraries that still have it. > >>> It would also be nice to implement these macros using _Generic when compiling in C11 mode, as it will allow the compiler to produce more helpful warning messages. I would propose this implementation: >> >>> #if __has_builtin(__builtin_isnan) >> >> This won't work for me, since I develop and test msun with old compilers >> that don't support __has_builtin(). Much the same set of compilers also >> don't have enough FP builtins. > > Please look in cdefs.h, which defines __has_builtin(x) to 0 if we the compiler does not support it. It is therefore safe to use __has_builtin() in any FreeBSD header. The old compilers run on old systems that don't have that in cdefs.h (though I sometimes edit it to add compatibility cruft like that). msun sources are otherwise portable to these systems. Well, not quite. They are not fully modular and also depend on stuff in libc/include and libc/${ARCH}. I have to update or edit headers there. This hack also doesn't work with gcc in -current. gcc has __builtin_isnan but not __has_builtin(), so __has_builtin(__builtin_isnan) gives the wrong result 0. >> It also doesn't even work. clang has squillions of builtins that >> aren't really builtines so they reduce to libcalls. > > Which, again, is not a problem for code outside of libm. If libm needs different definitions of these macros then that's fine, but they should be private to libm, not installed as public headers. Yes it is. It means that nothing should use isnan() or FP_FAST_FMA* outside of libm either, since isnan() is too slow and FP_FAST_FMA* can't be trusted. Even the implementation can't reliably tell if __builtin_isnan is usuable or better than alternatives. >> The msun implementation knows that isnan() and other classification >> macros are too slow to actually use, and rarely uses them. > > Which makes any concerns that only apply to msun internals irrelevant from the perspective of discussing what goes into this header. No, the efficiency of isnan() is more important for externals, because the internals already have work-arounds. >>> #define isnan(x) __builtin_isnan(x) >>> #else >>> static __inline int >>> __isnanf(float __x) >>> { >>> return (__x != __x); >>> } >> >> Here we can do better in most cases by hard-coding this without the ifdef. > > They will generate the same code. Clang expands the builtin in the LLVM IR to a fcmp uno, so will generate the correct code even when doing fast math optimisations. On some arches the same, and not affected by -ffast-math. But this is not necessarily the fastest code, so it is a performance bug if clang akways generates the same code for the builtin. Bit tests are faster in some cases, and may be required to prevent exceptions for signaling NaNs. -ffast-math could reasonably optimize x != x to "false". It already assumes that things like overflow and NaN results can't happen, so why not optimize further by assuming that NaN inputs can't happen? >> Generic stuff doesn't seem to work right for either isnan() or >> __builtin_isnan(), though it could for at least the latter. According >> to a quick grep of strings $(which clang), __builtin_classify() is >> generic but __builtin_isnan*() isn't (the former has no type suffixes >> but the latter does, and testing shows that the latter doesn't work >> without the suffices). > > I'm not sure what you were testing: Mostly isnan() without including , and gcc. I was confused by gcc converting floats to doubles. > $ cat isnan2.c > > int test(float f, double d, long double l) > { > return __builtin_isnan(f) | > __builtin_isnan(d) | > __builtin_isnan(l); > } > $ clang isnan2.c -S -emit-llvm -o - -O1 > ... > %cmp = fcmp uno float %f, 0.000000e+00 > %cmp1 = fcmp uno double %d, 0.000000e+00 > %or4 = or i1 %cmp, %cmp1 > %cmp2 = fcmp uno x86_fp80 %l, 0xK00000000000000000000 > ... > > As you can see, it parses them as generics and generates different IR for each. I don't believe that there's a way that these would be translated back into libcalls in the back end. Yes, most cases work right. gcc converts f to double and compares the result, but that mostly works. It would be just a pessimization except te conversion gives an exception for signaling NaNs. I hope I remember correctly that the comparision doesn't give this exception. When the above is changed to use __builtin_isnanf() on the float, gcc does the right thing (no conversion). The almost-correct handling of the float is apparently not completely accidental, since for the long double gcc doesn't convert to double before comparing. With gcc, you also don't have to use __builtin_isnan*() to get the builtins. gcc doesn't warn about the undeclared isnan(), and generates the same code as the above. You can also use isnanf() on the float to avoid the conversion. isnanf() is nonstandard, so gcc warns about it. If isnan() is declared as a function as in , then gcc forgets that it is standard and generates a conversion for the long double case too. This almost works, like the conversion for the float case, since changing the precision doesn't affect the classification With clang, you only get the builtins if you use them explicitly. clang generates verbose warnings for undeclared isnan() and always calls the named function. Conversions occur according to the prototype, if any. The above was tested only on amd64. isinf() is even more interesting and broken. Now gcc doesn't convert automatically to builtins. It does the reverse, in broken ways when __builtin_isinf() is used on floats and long doubles: - it converts the float to double to create the arg. Mostly works, as above. - it doesn't convert the long double to double, but copies it to the stack pessimally through integer registers. The pessimization can be fixed by compiling with -march=core2. isinf() is called twice with a double arg and once with a long double arg. This shows that gcc doesn't really understand its own builtin, but is just passing the values with the default promotions that occur when there is no prototype in scope. When __builtin_isinff() is used on the float arg and __builtin_isinfl() is used on the long double arg, gcc passes the args correctly except for pessimizing the long double. It converts __builtin_isinff() to isinff(), etc. This is very broken, since isinff() is in the application namespace. Apart from that, it causes the following problems: - isinff(), isinf() and isinfl() can't easily be removed from libraries - in general, there is no way to know the name of a libcall functions that might be generated for builtins that don't really exist. gcc also converts __builtin_fma() to fma(). That works and is not a namespace error since fma() is a standard API that must exist as a function. clang does different things wrong for __builtin_isinf(). It gets the type stuff right, as for __builtin_isnan(). It never generates libcalls, so it doesn't need a differently named set of extern functions. But it has the major pessimization of calling extern functions for fabs(), fabsf() and fabsl(). The latter is weird, since clang optimizes explicit fabs*() calls almost perfectly on amd64 using SSE bit operations for floats and doubles and i387 hardware fabs for long doubles (bit operations also work for long doubles, but are less convenient and much slower when done wrong). I probably knew some of the previous paragraph when I wrote a local isinf() for catrig*.c. catrig*.c is unlike most of msun. It uses classification macros a lot. Efficiency investigations showed that these work OK provided they always use efficient builtins and in particular, never use the standard macros (except isnan() = itself -> builtin for gcc). isinf(x) is just (fabs(x) == INFINITY), like clang generates for __builtin_isinf(), but much better since the fabs() is explicit so clang doesn't neglect to optimize it. This works well for gcc too (3.x and 4.2.1). Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 15:50:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2CB0DC8F; Thu, 11 Jul 2013 15:50:21 +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 02C2316CD; Thu, 11 Jul 2013 15:50:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6BFoJd6079566; Thu, 11 Jul 2013 11:50:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6BFoJYc079555; Thu, 11 Jul 2013 15:50:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Jul 2013 15:50:19 GMT Message-Id: <201307111550.r6BFoJYc079555@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:50:21 -0000 TB --- 2013-07-11 14:27:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 14:27:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 14:27:18 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-11 14:27:18 - cleaning the object tree TB --- 2013-07-11 14:28:24 - /usr/local/bin/svn stat /src TB --- 2013-07-11 14:28:39 - At svn revision 253186 TB --- 2013-07-11 14:28:40 - building world TB --- 2013-07-11 14:28:40 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 14:28:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 14:28:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 14:28:40 - SRCCONF=/dev/null TB --- 2013-07-11 14:28:40 - TARGET=sparc64 TB --- 2013-07-11 14:28:40 - TARGET_ARCH=sparc64 TB --- 2013-07-11 14:28:40 - TZ=UTC TB --- 2013-07-11 14:28:40 - __MAKE_CONF=/dev/null TB --- 2013-07-11 14:28:40 - cd /src TB --- 2013-07-11 14:28:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 11 14:28:47 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 11 15:39:09 UTC 2013 TB --- 2013-07-11 15:39:09 - generating LINT kernel config TB --- 2013-07-11 15:39:09 - cd /src/sys/sparc64/conf TB --- 2013-07-11 15:39:09 - /usr/bin/make -B LINT TB --- 2013-07-11 15:39:09 - cd /src/sys/sparc64/conf TB --- 2013-07-11 15:39:09 - /usr/sbin/config -m LINT TB --- 2013-07-11 15:39:09 - building LINT kernel TB --- 2013-07-11 15:39:09 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 15:39:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 15:39:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 15:39:09 - SRCCONF=/dev/null TB --- 2013-07-11 15:39:09 - TARGET=sparc64 TB --- 2013-07-11 15:39:09 - TARGET_ARCH=sparc64 TB --- 2013-07-11 15:39:09 - TZ=UTC TB --- 2013-07-11 15:39:09 - __MAKE_CONF=/dev/null TB --- 2013-07-11 15:39:09 - cd /src TB --- 2013-07-11 15:39:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 11 15:39:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-11 15:50:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-11 15:50:19 - ERROR: failed to build LINT kernel TB --- 2013-07-11 15:50:19 - 3801.13 user 645.12 system 4981.71 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 16:07:46 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E6867B8; Thu, 11 Jul 2013 16:07:46 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7233217A2; Thu, 11 Jul 2013 16:07:45 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 9442B6148; Thu, 11 Jul 2013 12:07:43 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: x-enigmail-version:openpgp:content-type; b=jbRIHMAGs3gOrxM86xUSY78Qf7QEQQ2OsbwKBKdNP9toiwvX+xFdQtvJ7Vp/Xtpxb TNTRJMy2tz61m3M/RE0kvqjDLTaGPYHxobTxKbOcykow202HXNR8N8r+Kvq9/TL Message-ID: <51DED84D.30300@protected-networks.net> Date: Thu, 11 Jul 2013 12:07:41 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130710 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: fix for SVN r253208 breaking buildkernel with gcc X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: multipart/mixed; boundary="------------080501020105090906020400" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: andre@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 16:07:46 -0000 This is a multi-part message in MIME format. --------------080501020105090906020400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Seems gcc is rather fussy about propagating 'const' and fails to compile /usr/src/sys/crypto/siphash/siphash.c after SVN r253208. I believe the attached patch is correct but please review .. imb --------------080501020105090906020400-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 16:09:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30C9D8E2 for ; Thu, 11 Jul 2013 16:09:51 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 051AF17BC for ; Thu, 11 Jul 2013 16:09:50 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id F3ED36148 for ; Thu, 11 Jul 2013 12:09:43 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=XJarNhtrwqXteIr0+vd6ITWf9giNPi6h0vINgY5+EqqHC5x7Xet/mY0g0yBrYjABY VdemA7H15mK/rHzEv2WR6jGBmUi3VHmCb5JP49difN9uBrn2mS3IrF3yT47AiQ/ Message-ID: <51DED8C6.6020807@protected-networks.net> Date: Thu, 11 Jul 2013 12:09:42 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130710 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: fix for SVN r253208 breaking buildkernel with gcc References: <51DED84D.30300@protected-networks.net> In-Reply-To: <51DED84D.30300@protected-networks.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 16:09:51 -0000 On 07/11/13 12:07, Michael Butler wrote: > Seems gcc is rather fussy about propagating 'const' and fails to compile > /usr/src/sys/crypto/siphash/siphash.c after SVN r253208. > > I believe the attached patch is correct but please review .. > > imb grr .. missing attachment :-( Index: /usr/src/sys/crypto/siphash/siphash.c =================================================================== --- /usr/src/sys/crypto/siphash/siphash.c (revision 253210) +++ /usr/src/sys/crypto/siphash/siphash.c (working copy) @@ -119,7 +119,8 @@ void SipHash_Update(SIPHASH_CTX *ctx, const void *src, size_t len) { - uint64_t m, *p; + uint64_t m; + const uint64_t *p; const uint8_t *s; size_t rem; @@ -144,13 +145,13 @@ /* Optimze for 64bit aligned/unaligned access. */ if (((uintptr_t)s & 0x7) == 0) { - for (p = (uint64_t *)s; len > 0; len--, p++) { + for (p = (const uint64_t *)s; len > 0; len--, p++) { m = le64toh(*p); ctx->v[3] ^= m; SipRounds(ctx, 0); ctx->v[0] ^= m; } - s = (uint8_t *)p; + s = (const uint8_t *)p; } else { for (; len > 0; len--, s += 8) { m = le64dec(s); From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 16:28:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63A2312F for ; Thu, 11 Jul 2013 16:28:00 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CFD70189D for ; Thu, 11 Jul 2013 16:27:59 +0000 (UTC) Received: (qmail 90040 invoked from network); 11 Jul 2013 17:18:32 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 17:18:32 -0000 Message-ID: <51DEDCFF.4080700@freebsd.org> Date: Thu, 11 Jul 2013 18:27:43 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Butler Subject: Re: fix for SVN r253208 breaking buildkernel with gcc References: <51DED84D.30300@protected-networks.net> <51DED8C6.6020807@protected-networks.net> In-Reply-To: <51DED8C6.6020807@protected-networks.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 16:28:00 -0000 On 11.07.2013 18:09, Michael Butler wrote: > On 07/11/13 12:07, Michael Butler wrote: >> Seems gcc is rather fussy about propagating 'const' and fails to compile >> /usr/src/sys/crypto/siphash/siphash.c after SVN r253208. >> >> I believe the attached patch is correct but please review .. >> >> imb > > grr .. missing attachment :-( Thanks, applied your patch in r253214. -- Andre > Index: /usr/src/sys/crypto/siphash/siphash.c > =================================================================== > --- /usr/src/sys/crypto/siphash/siphash.c (revision 253210) > +++ /usr/src/sys/crypto/siphash/siphash.c (working copy) > @@ -119,7 +119,8 @@ > void > SipHash_Update(SIPHASH_CTX *ctx, const void *src, size_t len) > { > - uint64_t m, *p; > + uint64_t m; > + const uint64_t *p; > const uint8_t *s; > size_t rem; > > @@ -144,13 +145,13 @@ > > /* Optimze for 64bit aligned/unaligned access. */ > if (((uintptr_t)s & 0x7) == 0) { > - for (p = (uint64_t *)s; len > 0; len--, p++) { > + for (p = (const uint64_t *)s; len > 0; len--, p++) { > m = le64toh(*p); > ctx->v[3] ^= m; > SipRounds(ctx, 0); > ctx->v[0] ^= m; > } > - s = (uint8_t *)p; > + s = (const uint8_t *)p; > } else { > for (; len > 0; len--, s += 8) { > m = le64dec(s); > > > _______________________________________________ > 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 Thu Jul 11 17:41:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 38A80788; Thu, 11 Jul 2013 17:41:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 14B7A1C2A; Thu, 11 Jul 2013 17:41:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6BDFEB982; Thu, 11 Jul 2013 13:41:20 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 Date: Thu, 11 Jul 2013 09:56:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307110418.r6B4I4k8072864@freebsd-current.sentex.ca> <20130711070541.GA21264@itx> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307110956.11699.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 11 Jul 2013 13:41:20 -0400 (EDT) Cc: Adrian Chadd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 17:41:21 -0000 On Thursday, July 11, 2013 3:07:33 am Adrian Chadd wrote: > On 11 July 2013 00:05, Navdeep Parhar wrote: > > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: > >> I don't get why this is dying. any ideas? > > > > Maybe because sparc64's ucontext.h is getting pulled in, and it has > > this: > > > > #define mc_flags mc_global[0] > > Ugh, we should fix this. When did this happen? annotate is your friend. It's over 10 years old: Working file: /home/jhb/work/freebsd/svn/head/sys/sparc64/include/ucontext.h ------------------------------------------------------------------------ r105733 | jake | 2002-10-22 14:03:15 -0400 (Tue, 22 Oct 2002) | 13 lines - Expand struct trapframe to 256 bytes, make all fields fixed width and the same size. Add some fields that previously overlapped with something else or were missing. - Make struct regs and struct mcontext (minus floating point) the same as struct trapframe so converting between them is easy (null). - Add space for saving floating point state to struct mcontext. This requires that it be 64 byte aligned. - Add assertions that none of these structures change size, as they are part of the ABI. - Remove some dead code in sendsig(). - Save and restore %gsr in struct trapframe. Remember to restore %fsr. - Add some comments to exception.S. ------------------------------------------------------------------------ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 17:10:20 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD671DEF; Thu, 11 Jul 2013 17:10:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 71BFC1AB4; Thu, 11 Jul 2013 17:10:20 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id EA3171A060B; Fri, 12 Jul 2013 02:38:06 +1000 (EST) Date: Fri, 12 Jul 2013 02:38:05 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Chisnall Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity In-Reply-To: Message-ID: <20130712013458.X85470@besplex.bde.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=GSpoo125mhwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mlUDQFikY8EA:10 a=5RSJzs5NDUsr1fZtrzAA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 X-Mailman-Approved-At: Thu, 11 Jul 2013 18:39:30 +0000 Cc: FreeBSD CURRENT , Garrett Wollman , "freebsd-toolchain@FreeBSD.org" , Bruce Evans , Tijl Coosemans , "freebsd-standards@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 17:10:21 -0000 On Thu, 11 Jul 2013, David Chisnall wrote: > On 11 Jul 2013, at 13:11, Bruce Evans wrote: > >> The error message for the __builtin_isnan() version is slightly better up >> to where it says more. >> >> The less-unportable macro can do more classification and detect problems >> at compile time using __typeof(). > > The attached patch fixes the related test cases in the libc++ test suite. Please review. OK if the ifdefs work and the style bugs are fixed. > This does not use __builtin_isnan(), but it does: > > - Stop exposing isnan and isinf in the header. We already have __isinf in libc, so this is used instead. > > - Call the static functions for isnan __inline__isnan*() so that they don't conflict with the ones in libm. > > - Add an __fp_type_select() macro that uses either __Generic(), __builtin_choose_expr() / __builtin_choose_expr(), or sizeof() comparisons, depending on what the compiler supports. > > - Refactor all of the type-generic macros to use __fp_type_select(). % Index: src/math.h % =================================================================== % --- src/math.h (revision 253148) % +++ src/math.h (working copy) % @@ -80,28 +80,39 @@ % #define FP_NORMAL 0x04 % #define FP_SUBNORMAL 0x08 % #define FP_ZERO 0x10 % + % +#if __STDC_VERSION__ >= 201112L % +#define __fp_type_select(x, f, d, ld) _Generic((x), \ % + float: f(x), \ % + double: d(x), \ % + long double: ld(x)) The normal formatting of this is unclear. Except for the tab after #define. math.h has only 1 other instance of a space after #define. % +#elif __GNUC_PREREQ__(5, 1) % +#define __fp_type_select(x, f, d, ld) __builtin_choose_expr( \ % + __builtin_types_compatible_p(__typeof (x), long double), ld(x), \ % + __builtin_choose_expr( \ % + __builtin_types_compatible_p(__typeof (x), double), d(x), \ % + __builtin_choose_expr( \ % + __builtin_types_compatible_p(__typeof (x), float), f(x), (void)0))) Extra space after __typeof. Normal formatting doesn't march to the right like this... % +#else % +#define __fp_type_select(x, f, d, ld) \ % + ((sizeof (x) == sizeof (float)) ? f(x) \ % + : (sizeof (x) == sizeof (double)) ? d(x) \ % + : ld(x)) ... or like this. Extra space after sizeof (bug copied from old code). % +#endif % + % + % + Extra blank lines. % #define fpclassify(x) \ % - ((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \ % - : (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \ % - : __fpclassifyl(x)) Example of normal style in old code (except for the space after sizeof(), and the backslashes aren't line up like they are in some other places in this file). % ... % @@ -119,10 +130,8 @@ % #define isunordered(x, y) (isnan(x) || isnan(y)) % #endif /* __MATH_BUILTIN_RELOPS */ % % -#define signbit(x) \ % - ((sizeof (x) == sizeof (float)) ? __signbitf(x) \ % - : (sizeof (x) == sizeof (double)) ? __signbit(x) \ % - : __signbitl(x)) % +#define signbit(x) \ % + __fp_type_select(x, __signbitf, __signbit, __signbitl) The tab lossage is especially obvious here. This macro definition fits on 1 line now. Similarly for others except __inline_isnan*, which takes 2 lines. __inline_isnan* should be named less verbosely, without __inline. I think this doesn't cause any significant conflicts with libm. Might need __always_inline. __fp_type_select is also verbose. % % typedef __double_t double_t; % typedef __float_t float_t; % @@ -175,6 +184,7 @@ % int __isfinite(double) __pure2; % int __isfinitel(long double) __pure2; % int __isinff(float) __pure2; % +int __isinf(double) __pure2; % int __isinfl(long double) __pure2; % int __isnanf(float) __pure2; % int __isnanl(long double) __pure2; % @@ -185,6 +195,23 @@ % int __signbitf(float) __pure2; % int __signbitl(long double) __pure2; The declarations of old extern functions can probably be removed too when they are replaced by inlines (only __isnan*() for now) . I think the declarations of __isnan*() are now only used to prevent warnings (at higher warning levels than have ever been used) in the file that implement the functions. % % +static __inline int % +__inline_isnanf(float __x) % +{ % + return (__x != __x); % +} % +static __inline int % +__inline_isnan(double __x) % +{ % + return (__x != __x); % +} % +static __inline int % +__inline_isnanl(long double __x) % +{ % + return (__x != __x); % +} % + % + Extra blank lines. Some insertion sort errors. In this file, APIs are mostly sorted in the order double, float, long double. All the inline functions except __inline_isnan*() only evaluate their args once, so they can be simpler shorter and less namespace-polluting as macros. catrig*.c uses the following macros for them (just showing the double precision ones here): @ #define isinf(x) (fabs(x) == INFINITY) @ #define isnan(x) ((x) != (x)) @ #define signbit(x) (__builtin_signbit(x)) Note that that these are not quite independent of the precision, so they don't all need multiple inline functions or macros. fabs() is not type-generic, but __builtin_fabs() might be. fabsl() for all precisions would work but be slower. __builtin_signbit() is even more likely to be type-generic, like __builtin_isnan(). But catrig[fl].c spell out the type suffixes for safety. I hoped to copy these to math.h after fixing any technical problems. isnan() needs a statement-expression to be safe. signbit() is more of the problem than the others, since it is hard to do without a builtin and the builtin doesn't exist in gcc-3.x. The builtin works fine with -current gcc and clang, at least on x86 . So the committed version just uses the builtin, and my local version uses libm internals that are unsuitable for the public signbit() (mainly due to namespace problems). The builtin might not work right in -curent for non-x86. When the extern function is used, it uses similar libm internals, but they take much longer when not inlined. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 18:44:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C769F961; Thu, 11 Jul 2013 18:44:33 +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 933031F02; Thu, 11 Jul 2013 18:44:33 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r6BIiW3t084706; Thu, 11 Jul 2013 12:44:32 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: hacking - aio_sendfile() From: Scott Long In-Reply-To: <20130711061753.GK91021@kib.kiev.ua> Date: Thu, 11 Jul 2013 11:44:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130711061753.GK91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 18:44:33 -0000 On Jul 10, 2013, at 11:17 PM, Konstantin Belousov = wrote: > On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: >> Hiya, >>=20 >> I've started writing an aio_sendfile() syscall. >>=20 >> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff >>=20 >> Yes, the diff is against -HEAD and not stable/9. >>=20 >> It's totally horrible, hackish and likely bad. I've only done some >> very, very basic testing to ensure it actually works; i haven't at = all >> stress tested it out yet. It's also very naive - I'm not at all doing >> any checks to see whether I can short-cut to do the aio there and >> then; I'm always queuing the sendfile() op through the worker = threads. >> That's likely stupid and inefficient in a lot of cases, but it at >> least gets the syscall up and working. > Yes, it is naive, but for different reason. >=20 > The kern_sendfile() is synchronous function, it only completes after > the other end of the network communication allows it. This means > that calling kern_sendfile() from the aio thread blocks the thread > indefinitely by unbounded sleep. No, kern_sendfile is async unless you specify the SF_SYNC hack flag. Otherwise, it'll fill the socket buffer and then return immediately, = unless the socket buffer is full and the socket is set to blocking mode. = That's outside the scope, as I said in my previous email. Scott From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 18:48:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E08C7AB6; Thu, 11 Jul 2013 18:48:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 82A1B1F33; Thu, 11 Jul 2013 18:48:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6BImZGT032221; Thu, 11 Jul 2013 21:48:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6BImZGT032221 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6BImZ74032220; Thu, 11 Jul 2013 21:48:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Jul 2013 21:48:35 +0300 From: Konstantin Belousov To: Scott Long Subject: Re: hacking - aio_sendfile() Message-ID: <20130711184835.GS91021@kib.kiev.ua> References: <20130711061753.GK91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5P5znCSOQSukcar1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 18:48:40 -0000 --5P5znCSOQSukcar1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote: >=20 > On Jul 10, 2013, at 11:17 PM, Konstantin Belousov w= rote: >=20 > > On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: > >> Hiya, > >>=20 > >> I've started writing an aio_sendfile() syscall. > >>=20 > >> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff > >>=20 > >> Yes, the diff is against -HEAD and not stable/9. > >>=20 > >> It's totally horrible, hackish and likely bad. I've only done some > >> very, very basic testing to ensure it actually works; i haven't at all > >> stress tested it out yet. It's also very naive - I'm not at all doing > >> any checks to see whether I can short-cut to do the aio there and > >> then; I'm always queuing the sendfile() op through the worker threads. > >> That's likely stupid and inefficient in a lot of cases, but it at > >> least gets the syscall up and working. > > Yes, it is naive, but for different reason. > >=20 > > The kern_sendfile() is synchronous function, it only completes after > > the other end of the network communication allows it. This means > > that calling kern_sendfile() from the aio thread blocks the thread > > indefinitely by unbounded sleep. >=20 >=20 > No, kern_sendfile is async unless you specify the SF_SYNC hack flag. > Otherwise, it'll fill the socket buffer and then return immediately, unle= ss > the socket buffer is full and the socket is set to blocking mode. That's > outside the scope, as I said in my previous email. You do not understand what I said, please re-read both my mail and code before replying. Implementing aio_sendfile() as proposed would create yet another possibility of indefinitely block all processes using aio. --5P5znCSOQSukcar1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3v4CAAoJEJDCuSvBvK1Bu7UP/1llBUEzZfnkb9CdwgTw74TB DMuWAa+d8UfqDEIVy7qfSqFwbqHmZUixnGmWc+WjHAOFeu7+rt55kb6kAZRdw16Q 5bGSkA8c7ZOApx9Gr73fIDj9pThtX0NG8QKkzMEX8hcPY0qQSIG2LbEWm5e2DXa2 2WRZh/nwVfn4NOxQo1ynaWB/XUFNyCBTeCTVKVLy4fBi+en0VduiSYLWzoysxW1u 0ojZOoI6JYT+53KctMofcwXFzKxTDnj/FWDqSh2P0DroAklwiVK/HuXG0fX0Q2ua xDyc2Jcx9K631In1BDEs9qf4k57zt/SPGkk1aNoGHPoM0g7LexT0GtwO18EN/1og Xje1wtEOVfVDjJBxZyICHiM4fV/fx/QLyKarEz/ut/tdf8QSD4bgQfRfMTYVkE5F kU3uCyoZDUxE4WOBsaSVjqAMKAMbIck4/hRpc1laMe4AvUsU8hFYMSYQ3RlOUmOd wf4uHxEIW+uuN55UCLFq1cPN5DzhHLgbOck5gqaiJQ+6F0q7a9nWc1pH9cFlWA0e Mjk/dMW+iQfXD/BgErzxD1y4z31ZqvPfiRdlhukNqkbPhz2xuLoRxxVLwJnfkEXz w11IpwnC+EdMAjuyBmHE6jz2vz3V1OdHovt0EudnSTXTrsTd81Fq9BIz+QnV0rLo XV6WmPUedN8J5XZpUsNq =15e2 -----END PGP SIGNATURE----- --5P5znCSOQSukcar1-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 19:04:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94070DDF; Thu, 11 Jul 2013 19:04:04 +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 48D991FAD; Thu, 11 Jul 2013 19:04:04 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r6BIfklB084661; Thu, 11 Jul 2013 12:41:46 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: hacking - aio_sendfile() From: Scott Long In-Reply-To: <20130711095615.GM91021@kib.kiev.ua> Date: Thu, 11 Jul 2013 11:41:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <648164F3-17CC-4629-8890-296FF3E642F8@samsco.org> References: <20130711061753.GK91021@kib.kiev.ua> <20130711093630.GL91021@kib.kiev.ua> <20130711095615.GM91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 19:04:04 -0000 On Jul 11, 2013, at 2:56 AM, Konstantin Belousov = wrote: > On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote: >> On 11 July 2013 02:36, Konstantin Belousov = wrote: >>=20 >>> No, it is not disk I/O which is problematic there. It is socket I/O >>> e.g. wait for the socket buffers lomark in the kern_sendfile() which >>> causes unbounded sleep. Look for the sbwait() call, both in the >>> kern_sendfile() itself, and in the pru_send methods of the = protocols, >>> e.g. in sosend_generic(). The wait scope controlled by the other = side of >>> connection and allow it to completely block the aio subsystem. >>>=20 >>> Disk I/O is supposed to finish in the finite time. >>=20 >> Even if the destination socket is marked as NONBLOCK? >=20 > You mean, would a sleep for the socket buffer space cause aio thread > block is the socket is put in nonblocking mode ? Or something else ? >=20 > No, it would not block the thread. But I cannot consider the > aio_sendfile(2) implementation useful if it requires non-blocking > socket. Also, what about other thread changing the socket to blocking > mode while sendfile is in flight ? Just as with other aspects of sendfile, it's up to the caller to protect = this kind of state. Objecting to aio_sendfile() simply for the reason you state = is absurd and against the design goals of sendfile. Scott From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 19:04:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82300B6; Thu, 11 Jul 2013 19:04:59 +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 31E1A1FC8; Thu, 11 Jul 2013 19:04:59 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r6BJ4vVN084841; Thu, 11 Jul 2013 13:04:58 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: hacking - aio_sendfile() From: Scott Long In-Reply-To: <20130711184835.GS91021@kib.kiev.ua> Date: Thu, 11 Jul 2013 12:04:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <292A629B-7650-4845-83A2-E2C985D9C346@samsco.org> References: <20130711061753.GK91021@kib.kiev.ua> <20130711184835.GS91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 19:04:59 -0000 On Jul 11, 2013, at 11:48 AM, Konstantin Belousov = wrote: > On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote: >>=20 >> On Jul 10, 2013, at 11:17 PM, Konstantin Belousov = wrote: >>=20 >>> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: >>>> Hiya, >>>>=20 >>>> I've started writing an aio_sendfile() syscall. >>>>=20 >>>> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff >>>>=20 >>>> Yes, the diff is against -HEAD and not stable/9. >>>>=20 >>>> It's totally horrible, hackish and likely bad. I've only done some >>>> very, very basic testing to ensure it actually works; i haven't at = all >>>> stress tested it out yet. It's also very naive - I'm not at all = doing >>>> any checks to see whether I can short-cut to do the aio there and >>>> then; I'm always queuing the sendfile() op through the worker = threads. >>>> That's likely stupid and inefficient in a lot of cases, but it at >>>> least gets the syscall up and working. >>> Yes, it is naive, but for different reason. >>>=20 >>> The kern_sendfile() is synchronous function, it only completes after >>> the other end of the network communication allows it. This means >>> that calling kern_sendfile() from the aio thread blocks the thread >>> indefinitely by unbounded sleep. >>=20 >>=20 >> No, kern_sendfile is async unless you specify the SF_SYNC hack flag. >> Otherwise, it'll fill the socket buffer and then return immediately, = unless >> the socket buffer is full and the socket is set to blocking mode. = That's >> outside the scope, as I said in my previous email. >=20 > You do not understand what I said, please re-read both my mail and = code > before replying. Implementing aio_sendfile() as proposed would create > yet another possibility of indefinitely block all processes using aio. I'm lost, maybe I missed some emails? I see a set of emails where you = incorrectly state that kern_sendfile() will always call sbwait(), and then you = backtrack on that and claim that it's unacceptable to enforce that SS_NBIO be used for aio = operations. I apologize if I'm missing something here. Scott From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 19:50:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B96E9D2B; Thu, 11 Jul 2013 19:50:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC3F1141; Thu, 11 Jul 2013 19:50:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6BJo8ps044715; Thu, 11 Jul 2013 22:50:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6BJo8ps044715 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6BJo8f2044711; Thu, 11 Jul 2013 22:50:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Jul 2013 22:50:08 +0300 From: Konstantin Belousov To: Scott Long Subject: Re: hacking - aio_sendfile() Message-ID: <20130711195008.GU91021@kib.kiev.ua> References: <20130711061753.GK91021@kib.kiev.ua> <20130711184835.GS91021@kib.kiev.ua> <292A629B-7650-4845-83A2-E2C985D9C346@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eyadjJPLjITSyz6C" Content-Disposition: inline In-Reply-To: <292A629B-7650-4845-83A2-E2C985D9C346@samsco.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 19:50:14 -0000 --eyadjJPLjITSyz6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 11, 2013 at 12:04:57PM -0700, Scott Long wrote: >=20 > On Jul 11, 2013, at 11:48 AM, Konstantin Belousov w= rote: >=20 > > On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote: > >>=20 > >> On Jul 10, 2013, at 11:17 PM, Konstantin Belousov wrote: > >>=20 > >>> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: > >>>> Hiya, > >>>>=20 > >>>> I've started writing an aio_sendfile() syscall. > >>>>=20 > >>>> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff > >>>>=20 > >>>> Yes, the diff is against -HEAD and not stable/9. > >>>>=20 > >>>> It's totally horrible, hackish and likely bad. I've only done some > >>>> very, very basic testing to ensure it actually works; i haven't at a= ll > >>>> stress tested it out yet. It's also very naive - I'm not at all doing > >>>> any checks to see whether I can short-cut to do the aio there and > >>>> then; I'm always queuing the sendfile() op through the worker thread= s. > >>>> That's likely stupid and inefficient in a lot of cases, but it at > >>>> least gets the syscall up and working. > >>> Yes, it is naive, but for different reason. > >>>=20 > >>> The kern_sendfile() is synchronous function, it only completes after > >>> the other end of the network communication allows it. This means > >>> that calling kern_sendfile() from the aio thread blocks the thread > >>> indefinitely by unbounded sleep. > >>=20 > >>=20 > >> No, kern_sendfile is async unless you specify the SF_SYNC hack flag. > >> Otherwise, it'll fill the socket buffer and then return immediately, u= nless > >> the socket buffer is full and the socket is set to blocking mode. Tha= t's > >> outside the scope, as I said in my previous email. > >=20 > > You do not understand what I said, please re-read both my mail and code > > before replying. Implementing aio_sendfile() as proposed would create > > yet another possibility of indefinitely block all processes using aio. >=20 > I'm lost, maybe I missed some emails? I see a set of emails where you in= correctly > state that kern_sendfile() will always call sbwait(), and then you backtr= ack on that > and claim that it's unacceptable to enforce that SS_NBIO be used for aio = operations. > I apologize if I'm missing something here. Can you cite my exact text where I claimed that kern_sendfile() always calls sbwait ? I wrote about this explicitely, stating that it is very easy to make kern_sendfile() sleep for the socket buffer space, and the duration of the sleep is user-controllable. As result, it allows to hang all processes doing aio calls, since aio thread pool is finite. I am sorry for retyping this and stealing your time by repeating. Making the kern_sendfile() to behave from the aio context as if the SS_NBIO was set on the socket contradicts the behaviour of other aio operations. E.g. aio_read and aio_write do not perform short reads and writes to not block the aio daemon threads (which is the cause of buggy behaviour of existing aio syscalls on sockets). More, I do not think that setting SS_NBIO is enough to prevent the blocking of aio threads in kern_sendfile(). The send socket buffer is locked exclusively by kern_sendfile(). Other thread which entered sendfile(2) and was deliberately put to sleep on the low watermark, still owns the so_snd sx. This means that aio threads trying to do kern_sendfile() on this socket would be also blocked, for duration controlled by other end. That said, even assuming SS_NBIO is always enforced and other sleep points are identified and worked around, the only benefit of such implementation comparing with the direct sendfile(2) call would be preventing the use of the calling thread context for disk i/o. FreeBSD recently gained aio_mlock(2) which allows to get the same result in non-hackish way. --eyadjJPLjITSyz6C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3wxvAAoJEJDCuSvBvK1BRaUP/Rcn/GYBzl0LPFiM21JxC4Fg Yy9as3pbFc2YycwBXboCYMVZh7zZzRdAkT2yHkc9fifZG+vkvmGMtw9uQXlUaEEq 5A4fUz7PY7WNusJM/GLZOR0dGiOWh+63XMzZ6zqTGi/89GyEU4gscvJs3SZZvpAS dMGKP5LXZyCz8xiRrbOJOvj0VdpQNs4L2+nxyhr1lirQKNhU9+t5/GThPAK0WwQQ oCQgAkBfOLD0SEgU2A+ca3oSlZ3pT6sKVolVSNnOtuRuUsrF5nU3jGrH5cs+Vqi+ E8ncvCvXTklGEfnY1Fk0M6xHZmSGigPZZsSNY3dKc/muFiT5O9h78P01Dr7WAwnl mQ8AQAqNdyTij+d+kjN3Sitkqa0cdOQUvent4E7YIM/ljafEvvsJEVgjFA6SLXI7 eUCVzyfaWT1xth1ozh556lpDLdcE7gltCsfVZvjuy2ZTwmWV/jNEzQIxaDRH/flC 13VA7vghAcHQDJWAP+UAJSY595Tw2ljYMkG92E6EoEiKT4z4KqKg/HT0m5XKs8s7 jSjRaG+XAZWyrDMNgzeGvNOVQ+cmLXkH42WSIwZozliYBkjRmcPk8m3HomvnEzRR G+KwdW21tS/oMYIeQNGOkZBIGzPbJEAP5QutnCfe8vwBETIiCSTaaKnwzuMfDvIr iI+zCIrCWLU+dO1rcZrp =jP1Y -----END PGP SIGNATURE----- --eyadjJPLjITSyz6C-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 22:33:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9180168; Thu, 11 Jul 2013 22:33: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 9EF9F1ADD; Thu, 11 Jul 2013 22:33:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6BMXDek029295; Thu, 11 Jul 2013 18:33:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6BMXDAT029283; Thu, 11 Jul 2013 22:33:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Jul 2013 22:33:13 GMT Message-Id: <201307112233.r6BMXDAT029283@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:33:19 -0000 TB --- 2013-07-11 17:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 17:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 17:00:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-11 17:00:18 - cleaning the object tree TB --- 2013-07-11 17:00:18 - /usr/local/bin/svn stat /src TB --- 2013-07-11 17:00:23 - At svn revision 253214 TB --- 2013-07-11 17:00:24 - building world TB --- 2013-07-11 17:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 17:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 17:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 17:00:24 - SRCCONF=/dev/null TB --- 2013-07-11 17:00:24 - TARGET=i386 TB --- 2013-07-11 17:00:24 - TARGET_ARCH=i386 TB --- 2013-07-11 17:00:24 - TZ=UTC TB --- 2013-07-11 17:00:24 - __MAKE_CONF=/dev/null TB --- 2013-07-11 17:00:24 - cd /src TB --- 2013-07-11 17:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 11 17:00:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 11 20:12:25 UTC 2013 TB --- 2013-07-11 20:12:25 - generating LINT kernel config TB --- 2013-07-11 20:12:25 - cd /src/sys/i386/conf TB --- 2013-07-11 20:12:25 - /usr/bin/make -B LINT TB --- 2013-07-11 20:12:25 - cd /src/sys/i386/conf TB --- 2013-07-11 20:12:25 - /usr/sbin/config -m LINT TB --- 2013-07-11 20:12:25 - building LINT kernel TB --- 2013-07-11 20:12:25 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 20:12:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 20:12:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 20:12:25 - SRCCONF=/dev/null TB --- 2013-07-11 20:12:25 - TARGET=i386 TB --- 2013-07-11 20:12:25 - TARGET_ARCH=i386 TB --- 2013-07-11 20:12:25 - TZ=UTC TB --- 2013-07-11 20:12:25 - __MAKE_CONF=/dev/null TB --- 2013-07-11 20:12:25 - cd /src TB --- 2013-07-11 20:12:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 11 20:12:25 UTC 2013 >>> 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 completed on Thu Jul 11 20:46:43 UTC 2013 TB --- 2013-07-11 20:46:43 - cd /src/sys/i386/conf TB --- 2013-07-11 20:46:43 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-11 20:46:43 - building LINT-NOINET kernel TB --- 2013-07-11 20:46:43 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 20:46:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 20:46:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 20:46:43 - SRCCONF=/dev/null TB --- 2013-07-11 20:46:43 - TARGET=i386 TB --- 2013-07-11 20:46:43 - TARGET_ARCH=i386 TB --- 2013-07-11 20:46:43 - TZ=UTC TB --- 2013-07-11 20:46:43 - __MAKE_CONF=/dev/null TB --- 2013-07-11 20:46:43 - cd /src TB --- 2013-07-11 20:46:43 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Jul 11 20:46:43 UTC 2013 >>> 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 Jul 11 21:17:55 UTC 2013 TB --- 2013-07-11 21:17:55 - cd /src/sys/i386/conf TB --- 2013-07-11 21:17:55 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-11 21:17:55 - building LINT-NOINET6 kernel TB --- 2013-07-11 21:17:55 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:17:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:17:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:17:55 - SRCCONF=/dev/null TB --- 2013-07-11 21:17:55 - TARGET=i386 TB --- 2013-07-11 21:17:55 - TARGET_ARCH=i386 TB --- 2013-07-11 21:17:55 - TZ=UTC TB --- 2013-07-11 21:17:55 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:17:55 - cd /src TB --- 2013-07-11 21:17:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Jul 11 21:17:55 UTC 2013 >>> 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 Jul 11 21:49:28 UTC 2013 TB --- 2013-07-11 21:49:28 - cd /src/sys/i386/conf TB --- 2013-07-11 21:49:28 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-11 21:49:28 - building LINT-NOIP kernel TB --- 2013-07-11 21:49:28 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:49:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:49:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:49:28 - SRCCONF=/dev/null TB --- 2013-07-11 21:49:28 - TARGET=i386 TB --- 2013-07-11 21:49:28 - TARGET_ARCH=i386 TB --- 2013-07-11 21:49:28 - TZ=UTC TB --- 2013-07-11 21:49:28 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:49:28 - cd /src TB --- 2013-07-11 21:49:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Jul 11 21:49:28 UTC 2013 >>> 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 Jul 11 22:17:57 UTC 2013 TB --- 2013-07-11 22:17:57 - cd /src/sys/i386/conf TB --- 2013-07-11 22:17:57 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-07-11 22:17:57 - building LINT-VIMAGE kernel TB --- 2013-07-11 22:17:57 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 22:17:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 22:17:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 22:17:57 - SRCCONF=/dev/null TB --- 2013-07-11 22:17:57 - TARGET=i386 TB --- 2013-07-11 22:17:57 - TARGET_ARCH=i386 TB --- 2013-07-11 22:17:57 - TZ=UTC TB --- 2013-07-11 22:17:57 - __MAKE_CONF=/dev/null TB --- 2013-07-11 22:17:57 - cd /src TB --- 2013-07-11 22:17:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Jul 11 22:17:57 UTC 2013 >>> 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/net/vnet.h:217:20: note: expanded from macro 'CURVNET_SET_VERBOSE' CURVNET_SET_QUIET(arg) ^ /src/sys/net/vnet.h:214:12: note: expanded from macro 'CURVNET_SET_QUIET' curvnet = arg; ^ 5 errors generated. *** Error code 1 Stop. make: stopped in /obj/i386.i386/src/sys/LINT-VIMAGE *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-11 22:33:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-11 22:33:13 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-07-11 22:33:13 - 15782.62 user 2950.52 system 19974.57 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 23:02:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA92466D; Thu, 11 Jul 2013 23:02: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 8CC501C9D; Thu, 11 Jul 2013 23:02:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6BN2lcC090235; Thu, 11 Jul 2013 19:02:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6BN2lLf090233; Thu, 11 Jul 2013 23:02:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Jul 2013 23:02:47 GMT Message-Id: <201307112302.r6BN2lLf090233@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:02:48 -0000 TB --- 2013-07-11 17:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 17:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 17:00:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-11 17:00:18 - cleaning the object tree TB --- 2013-07-11 17:00:18 - /usr/local/bin/svn stat /src TB --- 2013-07-11 17:00:23 - At svn revision 253214 TB --- 2013-07-11 17:00:24 - building world TB --- 2013-07-11 17:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 17:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 17:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 17:00:24 - SRCCONF=/dev/null TB --- 2013-07-11 17:00:24 - TARGET=amd64 TB --- 2013-07-11 17:00:24 - TARGET_ARCH=amd64 TB --- 2013-07-11 17:00:24 - TZ=UTC TB --- 2013-07-11 17:00:24 - __MAKE_CONF=/dev/null TB --- 2013-07-11 17:00:24 - cd /src TB --- 2013-07-11 17:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 11 17:00:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jul 11 20:48:41 UTC 2013 TB --- 2013-07-11 20:48:41 - generating LINT kernel config TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf TB --- 2013-07-11 20:48:41 - /usr/bin/make -B LINT TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf TB --- 2013-07-11 20:48:41 - /usr/sbin/config -m LINT TB --- 2013-07-11 20:48:41 - building LINT kernel TB --- 2013-07-11 20:48:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 20:48:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 20:48:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 20:48:41 - SRCCONF=/dev/null TB --- 2013-07-11 20:48:41 - TARGET=amd64 TB --- 2013-07-11 20:48:41 - TARGET_ARCH=amd64 TB --- 2013-07-11 20:48:41 - TZ=UTC TB --- 2013-07-11 20:48:41 - __MAKE_CONF=/dev/null TB --- 2013-07-11 20:48:41 - cd /src TB --- 2013-07-11 20:48:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 11 20:48:41 UTC 2013 >>> 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 completed on Thu Jul 11 21:20:29 UTC 2013 TB --- 2013-07-11 21:20:29 - cd /src/sys/amd64/conf TB --- 2013-07-11 21:20:29 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-11 21:20:29 - building LINT-NOINET kernel TB --- 2013-07-11 21:20:29 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:20:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:20:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:20:29 - SRCCONF=/dev/null TB --- 2013-07-11 21:20:29 - TARGET=amd64 TB --- 2013-07-11 21:20:29 - TARGET_ARCH=amd64 TB --- 2013-07-11 21:20:29 - TZ=UTC TB --- 2013-07-11 21:20:29 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:20:29 - cd /src TB --- 2013-07-11 21:20:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Jul 11 21:20:30 UTC 2013 >>> 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 Jul 11 21:50:20 UTC 2013 TB --- 2013-07-11 21:50:20 - cd /src/sys/amd64/conf TB --- 2013-07-11 21:50:20 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-11 21:50:20 - building LINT-NOINET6 kernel TB --- 2013-07-11 21:50:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:50:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:50:20 - SRCCONF=/dev/null TB --- 2013-07-11 21:50:20 - TARGET=amd64 TB --- 2013-07-11 21:50:20 - TARGET_ARCH=amd64 TB --- 2013-07-11 21:50:20 - TZ=UTC TB --- 2013-07-11 21:50:20 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:50:20 - cd /src TB --- 2013-07-11 21:50:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Jul 11 21:50:20 UTC 2013 >>> 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 Jul 11 22:20:11 UTC 2013 TB --- 2013-07-11 22:20:11 - cd /src/sys/amd64/conf TB --- 2013-07-11 22:20:11 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-11 22:20:11 - building LINT-NOIP kernel TB --- 2013-07-11 22:20:11 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 22:20:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 22:20:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 22:20:11 - SRCCONF=/dev/null TB --- 2013-07-11 22:20:11 - TARGET=amd64 TB --- 2013-07-11 22:20:11 - TARGET_ARCH=amd64 TB --- 2013-07-11 22:20:11 - TZ=UTC TB --- 2013-07-11 22:20:11 - __MAKE_CONF=/dev/null TB --- 2013-07-11 22:20:11 - cd /src TB --- 2013-07-11 22:20:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Jul 11 22:20:11 UTC 2013 >>> 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 Jul 11 22:47:36 UTC 2013 TB --- 2013-07-11 22:47:36 - cd /src/sys/amd64/conf TB --- 2013-07-11 22:47:36 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-07-11 22:47:36 - building LINT-VIMAGE kernel TB --- 2013-07-11 22:47:36 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 22:47:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 22:47:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 22:47:36 - SRCCONF=/dev/null TB --- 2013-07-11 22:47:36 - TARGET=amd64 TB --- 2013-07-11 22:47:36 - TARGET_ARCH=amd64 TB --- 2013-07-11 22:47:36 - TZ=UTC TB --- 2013-07-11 22:47:36 - __MAKE_CONF=/dev/null TB --- 2013-07-11 22:47:36 - cd /src TB --- 2013-07-11 22:47:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Jul 11 22:47:36 UTC 2013 >>> 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/net/vnet.h:217:20: note: expanded from macro 'CURVNET_SET_VERBOSE' CURVNET_SET_QUIET(arg) ^ /src/sys/net/vnet.h:214:12: note: expanded from macro 'CURVNET_SET_QUIET' curvnet = arg; ^ 5 errors generated. *** Error code 1 Stop. make: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-11 23:02:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-11 23:02:47 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-07-11 23:02:47 - 17093.32 user 3202.59 system 21748.86 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 23:30:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A0CAB7D; Thu, 11 Jul 2013 23:30:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BF79F1D86; Thu, 11 Jul 2013 23:30:52 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=u+Bwc9JL7tMNtl/i9xObSTPSFclN5AOtXcIZY5dPsHA= c=1 sm=2 a=2CN1efILQXEA:10 a=FKkrIqjQGGEA:10 a=l0nrKk16v60A:10 a=IkcTkHD0fZMA:10 a=6I5d2MoRAAAA:8 a=tG8P3wK5P364QUJtx80A:9 a=QEXdDO2ut3YA:10 a=SV7veod9ZcQA:10 a=HCYscHdTzkEnlTMq:21 a=Hg57A2LVB9d5kEav:21 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAIs/31GDaFve/2dsb2JhbABaFoMkT4MGvlCBHXSCIwEBAQMBAQEBICsgCxsYAgINGQIpAQkmBggHBAEcAQOHaAYMpiaRO4Emi2qBDxB+NAeCVoEfA5UVg3GIeYcrgViBVSAygQM3 X-IronPort-AV: E=Sophos;i="4.89,648,1367985600"; d="scan'208";a="40006670" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 11 Jul 2013 19:30:45 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 51E5F79204; Thu, 11 Jul 2013 19:30:45 -0400 (EDT) Date: Thu, 11 Jul 2013 19:30:45 -0400 (EDT) From: Rick Macklem To: Bryan Drewery Message-ID: <672055679.467398.1373585445319.JavaMail.root@uoguelph.ca> In-Reply-To: <51DD3C1F.1000609@shatow.net> Subject: Re: NFS panic: newnfs_copycred: negative nfsc_ngroups (client HEAD r253033, server 9.1-R) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-fs@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jul 2013 23:30:53 -0000 Bryan Drewery wrote: > I received this panic on the client while doing heavy parallel > reads/writes over NFS. I only recently moved these files to NFS, so I > don't know whether or not it's a recent regression. > > Client: HEAD r253033 > Server: 9.1-R > > core.txt: http://people.freebsd.org/~bdrewery/nfs.txt > > fstab of related paths: > > > tank:/tank/distfiles/freebsd /mnt/distfiles > > nfs > > rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv4 > > 0 0 > > tank:/usr/packages/ > > /mnt/all-packages nfs > > rw,bg,noatime,soft,retrycnt=3,rsize=65536,wsize=65536,readahead=8,nfsv4 > > 0 0 The mount options "soft" and "intr" should never be used for NFSv4. If an RPC fails with ETIMEDOUT or EINTR it can leave the open state in an undefined state. If you still get one of these crashes with all hard mounts, email again, since that would imply a client bug. (This is documented in the BUGS sections of mount_nfs(1), but not very well.;-) I'm not sure if this undefined open state could cause the crash, but it seems plausible, since the crash indicates garbage for the credentials in the open state structure. rick > > Server: params on these paths: -maproot=root -network 10.10.0.0/16 > > tcpdump at the time: > > > 21:43:05.396585 IP 10.10.0.7.4180315003 > 10.10.0.5.2049: 168 > > getattr fh 0,4/2 > > 21:43:05.396589 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48265029:48266477, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396603 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48266477:48267925, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396605 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack > > 48266477, win 3916, options [nop,nop,TS val 596674 ecr > > 1950216660], length 0 > > 21:43:05.396608 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48267925:48269373, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396621 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48269373:48270821, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396624 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack > > 48269373, win 3870, options [nop,nop,TS val 596674 ecr > > 1950216660], length 0 > > 21:43:05.396641 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48270821:48272269, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396653 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48272269:48273717, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396656 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack > > 48272269, win 3825, options [nop,nop,TS val 596674 ecr > > 1950216660], length 0 > > 21:43:05.396659 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48273717:48275165, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396671 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48275165:48276613, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396674 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack > > 48275165, win 3780, options [nop,nop,TS val 596674 ecr > > 1950216660], length 0 > > 21:43:05.396676 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48276613:48278061, ack 4394885, win 29124, options [nop,nop,TS val > > 1950216660 ecr 596674], length 1448 > > 21:43:05.396689 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > > 48278061:48279509, ack 4394885, win 29124, options [nop,nop,TS val > > Write failed: Broken pipe > > I have nfsuserd running on both client/server. nfscbd is running. > nfs_client_enable=yes in rc.conf. > > User lookups seem to work fine: > > > -rw-r--r-- 1 root bryan 1554804 Jul 6 10:50 > > /mnt/distfiles/pkg-1.1.4.tar.xz > > I ran a find -ls on these paths and all files return a user/group. I > am > guessing there is a race condition with files being written and > looking > up the associated groups. > > -- > Regards, > Bryan Drewery > bdrewery@freenode/EFNet > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 02:04:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6ACCED25; Fri, 12 Jul 2013 02:04:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4C111EC; Fri, 12 Jul 2013 02:04:28 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6C24QgH053166; Fri, 12 Jul 2013 02:04:27 GMT (envelope-from davidxu@freebsd.org) Message-ID: <51DF6450.7050204@freebsd.org> Date: Fri, 12 Jul 2013 10:05:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130416 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: hacking - aio_sendfile() References: <20130711061753.GK91021@kib.kiev.ua> In-Reply-To: <20130711061753.GK91021@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 02:04:28 -0000 On 2013/07/11 14:17, Konstantin Belousov wrote: > On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: >> Hiya, >> >> I've started writing an aio_sendfile() syscall. >> >> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff >> >> Yes, the diff is against -HEAD and not stable/9. >> >> It's totally horrible, hackish and likely bad. I've only done some >> very, very basic testing to ensure it actually works; i haven't at all >> stress tested it out yet. It's also very naive - I'm not at all doing >> any checks to see whether I can short-cut to do the aio there and >> then; I'm always queuing the sendfile() op through the worker threads. >> That's likely stupid and inefficient in a lot of cases, but it at >> least gets the syscall up and working. > Yes, it is naive, but for different reason. > > The kern_sendfile() is synchronous function, it only completes after > the other end of the network communication allows it. This means > that calling kern_sendfile() from the aio thread blocks the thread > indefinitely by unbounded sleep. > > Your implementation easily causes exhaustion of the aio thread pool, > blocking the whole aio subsystem. It is known that our aio does not work > for sockets for the same reason. I object against adding more code with > the same defect. > > Proper route seems to rewrite aio for sockets using the upcalls. The same > should be done for sendfile, if sendfile is given aio flavor. > Yes, current aio implementation is horrible, it only works for fast disk I/O, I think the thread pool size is enough to saturate disks, but for socket or pipe I/O, it does not work well, the thread pool is too easy to be exhausted. I even think the support for socket and pipe in aio code should be cut and thrown away, because you can always use kqueue + non-blocking I/O. From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 02:15:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 29B3CFD7; Fri, 12 Jul 2013 02:15:59 +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 F2FE9123A; Fri, 12 Jul 2013 02:15:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C2FvBo082448; Thu, 11 Jul 2013 22:15:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C2Fv6L082447; Fri, 12 Jul 2013 02:15:57 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 02:15:57 GMT Message-Id: <201307120215.r6C2Fv6L082447@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 02:15:59 -0000 TB --- 2013-07-12 01:00:05 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 01:00:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 01:00:05 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-12 01:00:05 - cleaning the object tree TB --- 2013-07-12 01:01:29 - /usr/local/bin/svn stat /src TB --- 2013-07-12 01:01:32 - At svn revision 253214 TB --- 2013-07-12 01:01:33 - building world TB --- 2013-07-12 01:01:33 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 01:01:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 01:01:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 01:01:33 - SRCCONF=/dev/null TB --- 2013-07-12 01:01:33 - TARGET=sparc64 TB --- 2013-07-12 01:01:33 - TARGET_ARCH=sparc64 TB --- 2013-07-12 01:01:33 - TZ=UTC TB --- 2013-07-12 01:01:33 - __MAKE_CONF=/dev/null TB --- 2013-07-12 01:01:33 - cd /src TB --- 2013-07-12 01:01:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 01:01:40 UTC 2013 >>> 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 Jul 12 02:05:13 UTC 2013 TB --- 2013-07-12 02:05:13 - generating LINT kernel config TB --- 2013-07-12 02:05:13 - cd /src/sys/sparc64/conf TB --- 2013-07-12 02:05:13 - /usr/bin/make -B LINT TB --- 2013-07-12 02:05:13 - cd /src/sys/sparc64/conf TB --- 2013-07-12 02:05:13 - /usr/sbin/config -m LINT TB --- 2013-07-12 02:05:13 - building LINT kernel TB --- 2013-07-12 02:05:13 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 02:05:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 02:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 02:05:13 - SRCCONF=/dev/null TB --- 2013-07-12 02:05:13 - TARGET=sparc64 TB --- 2013-07-12 02:05:13 - TARGET_ARCH=sparc64 TB --- 2013-07-12 02:05:13 - TZ=UTC TB --- 2013-07-12 02:05:13 - __MAKE_CONF=/dev/null TB --- 2013-07-12 02:05:13 - cd /src TB --- 2013-07-12 02:05:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 12 02:05:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 02:15:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 02:15:57 - ERROR: failed to build LINT kernel TB --- 2013-07-12 02:15:57 - 3751.41 user 630.89 system 4552.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 04:58:06 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AEA41665; Fri, 12 Jul 2013 04:58:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id BF80E1974; Fri, 12 Jul 2013 04:58:05 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C4vhGp070377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 13:57:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C4vfOc051570; Fri, 12 Jul 2013 13:57:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 12 Jul 2013 13:56:21 +0900 (JST) Message-Id: <20130712.135621.1408565802386368060.hrs@allbsd.org> To: rkoberman@gmail.com, feld@feld.me, trashcan@odo.in-berlin.de Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jul_12_13_56_21_2013_046)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 12 Jul 2013 13:57:55 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 04:58:06 -0000 ----Security_Multipart(Fri_Jul_12_13_56_21_2013_046)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kevin Oberman wrote in : rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: rk> rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < rk> > trashcan@odo.in-berlin.de> wrote: rk> > rk> > Will that patch make it into 9.2? If I am not mistaken, that patch isn't rk> >> in stable yet. rk> >> rk> > rk> > I would also like to see this patch hit 9.x sooner than later. It's so rk> > painful when someone forgets to fix the alias numbering on servers with rk> > many, many IPv4 and IPv6 addresses... rk> > rk> rk> Please, please, please, please, ...! rk> rk> Freeze is only two days away, so time for 9.2 is almost over and I can see rk> no good reason NOT to get this done. r252015 was merged to stable/9 today. -- Hiroki ----Security_Multipart(Fri_Jul_12_13_56_21_2013_046)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHfjHUACgkQTyzT2CeTzy0thACdE+jtHh/MenoksycA1kaOIono Y8EAoLpJ37td0h3pQSB1ugZNDBB9conv =AdW8 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jul_12_13_56_21_2013_046)---- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 05:14:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4DAE39FB; Fri, 12 Jul 2013 05:14:26 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id F372619EE; Fri, 12 Jul 2013 05:14:25 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id k7so12519852oag.9 for ; Thu, 11 Jul 2013 22:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=roqFDgiQGc+Ag6fy7hlhkT3YyEXlPRH8+lx/iEYLSiY=; b=x7Eq2+iAePYypAqqXWrvTIr6y9nVs4R1+V2ThAdtDwmz1Yt5W1n/3d8if/W/fEz6nF LHfbYYY8rcP7ApFk+b3MLk7COckxB58isp2xUc26HQrtGksCvspRSpwhcs43JeBi8a/u CVzw+pYnBdbopxq4kfFaXeb1mVAQVS51T8bZip2QN5EN/OtapnOZmcPb1WgLtyr/t8ns 5AReMqNIKezG3GS7dSafgkLxbTbu+0KXoNZETqO1VGBtz/zFtOpn1PDCOMjzR+ZMXCiA 3JNWnhMEHpIrTrZ6IW38gHMnXcbaWQmrMSGUzpRz9tlNJE/xCKVNvIjp3DTnPQprbLSW c32A== MIME-Version: 1.0 X-Received: by 10.60.52.165 with SMTP id u5mr34180680oeo.15.1373606065538; Thu, 11 Jul 2013 22:14:25 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Thu, 11 Jul 2013 22:14:25 -0700 (PDT) In-Reply-To: <20130712.135621.1408565802386368060.hrs@allbsd.org> References: <20130712.135621.1408565802386368060.hrs@allbsd.org> Date: Thu, 11 Jul 2013 22:14:25 -0700 X-Google-Sender-Auth: FjS5GM5xIioW26jaY-2H8BAJUZ4 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kevin Oberman To: Hiroki Sato Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , "freebsd-stable@freebsd.org Stable" , Michael Grimm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 05:14:26 -0000 On Thu, Jul 11, 2013 at 9:56 PM, Hiroki Sato wrote: > Kevin Oberman wrote > in : > > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > rk> > rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < > rk> > trashcan@odo.in-berlin.de> wrote: > rk> > > rk> > Will that patch make it into 9.2? If I am not mistaken, that patch > isn't > rk> >> in stable yet. > rk> >> > rk> > > rk> > I would also like to see this patch hit 9.x sooner than later. It's > so > rk> > painful when someone forgets to fix the alias numbering on servers > with > rk> > many, many IPv4 and IPv6 addresses... > rk> > > rk> > rk> Please, please, please, please, ...! > rk> > rk> Freeze is only two days away, so time for 9.2 is almost over and I can > see > rk> no good reason NOT to get this done. > > r252015 was merged to stable/9 today. > > -- Hiroki > Just under the wire! I'm sure that I am not the only one who appreciates it. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 05:40:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 22D87F46; Fri, 12 Jul 2013 05:40: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 C9CCC1AC1; Fri, 12 Jul 2013 05:40:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C5eG0U009825; Fri, 12 Jul 2013 01:40:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C5eF4E009818; Fri, 12 Jul 2013 05:40:15 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 05:40:15 GMT Message-Id: <201307120540.r6C5eF4E009818@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:40:17 -0000 TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:10:23 - At svn revision 253248 TB --- 2013-07-12 04:10:24 - building world TB --- 2013-07-12 04:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:10:24 - SRCCONF=/dev/null TB --- 2013-07-12 04:10:24 - TARGET=arm TB --- 2013-07-12 04:10:24 - TARGET_ARCH=arm TB --- 2013-07-12 04:10:24 - TZ=UTC TB --- 2013-07-12 04:10:24 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:10:24 - cd /src TB --- 2013-07-12 04:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 04:10:32 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/arm.arm/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/arm.arm/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:40:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:40:15 - ERROR: failed to build world TB --- 2013-07-12 05:40:15 - 4327.65 user 679.95 system 5396.15 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 05:40:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9EA2F47; Fri, 12 Jul 2013 05:40: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 8E5251AC3; Fri, 12 Jul 2013 05:40:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C5eHSx009890; Fri, 12 Jul 2013 01:40:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C5eH0n009888; Fri, 12 Jul 2013 05:40:17 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 05:40:17 GMT Message-Id: <201307120540.r6C5eH0n009888@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:40:17 -0000 TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:10:23 - At svn revision 253248 TB --- 2013-07-12 04:10:24 - building world TB --- 2013-07-12 04:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:10:24 - SRCCONF=/dev/null TB --- 2013-07-12 04:10:24 - TARGET=arm TB --- 2013-07-12 04:10:24 - TARGET_ARCH=armv6 TB --- 2013-07-12 04:10:24 - TZ=UTC TB --- 2013-07-12 04:10:24 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:10:24 - cd /src TB --- 2013-07-12 04:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 04:10:33 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/arm.armv6/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/arm.armv6/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:40:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:40:17 - ERROR: failed to build world TB --- 2013-07-12 05:40:17 - 4330.73 user 682.20 system 5397.30 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 05:45:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2D376339; Fri, 12 Jul 2013 05:45: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 D30CD1AFA; Fri, 12 Jul 2013 05:45:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C5j2AU045642; Fri, 12 Jul 2013 01:45:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C5j2o4045641; Fri, 12 Jul 2013 05:45:02 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 05:45:02 GMT Message-Id: <201307120545.r6C5j2o4045641@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:45:03 -0000 TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:18:19 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:18:22 - At svn revision 253248 TB --- 2013-07-12 04:18:23 - building world TB --- 2013-07-12 04:18:23 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:18:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:18:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:18:23 - SRCCONF=/dev/null TB --- 2013-07-12 04:18:23 - TARGET=i386 TB --- 2013-07-12 04:18:23 - TARGET_ARCH=i386 TB --- 2013-07-12 04:18:23 - TZ=UTC TB --- 2013-07-12 04:18:23 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:18:23 - cd /src TB --- 2013-07-12 04:18:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 04:18:30 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/i386.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/i386.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:45:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:45:02 - ERROR: failed to build world TB --- 2013-07-12 05:45:02 - 4337.52 user 685.93 system 5682.32 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 05:45:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D598C5A2; Fri, 12 Jul 2013 05:45: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 8934F1B1A; Fri, 12 Jul 2013 05:45:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C5jbWc048902; Fri, 12 Jul 2013 01:45:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C5jbO8048897; Fri, 12 Jul 2013 05:45:37 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 05:45:37 GMT Message-Id: <201307120545.r6C5jbO8048897@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:45:37 -0000 TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:18:47 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:18:50 - At svn revision 253248 TB --- 2013-07-12 04:18:51 - building world TB --- 2013-07-12 04:18:51 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:18:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:18:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:18:51 - SRCCONF=/dev/null TB --- 2013-07-12 04:18:51 - TARGET=amd64 TB --- 2013-07-12 04:18:51 - TARGET_ARCH=amd64 TB --- 2013-07-12 04:18:51 - TZ=UTC TB --- 2013-07-12 04:18:51 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:18:51 - cd /src TB --- 2013-07-12 04:18:51 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 04:18:58 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:45:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:45:37 - ERROR: failed to build world TB --- 2013-07-12 05:45:37 - 4353.59 user 679.80 system 5717.27 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 06:07:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2ECDE7D; Fri, 12 Jul 2013 06:07:51 +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 A08BD1BFC; Fri, 12 Jul 2013 06:07:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C67oNN013212; Fri, 12 Jul 2013 02:07:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C67oBn013199; Fri, 12 Jul 2013 06:07:50 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 06:07:50 GMT Message-Id: <201307120607.r6C67oBn013199@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 , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:07:52 -0000 TB --- 2013-07-12 05:45:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 05:45:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 05:45:02 - starting HEAD tinderbox run for mips/mips TB --- 2013-07-12 05:45:02 - cleaning the object tree TB --- 2013-07-12 05:45:02 - /usr/local/bin/svn stat /src TB --- 2013-07-12 05:45:05 - At svn revision 253248 TB --- 2013-07-12 05:45:06 - building world TB --- 2013-07-12 05:45:06 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 05:45:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 05:45:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 05:45:06 - SRCCONF=/dev/null TB --- 2013-07-12 05:45:06 - TARGET=mips TB --- 2013-07-12 05:45:06 - TARGET_ARCH=mips TB --- 2013-07-12 05:45:06 - TZ=UTC TB --- 2013-07-12 05:45:06 - __MAKE_CONF=/dev/null TB --- 2013-07-12 05:45:06 - cd /src TB --- 2013-07-12 05:45:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 05:45:13 UTC 2013 >>> 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 [...] /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 06:07:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 06:07:50 - ERROR: failed to build world TB --- 2013-07-12 06:07:50 - 1024.16 user 230.43 system 1368.47 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 06:08:29 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94C7EFB4; Fri, 12 Jul 2013 06:08:29 +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 51A561C12; Fri, 12 Jul 2013 06:08:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C68PdY015167; Fri, 12 Jul 2013 02:08:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C68Pnw015166; Fri, 12 Jul 2013 06:08:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 06:08:25 GMT Message-Id: <201307120608.r6C68Pnw015166@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 , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:08:29 -0000 TB --- 2013-07-12 05:45:37 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 05:45:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 05:45:37 - starting HEAD tinderbox run for mips64/mips TB --- 2013-07-12 05:45:37 - cleaning the object tree TB --- 2013-07-12 05:45:37 - /usr/local/bin/svn stat /src TB --- 2013-07-12 05:45:40 - At svn revision 253248 TB --- 2013-07-12 05:45:41 - building world TB --- 2013-07-12 05:45:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 05:45:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 05:45:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 05:45:41 - SRCCONF=/dev/null TB --- 2013-07-12 05:45:41 - TARGET=mips TB --- 2013-07-12 05:45:41 - TARGET_ARCH=mips64 TB --- 2013-07-12 05:45:41 - TZ=UTC TB --- 2013-07-12 05:45:41 - __MAKE_CONF=/dev/null TB --- 2013-07-12 05:45:41 - cd /src TB --- 2013-07-12 05:45:41 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 05:45:48 UTC 2013 >>> 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 [...] /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 06:08:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 06:08:25 - ERROR: failed to build world TB --- 2013-07-12 06:08:25 - 1021.77 user 229.49 system 1368.24 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 06:09:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 469BC158; Fri, 12 Jul 2013 06:09:26 +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 0474D1C25; Fri, 12 Jul 2013 06:09:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C69PHl017574; Fri, 12 Jul 2013 02:09:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C69PpQ017573; Fri, 12 Jul 2013 06:09:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 06:09:25 GMT Message-Id: <201307120609.r6C69PpQ017573@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:09:26 -0000 TB --- 2013-07-12 05:40:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 05:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 05:40:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-07-12 05:40:17 - cleaning the object tree TB --- 2013-07-12 05:40:17 - /usr/local/bin/svn stat /src TB --- 2013-07-12 05:40:20 - At svn revision 253248 TB --- 2013-07-12 05:40:21 - building world TB --- 2013-07-12 05:40:21 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 05:40:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 05:40:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 05:40:21 - SRCCONF=/dev/null TB --- 2013-07-12 05:40:21 - TARGET=ia64 TB --- 2013-07-12 05:40:21 - TARGET_ARCH=ia64 TB --- 2013-07-12 05:40:21 - TZ=UTC TB --- 2013-07-12 05:40:21 - __MAKE_CONF=/dev/null TB --- 2013-07-12 05:40:21 - cd /src TB --- 2013-07-12 05:40:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 05:40:28 UTC 2013 >>> 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 [...] /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 06:09:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 06:09:25 - ERROR: failed to build world TB --- 2013-07-12 06:09:25 - 1368.02 user 271.21 system 1747.77 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 06:34:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8273C75C; Fri, 12 Jul 2013 06:34:43 +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 3FCA41D00; Fri, 12 Jul 2013 06:34:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C6Ygj0090328; Fri, 12 Jul 2013 02:34:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C6YgnD090321; Fri, 12 Jul 2013 06:34:42 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 06:34:42 GMT Message-Id: <201307120634.r6C6YgnD090321@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:34:43 -0000 TB --- 2013-07-12 06:09:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 06:09:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 06:09:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-12 06:09:25 - cleaning the object tree TB --- 2013-07-12 06:10:04 - /usr/local/bin/svn stat /src TB --- 2013-07-12 06:10:08 - At svn revision 253248 TB --- 2013-07-12 06:10:09 - building world TB --- 2013-07-12 06:10:09 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 06:10:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 06:10:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 06:10:09 - SRCCONF=/dev/null TB --- 2013-07-12 06:10:09 - TARGET=sparc64 TB --- 2013-07-12 06:10:09 - TARGET_ARCH=sparc64 TB --- 2013-07-12 06:10:09 - TZ=UTC TB --- 2013-07-12 06:10:09 - __MAKE_CONF=/dev/null TB --- 2013-07-12 06:10:09 - cd /src TB --- 2013-07-12 06:10:09 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 06:10:15 UTC 2013 >>> 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 [...] /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 06:34:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 06:34:42 - ERROR: failed to build world TB --- 2013-07-12 06:34:42 - 1101.79 user 218.78 system 1517.04 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 06:37:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64172AAB; Fri, 12 Jul 2013 06:37: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 22DDB1D43; Fri, 12 Jul 2013 06:37:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C6b9Co095176; Fri, 12 Jul 2013 02:37:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C6b92X095175; Fri, 12 Jul 2013 06:37:09 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 06:37:09 GMT Message-Id: <201307120637.r6C6b92X095175@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:37:10 -0000 TB --- 2013-07-12 06:07:51 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 06:07:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 06:07:51 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-07-12 06:07:51 - cleaning the object tree TB --- 2013-07-12 06:07:51 - /usr/local/bin/svn stat /src TB --- 2013-07-12 06:07:56 - At svn revision 253248 TB --- 2013-07-12 06:07:57 - building world TB --- 2013-07-12 06:07:57 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 06:07:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 06:07:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 06:07:57 - SRCCONF=/dev/null TB --- 2013-07-12 06:07:57 - TARGET=powerpc TB --- 2013-07-12 06:07:57 - TARGET_ARCH=powerpc TB --- 2013-07-12 06:07:57 - TZ=UTC TB --- 2013-07-12 06:07:57 - __MAKE_CONF=/dev/null TB --- 2013-07-12 06:07:57 - cd /src TB --- 2013-07-12 06:07:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 06:08:04 UTC 2013 >>> 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 [...] /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 06:37:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 06:37:09 - ERROR: failed to build world TB --- 2013-07-12 06:37:09 - 1373.97 user 243.75 system 1758.21 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 06:37:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 21160BE6; Fri, 12 Jul 2013 06:37: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 D26CF1D5B; Fri, 12 Jul 2013 06:37:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C6bsqU096668; Fri, 12 Jul 2013 02:37:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C6bsdA096667; Fri, 12 Jul 2013 06:37:54 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 06:37:54 GMT Message-Id: <201307120637.r6C6bsdA096667@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 , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:37:55 -0000 TB --- 2013-07-12 06:08:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 06:08:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 06:08:25 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-07-12 06:08:25 - cleaning the object tree TB --- 2013-07-12 06:08:25 - /usr/local/bin/svn stat /src TB --- 2013-07-12 06:08:29 - At svn revision 253248 TB --- 2013-07-12 06:08:30 - building world TB --- 2013-07-12 06:08:30 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 06:08:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 06:08:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 06:08:30 - SRCCONF=/dev/null TB --- 2013-07-12 06:08:30 - TARGET=powerpc TB --- 2013-07-12 06:08:30 - TARGET_ARCH=powerpc64 TB --- 2013-07-12 06:08:30 - TZ=UTC TB --- 2013-07-12 06:08:30 - __MAKE_CONF=/dev/null TB --- 2013-07-12 06:08:30 - cd /src TB --- 2013-07-12 06:08:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 06:08:36 UTC 2013 >>> 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 [...] /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 06:37:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 06:37:54 - ERROR: failed to build world TB --- 2013-07-12 06:37:54 - 1387.85 user 247.16 system 1768.52 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 06:52:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CE635E83; Fri, 12 Jul 2013 06:52:46 +0000 (UTC) (envelope-from trashcan@odo.in-berlin.de) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.60.26]) by mx1.freebsd.org (Postfix) with ESMTP id 95C001E32; Fri, 12 Jul 2013 06:52:46 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mail.kaan-bock.invalid [10.10.10.1]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bs4Zb47y3zLLM; Fri, 12 Jul 2013 08:52:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at enfer-du-nord.net Received: from mx1.enfer-du-nord.net ([10.10.10.1]) by mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [10.10.10.1]) (amavisd-new, port 10024) with LMTP id dvBYt91V8hj7; Fri, 12 Jul 2013 08:52:39 +0200 (CEST) Received: from mx1.enfer-du-nord.net (www.kaan-bock.invalid [10.10.10.2]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bs4Zb141BzLLC; Fri, 12 Jul 2013 08:52:39 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 12 Jul 2013 08:52:39 +0200 From: Michael Grimm To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: =?UTF-8?Q?ipv=36=5Faddrs=5FIF=20aliases=20in=20rc=2Econf=28?= =?UTF-8?Q?=35=29?= In-Reply-To: <20130712.135621.1408565802386368060.hrs@allbsd.org> References: <20130712.135621.1408565802386368060.hrs@allbsd.org> Message-ID: <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net> X-Sender: trashcan@odo.in-berlin.de User-Agent: Roundcube Webmail/0.9.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 06:52:46 -0000 On 2013-07-12 6:56, Hiroki Sato wrote: > Kevin Oberman wrote > in > : > > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > rk> > rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < > rk> > trashcan@odo.in-berlin.de> wrote: > rk> > > rk> > Will that patch make it into 9.2? If I am not mistaken, that > patch isn't > rk> >> in stable yet. > rk> >> > rk> > > rk> > I would also like to see this patch hit 9.x sooner than later. > It's so > rk> > painful when someone forgets to fix the alias numbering on > servers with > rk> > many, many IPv4 and IPv6 addresses... > rk> > > rk> > rk> Please, please, please, please, ...! > rk> > rk> Freeze is only two days away, so time for 9.2 is almost over and I > can see > rk> no good reason NOT to get this done. > > r252015 was merged to stable/9 today. Thanks! This is highly appreciated. A first glance at network.subr tells me that much more has been modified/simplified regarding alias definitions, great. Regards, Michael From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 07:02:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3DCEE4E2; Fri, 12 Jul 2013 07:02:39 +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 04A941F92; Fri, 12 Jul 2013 07:02:38 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UxXNA-001c48-6z>; Fri, 12 Jul 2013 09:02:32 +0200 Received: from e179079111.adsl.alicedsl.de ([85.179.79.111] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UxXNA-002Eie-4P>; Fri, 12 Jul 2013 09:02:32 +0200 Date: Fri, 12 Jul 2013 09:02:31 +0200 From: "O. Hartmann" To: FreeBSD Ports , FreeBSD CURRENT Subject: CURRENT: Changes in lib/msun/math.h make ports to fail Message-ID: <20130712090231.3ccf1f08@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 85.179.79.111 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 07:02:39 -0000 Updating CURRENT from r253216 to r253252 triggers an updating of several ports to fail, namely, for instance, www/firefox graphiks/webkit-gtk2 deskuitls/fbreader graphics/gdal The error is in all ports when compiled with CLANG 3.3 -std=c++11 -stdlib=libc++ similar, routing to math.h. I will show the error for www/firefox: [...] In file included from ./../../dist/include/mozilla/MathAlgorithms.h:15: /usr/include/c++/4.2/cmath:468:44: error: __builtin_types_compatible_p is not valid in C++ __capture_fpclassify(_Tp __f) { return fpclassify(__f); } ^~~~~~~~~~~~~~~ /usr/include/math.h:104:2: note: expanded from macro 'fpclassify' __fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), [...] I was wondering why /usr/include/c++/4.2/cmath gets included and not the header provided for CLANG. I guess this is a typo/bug. I did do dig deeper into it. Hope someone can fix this. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 07:04:25 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DFDDA698; Fri, 12 Jul 2013 07:04:25 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 3E54F1FB0; Fri, 12 Jul 2013 07:04:25 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C749br083292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 16:04:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C7490M052950; Fri, 12 Jul 2013 16:04:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 12 Jul 2013 16:03:58 +0900 (JST) Message-Id: <20130712.160358.1330135778606339435.hrs@allbsd.org> To: trashcan@odo.in-berlin.de Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Hiroki Sato In-Reply-To: <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net> <201306200229.r5K2TnfR085621@svn.freebsd.org> References: <20130712.135621.1408565802386368060.hrs@allbsd.org> <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jul_12_16_03_58_2013_117)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 12 Jul 2013 16:04:20 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 07:04:25 -0000 ----Security_Multipart(Fri_Jul_12_16_03_58_2013_117)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Grimm wrote in <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net>: tr> On 2013-07-12 6:56, Hiroki Sato wrote: tr> > Kevin Oberman wrote tr> > in : tr> > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: tr> > rk> tr> > rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < tr> > rk> > trashcan@odo.in-berlin.de> wrote: tr> > rk> > tr> > rk> > Will that patch make it into 9.2? If I am not mistaken, that patch isn't tr> > rk> >> in stable yet. tr> > rk> >> tr> > rk> > tr> > rk> > I would also like to see this patch hit 9.x sooner than later. It's so tr> > rk> > painful when someone forgets to fix the alias numbering on servers with tr> > rk> > many, many IPv4 and IPv6 addresses... tr> > rk> > tr> > rk> tr> > rk> Please, please, please, please, ...! tr> > rk> tr> > rk> Freeze is only two days away, so time for 9.2 is almost over and I can see tr> > rk> no good reason NOT to get this done. tr> > r252015 was merged to stable/9 today. tr> tr> Thanks! This is highly appreciated. A first glance at network.subr tells me that tr> much more has been modified/simplified regarding alias definitions, great. Please let me know if the existing configurations and/or the new formats do not work. The following is a summary of the supported rc.conf variables, FYI: Hiroki Sato wrote in <201306200229.r5K2TnfR085621@svn.freebsd.org>: hr> A summary of the supported ifconfig_* variables is as follows: hr> hr> # IPv4 configuration. hr> ifconfig_em0="inet 192.168.0.1" hr> # IPv6 configuration. hr> ifconfig_em0_ipv6="inet6 2001:db8::1/64" hr> # IPv4 address range spec. Now deprecated. hr> ipv4_addr_em0="10.2.1.1-10" hr> # IPv6 alias. hr> ifconfig_em0_alias0="inet6 2001:db8:5::1 prefixlen 70" hr> # IPv4 alias. hr> ifconfig_em0_alias1="inet 10.2.2.1/24" hr> # IPv4 alias with range spec w/o AF keyword (backward compat). hr> ifconfig_em0_alias2="10.3.1.1-10/32" hr> # IPv6 alias with range spec. hr> ifconfig_em0_alias3="inet6 2001:db8:20-2f::1/64" hr> # ifconfig_IF_aliases is just like ifconfig_IF_aliasN. hr> ifconfig_em0_aliases="inet 10.3.3.201-204/24 inet6 2001:db8:210-213::1/64 inet 10.1.1.1/24" hr> # IPv6 alias (backward compat) hr> ipv6_ifconfig_em0_alias0="inet6 2001:db8:f::1/64" hr> # IPv6 alias w/o AF keyword (backward compat) hr> ipv6_ifconfig_em0_alias1="2001:db8:f:1::1/64" hr> # IPv6 prefix. hr> ipv6_prefix_em0="2001:db8::/64" -- Hiroki ----Security_Multipart(Fri_Jul_12_16_03_58_2013_117)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHfql4ACgkQTyzT2CeTzy3INwCeKjaEbDXoDCva3qwaYQu0wCVR aBUAn23bflmEp/UV4CqMXFyPs5d8sucN =VSMm -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jul_12_16_03_58_2013_117)---- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 07:09:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2271A57; Fri, 12 Jul 2013 07:09:04 +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 A5735104A; Fri, 12 Jul 2013 07:09:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C793U4031827; Fri, 12 Jul 2013 03:09:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C793qs031826; Fri, 12 Jul 2013 07:09:03 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 07:09:03 GMT Message-Id: <201307120709.r6C793qs031826@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 07:09:05 -0000 TB --- 2013-07-12 05:40:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 05:40:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 05:40:16 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-07-12 05:40:16 - cleaning the object tree TB --- 2013-07-12 05:40:16 - /usr/local/bin/svn stat /src TB --- 2013-07-12 05:40:19 - At svn revision 253248 TB --- 2013-07-12 05:40:20 - building world TB --- 2013-07-12 05:40:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 05:40:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 05:40:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 05:40:20 - SRCCONF=/dev/null TB --- 2013-07-12 05:40:20 - TARGET=pc98 TB --- 2013-07-12 05:40:20 - TARGET_ARCH=i386 TB --- 2013-07-12 05:40:20 - TZ=UTC TB --- 2013-07-12 05:40:20 - __MAKE_CONF=/dev/null TB --- 2013-07-12 05:40:20 - cd /src TB --- 2013-07-12 05:40:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 05:40:27 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/pc98.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/pc98.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 07:09:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 07:09:03 - ERROR: failed to build world TB --- 2013-07-12 07:09:03 - 4590.63 user 561.52 system 5327.54 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 08:40:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C777C235; Fri, 12 Jul 2013 08:40:53 +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 7A0481633; Fri, 12 Jul 2013 08:40:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C8eqgr066106; Fri, 12 Jul 2013 04:40:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C8eqJr066105; Fri, 12 Jul 2013 08:40:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 08:40:52 GMT Message-Id: <201307120840.r6C8eqJr066105@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:40:53 -0000 TB --- 2013-07-12 07:10:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 07:10:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 07:10:22 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-12 07:10:22 - cleaning the object tree TB --- 2013-07-12 07:12:15 - /usr/local/bin/svn stat /src TB --- 2013-07-12 07:12:19 - At svn revision 253253 TB --- 2013-07-12 07:12:20 - building world TB --- 2013-07-12 07:12:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 07:12:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 07:12:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 07:12:20 - SRCCONF=/dev/null TB --- 2013-07-12 07:12:20 - TARGET=amd64 TB --- 2013-07-12 07:12:20 - TARGET_ARCH=amd64 TB --- 2013-07-12 07:12:20 - TZ=UTC TB --- 2013-07-12 07:12:20 - __MAKE_CONF=/dev/null TB --- 2013-07-12 07:12:20 - cd /src TB --- 2013-07-12 07:12:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 07:12:27 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 08:40:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 08:40:52 - ERROR: failed to build world TB --- 2013-07-12 08:40:52 - 4354.00 user 703.61 system 5430.38 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 08:40:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E9F13236; Fri, 12 Jul 2013 08:40:53 +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 9EFD51634; Fri, 12 Jul 2013 08:40:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C8eqai066120; Fri, 12 Jul 2013 04:40:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C8eqMT066119; Fri, 12 Jul 2013 08:40:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 08:40:52 GMT Message-Id: <201307120840.r6C8eqMT066119@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:40:54 -0000 TB --- 2013-07-12 07:10:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 07:10:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 07:10:22 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-12 07:10:22 - cleaning the object tree TB --- 2013-07-12 07:12:15 - /usr/local/bin/svn stat /src TB --- 2013-07-12 07:12:19 - At svn revision 253253 TB --- 2013-07-12 07:12:20 - building world TB --- 2013-07-12 07:12:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 07:12:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 07:12:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 07:12:20 - SRCCONF=/dev/null TB --- 2013-07-12 07:12:20 - TARGET=i386 TB --- 2013-07-12 07:12:20 - TARGET_ARCH=i386 TB --- 2013-07-12 07:12:20 - TZ=UTC TB --- 2013-07-12 07:12:20 - __MAKE_CONF=/dev/null TB --- 2013-07-12 07:12:20 - cd /src TB --- 2013-07-12 07:12:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 07:12:27 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/i386.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/i386.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 08:40:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 08:40:52 - ERROR: failed to build world TB --- 2013-07-12 08:40:52 - 4339.53 user 716.43 system 5430.75 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 08:42:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3B5084CB; Fri, 12 Jul 2013 08:42:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E3C911667; Fri, 12 Jul 2013 08:42:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C8g0GY069314; Fri, 12 Jul 2013 04:42:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C8g0lq069311; Fri, 12 Jul 2013 08:42:00 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 08:42:00 GMT Message-Id: <201307120842.r6C8g0lq069311@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:42:01 -0000 TB --- 2013-07-12 07:10:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 07:10:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 07:10:22 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-12 07:10:22 - cleaning the object tree TB --- 2013-07-12 07:12:13 - /usr/local/bin/svn stat /src TB --- 2013-07-12 07:12:17 - At svn revision 253253 TB --- 2013-07-12 07:12:18 - building world TB --- 2013-07-12 07:12:18 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 07:12:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 07:12:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 07:12:18 - SRCCONF=/dev/null TB --- 2013-07-12 07:12:18 - TARGET=arm TB --- 2013-07-12 07:12:18 - TARGET_ARCH=armv6 TB --- 2013-07-12 07:12:18 - TZ=UTC TB --- 2013-07-12 07:12:18 - __MAKE_CONF=/dev/null TB --- 2013-07-12 07:12:18 - cd /src TB --- 2013-07-12 07:12:18 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 07:12:25 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/arm.armv6/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/arm.armv6/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 08:42:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 08:42:00 - ERROR: failed to build world TB --- 2013-07-12 08:42:00 - 4345.73 user 730.26 system 5498.15 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 08:42:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D5344CC; Fri, 12 Jul 2013 08:42:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E3DCD1668; Fri, 12 Jul 2013 08:42:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C8g0Rm069310; Fri, 12 Jul 2013 04:42:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C8g0WE069309; Fri, 12 Jul 2013 08:42:00 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 08:42:00 GMT Message-Id: <201307120842.r6C8g0WE069309@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:42:01 -0000 TB --- 2013-07-12 07:10:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 07:10:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 07:10:22 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-12 07:10:22 - cleaning the object tree TB --- 2013-07-12 07:12:13 - /usr/local/bin/svn stat /src TB --- 2013-07-12 07:12:17 - At svn revision 253253 TB --- 2013-07-12 07:12:18 - building world TB --- 2013-07-12 07:12:18 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 07:12:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 07:12:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 07:12:18 - SRCCONF=/dev/null TB --- 2013-07-12 07:12:18 - TARGET=arm TB --- 2013-07-12 07:12:18 - TARGET_ARCH=arm TB --- 2013-07-12 07:12:18 - TZ=UTC TB --- 2013-07-12 07:12:18 - __MAKE_CONF=/dev/null TB --- 2013-07-12 07:12:18 - cd /src TB --- 2013-07-12 07:12:18 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 07:12:25 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/arm.arm/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/arm.arm/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 08:42:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 08:42:00 - ERROR: failed to build world TB --- 2013-07-12 08:42:00 - 4342.61 user 732.15 system 5498.02 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 09:02:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9EDD2E64 for ; Fri, 12 Jul 2013 09:02:21 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7227517D2 for ; Fri, 12 Jul 2013 09:02:21 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id 9so20093248iec.33 for ; Fri, 12 Jul 2013 02:02:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=e+7/ETrnsOQ0d7cWp/fT3isRm3Fg3kLY6PXu0Bz2De0=; b=a2Asam36Fh05JmkZpiKuQUuJMM4u1Vx66dM0wao8OUNqYONaStGZZRoWh3/fISsIbd jjq39Obq3J1oFYhn72L1jFPMprsxSskE4hxLfl/yCU3ZXy5A7np1fckdR9e4llWAsiDP TJfTAE1AG2dfX+eLZd/KK+WnO8NpHApaSL8leTNaPuJC/ntiS0uqAlaEGU4sPXJLk5jK U1s0QHRO+Ox9FPh0Ppl/BzFGlvP4VhHl+71ezwIOctQoI1mvXl0EoEl2qybb5dR4FalS 6USf+y5agb3EGELH3yN0xu7hws+cfIbnhQ6xNoi+VI/E1a423644qq1I5JrPHDap0IpD cvVw== X-Received: by 10.42.52.6 with SMTP id h6mr12388570icg.5.1373619734935; Fri, 12 Jul 2013 02:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.228.161 with HTTP; Fri, 12 Jul 2013 02:01:59 -0700 (PDT) In-Reply-To: References: <1601171.hWXcdG7J9D@notebook.alkar.net> From: "Lundberg, Johannes" Date: Fri, 12 Jul 2013 18:01:59 +0900 Message-ID: Subject: Re: FreeBSD-head hang when shutdown by ACPI with Intel GPU and new Xorg and SandyBridge To: Kevin Oberman X-Gm-Message-State: ALoCoQl+gFJRx/0eKO84jsURuml9Ki3OP0IOVuOqF1qzlLGkWucMzafFZl746wNhIiAM/fwpS+7u Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Artyom Mirgorodskiy , "freebsd-x11@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 09:02:21 -0000 > As the KMS code does not switch the display mode back, once X with KMS starts, you can't get a console back. Is there any solution for this in the works? Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Wed, May 22, 2013 at 5:44 AM, Kevin Oberman wrote: > On Tue, May 21, 2013 at 12:50 PM, Artyom Mirgorodskiy < > artyom.mirgorodsky@gmail.com> wrote: > > > Hi > > More than a month I can not shutdown FreeBSD on my laptop correctly when > > running Xorg with Intel GPU. However reboot work correctly. Shutdown work > > fine if I choose Vesa driver in xorg.conf. So I can run with intel, then > > edit xorg.conf, kill Xorg server and shutdown correctly. If I shut down > > immediately after loading Xorg - everything is fine too. > > Without the text console is difficult to provide any information :( Why > > would still not recover mode when kill Xorg? > > > > PS > > I try to disable RC6 states -without any changes. > > FreeBSD shutdown correctly before January. > > > > I am seeing similar issues on my Sandybridge running Xorg with KMS, but I > see it on 9-Stable. > > The main difference between shutdown and reboot is that shutdown goes > through the rc.d files and issues a 'stop' for each. reboot simply kills > running processes, first by sending SIGTERM and then sending SIGKILL to > those that still live. So something is failing to die and that "something" > is probably X. The system still responds to ICMP ECHOREQUEST (i.e. ping), > but I can't fire up an ssh session. > > As the KMS code does not switch the display mode back, once X with KMS > starts, you can't get a console back. > > Since the system is deadlocked in this state, I suspect something bad is > happening in the KMS code that leaves the system hung. > > I may try to run a firewire console. Never tried it, but it should work. > _______________________________________________ > 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 Fri Jul 12 09:06:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02FEF140; Fri, 12 Jul 2013 09:06: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 B5F1F1806; Fri, 12 Jul 2013 09:06:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C96G8W052938; Fri, 12 Jul 2013 05:06:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C96GVG052934; Fri, 12 Jul 2013 09:06:16 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 09:06:16 GMT Message-Id: <201307120906.r6C96GVG052934@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 , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:06:17 -0000 TB --- 2013-07-12 08:42:00 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 08:42:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 08:42:00 - starting HEAD tinderbox run for mips64/mips TB --- 2013-07-12 08:42:00 - cleaning the object tree TB --- 2013-07-12 08:43:11 - /usr/local/bin/svn stat /src TB --- 2013-07-12 08:43:15 - At svn revision 253253 TB --- 2013-07-12 08:43:16 - building world TB --- 2013-07-12 08:43:16 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 08:43:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 08:43:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 08:43:16 - SRCCONF=/dev/null TB --- 2013-07-12 08:43:16 - TARGET=mips TB --- 2013-07-12 08:43:16 - TARGET_ARCH=mips64 TB --- 2013-07-12 08:43:16 - TZ=UTC TB --- 2013-07-12 08:43:16 - __MAKE_CONF=/dev/null TB --- 2013-07-12 08:43:16 - cd /src TB --- 2013-07-12 08:43:16 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 08:43:23 UTC 2013 >>> 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 [...] /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 09:06:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 09:06:16 - ERROR: failed to build world TB --- 2013-07-12 09:06:16 - 1020.17 user 234.40 system 1455.64 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 09:06:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E48823C; Fri, 12 Jul 2013 09:06: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 4CA171808; Fri, 12 Jul 2013 09:06:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C96JAQ053230; Fri, 12 Jul 2013 05:06:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C96JYN053226; Fri, 12 Jul 2013 09:06:19 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 09:06:19 GMT Message-Id: <201307120906.r6C96JYN053226@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 , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:06:20 -0000 TB --- 2013-07-12 08:42:00 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 08:42:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 08:42:00 - starting HEAD tinderbox run for mips/mips TB --- 2013-07-12 08:42:00 - cleaning the object tree TB --- 2013-07-12 08:43:11 - /usr/local/bin/svn stat /src TB --- 2013-07-12 08:43:15 - At svn revision 253253 TB --- 2013-07-12 08:43:16 - building world TB --- 2013-07-12 08:43:16 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 08:43:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 08:43:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 08:43:16 - SRCCONF=/dev/null TB --- 2013-07-12 08:43:16 - TARGET=mips TB --- 2013-07-12 08:43:16 - TARGET_ARCH=mips TB --- 2013-07-12 08:43:16 - TZ=UTC TB --- 2013-07-12 08:43:16 - __MAKE_CONF=/dev/null TB --- 2013-07-12 08:43:16 - cd /src TB --- 2013-07-12 08:43:16 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 08:43:23 UTC 2013 >>> 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 [...] /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 09:06:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 09:06:19 - ERROR: failed to build world TB --- 2013-07-12 09:06:19 - 1022.67 user 236.02 system 1459.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 09:11:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4B60A520; Fri, 12 Jul 2013 09:11:52 +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 0981A185F; Fri, 12 Jul 2013 09:11:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C9BpYi068662; Fri, 12 Jul 2013 05:11:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C9BpNn068661; Fri, 12 Jul 2013 09:11:51 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 09:11:51 GMT Message-Id: <201307120911.r6C9BpNn068661@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:11:52 -0000 TB --- 2013-07-12 08:40:53 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 08:40:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 08:40:53 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-07-12 08:40:53 - cleaning the object tree TB --- 2013-07-12 08:41:54 - /usr/local/bin/svn stat /src TB --- 2013-07-12 08:42:00 - At svn revision 253253 TB --- 2013-07-12 08:42:01 - building world TB --- 2013-07-12 08:42:01 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 08:42:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 08:42:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 08:42:01 - SRCCONF=/dev/null TB --- 2013-07-12 08:42:01 - TARGET=ia64 TB --- 2013-07-12 08:42:01 - TARGET_ARCH=ia64 TB --- 2013-07-12 08:42:01 - TZ=UTC TB --- 2013-07-12 08:42:01 - __MAKE_CONF=/dev/null TB --- 2013-07-12 08:42:01 - cd /src TB --- 2013-07-12 08:42:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 08:42:10 UTC 2013 >>> 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 [...] /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 09:11:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 09:11:51 - ERROR: failed to build world TB --- 2013-07-12 09:11:51 - 1365.65 user 256.41 system 1858.32 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 09:36:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C08E9D58; Fri, 12 Jul 2013 09:36:18 +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 7CCA81982; Fri, 12 Jul 2013 09:36:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C9aHSP041218; Fri, 12 Jul 2013 05:36:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C9aH7Z041217; Fri, 12 Jul 2013 09:36:17 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 09:36:17 GMT Message-Id: <201307120936.r6C9aH7Z041217@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:36:18 -0000 TB --- 2013-07-12 09:11:51 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 09:11:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 09:11:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-12 09:11:51 - cleaning the object tree TB --- 2013-07-12 09:12:17 - /usr/local/bin/svn stat /src TB --- 2013-07-12 09:12:20 - At svn revision 253253 TB --- 2013-07-12 09:12:21 - building world TB --- 2013-07-12 09:12:21 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 09:12:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 09:12:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 09:12:21 - SRCCONF=/dev/null TB --- 2013-07-12 09:12:21 - TARGET=sparc64 TB --- 2013-07-12 09:12:21 - TARGET_ARCH=sparc64 TB --- 2013-07-12 09:12:21 - TZ=UTC TB --- 2013-07-12 09:12:21 - __MAKE_CONF=/dev/null TB --- 2013-07-12 09:12:21 - cd /src TB --- 2013-07-12 09:12:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 09:12:27 UTC 2013 >>> 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 [...] /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 09:36:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 09:36:17 - ERROR: failed to build world TB --- 2013-07-12 09:36:17 - 1098.57 user 222.26 system 1466.31 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 09:36:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C230D59; Fri, 12 Jul 2013 09:36: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 EF2F01983; Fri, 12 Jul 2013 09:36:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C9aIuX041228; Fri, 12 Jul 2013 05:36:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C9aI5i041227; Fri, 12 Jul 2013 09:36:18 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 09:36:18 GMT Message-Id: <201307120936.r6C9aI5i041227@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:36:19 -0000 TB --- 2013-07-12 09:06:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 09:06:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 09:06:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-07-12 09:06:16 - cleaning the object tree TB --- 2013-07-12 09:07:01 - /usr/local/bin/svn stat /src TB --- 2013-07-12 09:07:05 - At svn revision 253253 TB --- 2013-07-12 09:07:06 - building world TB --- 2013-07-12 09:07:06 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 09:07:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 09:07:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 09:07:06 - SRCCONF=/dev/null TB --- 2013-07-12 09:07:06 - TARGET=powerpc TB --- 2013-07-12 09:07:06 - TARGET_ARCH=powerpc TB --- 2013-07-12 09:07:06 - TZ=UTC TB --- 2013-07-12 09:07:06 - __MAKE_CONF=/dev/null TB --- 2013-07-12 09:07:06 - cd /src TB --- 2013-07-12 09:07:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 09:07:12 UTC 2013 >>> 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 [...] /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 09:36:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 09:36:18 - ERROR: failed to build world TB --- 2013-07-12 09:36:18 - 1375.59 user 249.39 system 1802.09 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 09:36:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C037EA9; Fri, 12 Jul 2013 09:36: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 5AF871993; Fri, 12 Jul 2013 09:36:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C9abCe041751; Fri, 12 Jul 2013 05:36:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C9abhT041750; Fri, 12 Jul 2013 09:36:37 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 09:36:37 GMT Message-Id: <201307120936.r6C9abhT041750@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 , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:36:38 -0000 TB --- 2013-07-12 09:06:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 09:06:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 09:06:20 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-07-12 09:06:20 - cleaning the object tree TB --- 2013-07-12 09:07:06 - /usr/local/bin/svn stat /src TB --- 2013-07-12 09:07:09 - At svn revision 253253 TB --- 2013-07-12 09:07:10 - building world TB --- 2013-07-12 09:07:10 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 09:07:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 09:07:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 09:07:10 - SRCCONF=/dev/null TB --- 2013-07-12 09:07:10 - TARGET=powerpc TB --- 2013-07-12 09:07:10 - TARGET_ARCH=powerpc64 TB --- 2013-07-12 09:07:10 - TZ=UTC TB --- 2013-07-12 09:07:10 - __MAKE_CONF=/dev/null TB --- 2013-07-12 09:07:10 - cd /src TB --- 2013-07-12 09:07:10 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 09:07:16 UTC 2013 >>> 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 [...] /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 09:36:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 09:36:37 - ERROR: failed to build world TB --- 2013-07-12 09:36:37 - 1387.30 user 257.10 system 1817.52 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 10:10:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9AC11A72; Fri, 12 Jul 2013 10:10: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 4D0461B41; Fri, 12 Jul 2013 10:10:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CAArKc076638; Fri, 12 Jul 2013 06:10:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CAArEU076637; Fri, 12 Jul 2013 10:10:53 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 10:10:53 GMT Message-Id: <201307121010.r6CAArEU076637@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 10:10:54 -0000 TB --- 2013-07-12 08:40:52 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 08:40:52 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 08:40:52 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-07-12 08:40:52 - cleaning the object tree TB --- 2013-07-12 08:42:04 - /usr/local/bin/svn stat /src TB --- 2013-07-12 08:42:08 - At svn revision 253253 TB --- 2013-07-12 08:42:09 - building world TB --- 2013-07-12 08:42:09 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 08:42:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 08:42:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 08:42:09 - SRCCONF=/dev/null TB --- 2013-07-12 08:42:09 - TARGET=pc98 TB --- 2013-07-12 08:42:09 - TARGET_ARCH=i386 TB --- 2013-07-12 08:42:09 - TZ=UTC TB --- 2013-07-12 08:42:09 - __MAKE_CONF=/dev/null TB --- 2013-07-12 08:42:09 - cd /src TB --- 2013-07-12 08:42:09 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 08:42:16 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/pc98.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/pc98.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 10:10:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 10:10:53 - ERROR: failed to build world TB --- 2013-07-12 10:10:53 - 4589.79 user 533.86 system 5400.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 10:26:21 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2DBCFD39; Fri, 12 Jul 2013 10:26:21 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id D6DCA1C0E; Fri, 12 Jul 2013 10:26:20 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6CAQAtn064142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jul 2013 10:26:11 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_D51080B0-9E93-4601-804C-6B3DA031AAE1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: FreeBSD-head hang when shutdown by ACPI with Intel GPU and new Xorg and SandyBridge From: David Chisnall In-Reply-To: Date: Fri, 12 Jul 2013 11:26:06 +0100 Message-Id: <22CEA4A9-5C63-4561-8663-42F8623F1D97@FreeBSD.org> References: <1601171.hWXcdG7J9D@notebook.alkar.net> To: "Lundberg, Johannes" X-Mailer: Apple Mail (2.1503) Cc: Kevin Oberman , "freebsd-x11@freebsd.org" , FreeBSD Current , Artyom Mirgorodskiy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 10:26:21 -0000 --Apple-Mail=_D51080B0-9E93-4601-804C-6B3DA031AAE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Jul 2013, at 10:01, "Lundberg, Johannes" = wrote: >> As the KMS code does not switch the display mode back, once X with = KMS > starts, you can't get a console back. >=20 > Is there any solution for this in the works? Yes. ray@ is currently being funded by the FreeBSD Foundation to = improve Newcons compatibility with KMS. The Newcons framework is = designed to improve layering in the console. The machine-dependent part = simply provides a framebuffer interface, the machine-independent part = provides the terminal emulator (this also means things like unicode in = the console will work, as will higher-resolution consoles). It's = currently used on a few non-x86 platforms, but it wasn't a priority for = x86 because the PC BIOS text console mostly works and people who want a = better terminal can just run X. It's now become a priority because of = the KMS integration with X.org. Once this work is completed, we will = switch to a new X.org by default and will use the KMS interface within = the kernel for selecting the video mode. =20 David --Apple-Mail=_D51080B0-9E93-4601-804C-6B3DA031AAE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR39m/AAoJEKx65DEEsqIdySUQAJBCTvZI8wcCHBl1a5eYAOtj +B2ibwGKmN1ubb+CFX7DTxiWfCnMjJ0JcYc1bGFRKtvHYYBueIuUWKxmk3vFDPzj PH8tfhKPdYV7upKMkZcG9paWWnSYXA73mZUWfDf7Y0LUIuN54vQSNks270yvPQA5 DlFbwoYqdZe+Ejlt22NfqxRB9slxwMEIsaMOPSN/HZ4raKlDfjgxVBf3fvY5Ihym XGgnvLLFMTx/Zid7Vj93rQD2yIQZn3McRg9i13b8J0OG2/VXuPXmrD7ZvNWJeEKS ACyLmntZIU28zLI6dEV19rfgym7qktxHon3oNcR7niTekA62NLk48exh5DbMKNYI 0HJXfSF28EdfLRX/ms4xsAHtjAkt7QB631+q8jMK82uos927paCiWGKuWdJnsjs8 GKnQRbRjCUxNHUSUjASMTsoPR0bXPmxv3AoAE1t2tng1Rty064oX6K2N703V9V7c w2Y/kbodfTs3Znz5tQz5C9/wXpqMStrtHhR5NNQuzvi1IQtamQsgworREYh/E07m Q587fIfXTELelo/47O+TQ9whnb5rbXYi8EXfnM+CoYDW1LsXt5JjPCDPeyP93F4C XtitVA2aeXsmOdqika9Axv+RqfjU/t3Mbnhpq29x9qm0u4sttdxOFJprgGId1Wdy FID5L7jCdehxHeGBFxPG =tqTb -----END PGP SIGNATURE----- --Apple-Mail=_D51080B0-9E93-4601-804C-6B3DA031AAE1-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 11:11:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A873503; Fri, 12 Jul 2013 11:11:54 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by mx1.freebsd.org (Postfix) with ESMTP id 835E31DB4; Fri, 12 Jul 2013 11:11:53 +0000 (UTC) Received: from [78.35.187.54] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Uxb3o-00087f-D6; Fri, 12 Jul 2013 12:58:48 +0200 Date: Fri, 12 Jul 2013 12:56:46 +0200 From: Fabian Keil To: Andre Oppermann Subject: Re: Improved SYN Cookies: Looking for testers Message-ID: <20130712125640.6d194bd2@fabiankeil.de> In-Reply-To: <51DE6E86.6080707@freebsd.org> References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> <51DE6E86.6080707@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/+l5SWKY1Do2xlDqSnlUmZmj"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 11:11:54 -0000 --Sig_/+l5SWKY1Do2xlDqSnlUmZmj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > On 10.07.2013 15:18, Fabian Keil wrote: > > Andre Oppermann wrote: > > > >> We have a SYN cookie implementation for quite some time now but it > >> has some limitations with current realities for window scaling and > >> SACK encoding the in the few available bits. [...] > >> http://people.freebsd.org/~andre/syncookie-20130708.diff > > > > I've been using the patch for a couple of days and didn't notice any > > issues so far. Privoxy's regression tests continue to work as expected > > as well. >=20 > Thanks for testing and reporting back. >=20 > Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_on= ly=3D1 > as well to bypass the syn cache entirely? I haven't noticed any issues with net.inet.tcp.syncookies_only=3D1. > It will give a bit of debug log output which is it telling you mostly abo= ut > rounding to the next nearest index value. You can send the output privat= ely > to me to spot unexpected outliers, if any. One unexpected outlier seems to be: Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:81= 18 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 27 bytes o= f data after socket was closed, sending RST and removing tcpcb Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:81= 18 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authen= tication, segment rejected (probably spoofed) This also seems to have resulted in two reset packets: fk@r500 ~/test/wireshark $tcpdump -vv -n -r syncookie-test.pcap dst port 6= 2972 reading from file syncookie-test.pcap, link-type NULL (BSD loopback) 12:42:47.033832 IP (tos 0x0, ttl 64, id 17522, offset 0, flags [DF], proto = TCP (6), length 60, bad cksum 0 (->e248)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [S.], cksum 0x8c5f (correct), seq= 1633309846, ack 61471870, win 65535, options [mss 16344,nop,wscale 6,sackO= K,TS val 4243589075 ecr 4051741531], length 0 12:42:47.138107 IP (tos 0x0, ttl 64, id 17582, offset 0, flags [DF], proto = TCP (6), length 52, bad cksum 0 (->e214)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xef2f (correct), seq = 1, ack 183, win 1275, options [nop,nop,TS val 4243589180 ecr 4051741536], l= ength 0 12:42:47.785762 IP (tos 0x0, ttl 64, id 17592, offset 0, flags [DF], proto = TCP (6), length 120, bad cksum 0 (->e1c6)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x7209 (correct), seq= 1:69, ack 183, win 1275, options [nop,nop,TS val 4243589827 ecr 4051741536= ], length 68 12:42:47.945156 IP (tos 0x0, ttl 64, id 17609, offset 0, flags [DF], proto = TCP (6), length 52, bad cksum 0 (->e1f9)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xe80f (correct), seq = 69, ack 325, win 1275, options [nop,nop,TS val 4243589987 ecr 4051742343], = length 0 12:42:48.470035 IP (tos 0x0, ttl 64, id 17678, offset 0, flags [DF], proto = TCP (6), length 550, bad cksum 0 (->dfc2)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x3ce0 (correct), seq= 69:567, ack 325, win 1275, options [nop,nop,TS val 4243590511 ecr 40517423= 43], length 498 12:42:48.599754 IP (tos 0x0, ttl 64, id 17683, offset 0, flags [DF], proto = TCP (6), length 550, bad cksum 0 (->dfbd)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x0a10 (correct), seq= 567:1065, ack 325, win 1275, options [nop,nop,TS val 4243590641 ecr 405174= 3067], length 498 12:42:48.699161 IP (tos 0x0, ttl 64, id 17688, offset 0, flags [DF], proto = TCP (6), length 2465, bad cksum 0 (->d83d)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x92bd (correct), seq= 1065:3478, ack 325, win 1275, options [nop,nop,TS val 4243590741 ecr 40517= 43197], length 2413 12:42:48.824428 IP (tos 0x0, ttl 64, id 17706, offset 0, flags [DF], proto = TCP (6), length 52, bad cksum 0 (->e198)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xd2da (correct), seq = 3478, ack 592, win 1275, options [nop,nop,TS val 4243590867 ecr 4051743216]= , length 0 12:42:48.924148 IP (tos 0x0, ttl 64, id 17713, offset 0, flags [DF], proto = TCP (6), length 52, bad cksum 0 (->e191)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xd1dd (correct), seq = 3478, ack 639, win 1275, options [nop,nop,TS val 4243590966 ecr 4051743323]= , length 0 12:42:49.725732 IP (tos 0x0, ttl 64, id 17769, offset 0, flags [DF], proto = TCP (6), length 99, bad cksum 0 (->e12a)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x7969 (correct), seq= 3478:3525, ack 639, win 1275, options [nop,nop,TS val 4243591767 ecr 40517= 43323], length 47 12:42:49.833378 IP (tos 0x0, ttl 64, id 17784, offset 0, flags [DF], proto = TCP (6), length 52, bad cksum 0 (->e14a)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xc9a7 (correct), seq = 3525, ack 882, win 1275, options [nop,nop,TS val 4243591876 ecr 4051744225]= , length 0 12:42:50.436702 IP (tos 0x0, ttl 64, id 17801, offset 0, flags [DF], proto = TCP (6), length 550, bad cksum 0 (->df47)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x3f05 (correct), seq= 3525:4023, ack 882, win 1275, options [nop,nop,TS val 4243592478 ecr 40517= 44225], length 498 12:42:50.539394 IP (tos 0x0, ttl 64, id 17847, offset 0, flags [DF], proto = TCP (6), length 5051, bad cksum 0 (->cd84)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x1b29 (correct), seq= 4023:9022, ack 882, win 1275, options [nop,nop,TS val 4243592581 ecr 40517= 45037], length 4999 12:42:50.639133 IP (tos 0x0, ttl 64, id 17860, offset 0, flags [DF], proto = TCP (6), length 7204, bad cksum 0 (->c50e)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x7f02 (correct), seq= 9022:16174, ack 882, win 1275, options [nop,nop,TS val 4243592681 ecr 4051= 745137], length 7152 12:42:50.673745 IP (tos 0x0, ttl 64, id 17867, offset 0, flags [DF], proto = TCP (6), length 16384, bad cksum 0 (->a12b)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0x1f1d (correct), seq = 16174:32506, ack 882, win 1275, options [nop,nop,TS val 4243592715 ecr 4051= 745137], length 16332 12:42:50.673796 IP (tos 0x0, ttl 64, id 17869, offset 0, flags [DF], proto = TCP (6), length 1244, bad cksum 0 (->dc4d)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0xf717 (correct), seq= 32506:33698, ack 882, win 1275, options [nop,nop,TS val 4243592715 ecr 405= 1745171], length 1192 12:42:50.769080 IP (tos 0x0, ttl 64, id 17883, offset 0, flags [DF], proto = TCP (6), length 16384, bad cksum 0 (->a11b)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0x6a4e (correct), seq = 33698:50030, ack 882, win 1275, options [nop,nop,TS val 4243592811 ecr 4051= 745171], length 16332 12:42:50.769123 IP (tos 0x0, ttl 64, id 17885, offset 0, flags [DF], proto = TCP (6), length 2532, bad cksum 0 (->d735)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x4cde (correct), seq= 50030:52510, ack 882, win 1275, options [nop,nop,TS val 4243592811 ecr 405= 1745267], length 2480 12:42:50.869118 IP (tos 0x0, ttl 64, id 17908, offset 0, flags [DF], proto = TCP (6), length 13592, bad cksum 0 (->abea)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0xd9bf (correct), seq= 52510:66050, ack 882, win 1275, options [nop,nop,TS val 4243592911 ecr 405= 1745367], length 13540 12:42:50.980382 IP (tos 0x0, ttl 64, id 17938, offset 0, flags [DF], proto = TCP (6), length 550, bad cksum 0 (->debe)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x9e13 (correct), seq= 66050:66548, ack 882, win 1275, options [nop,nop,TS val 4243593022 ecr 405= 1745383], length 498 12:42:51.080184 IP (tos 0x0, ttl 64, id 17953, offset 0, flags [DF], proto = TCP (6), length 3538, bad cksum 0 (->d303)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0xe297 (correct), seq= 66548:70034, ack 882, win 1275, options [nop,nop,TS val 4243593122 ecr 405= 1745578], length 3486 12:42:51.126696 IP (tos 0x0, ttl 64, id 17960, offset 0, flags [DF], proto = TCP (6), length 1484, bad cksum 0 (->db02)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [FP.], cksum 0xd00a (correct), se= q 70034:71466, ack 882, win 1275, options [nop,nop,TS val 4243593168 ecr 40= 51745578], length 1432 12:42:51.173301 IP (tos 0x0, ttl 64, id 17981, offset 0, flags [DF], proto = TCP (6), length 40, bad cksum 0 (->e091)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [R], cksum 0xb90f (correct), seq = 1633381313, win 0, length 0 12:42:51.173330 IP (tos 0x0, ttl 64, id 17983, offset 0, flags [DF], proto = TCP (6), length 40, bad cksum 0 (->e08f)!) 10.0.0.1.8118 > 10.0.0.1.62972: Flags [R], cksum 0xb90f (correct), seq = 1633381313, win 0, length 0 Client and server are running on the same system. As I don't usually use net.inet.tcp.log_debug and haven't been able to inte= ntionally reproduce the issue (but have seen it a few times), I'm not sure yet if the= behaviour is actually related to the SYN cookie changes at all. Fabian --Sig_/+l5SWKY1Do2xlDqSnlUmZmj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHf4O4ACgkQBYqIVf93VJ3xFQCeO0huZtcJZOizigu0Yt1zF9Kb Ph0AnjNBYkGiAnmYrZLXAp9Gly8giF54 =D0k2 -----END PGP SIGNATURE----- --Sig_/+l5SWKY1Do2xlDqSnlUmZmj-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 11:49:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DDF89C60; Fri, 12 Jul 2013 11:49:39 +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 8FBDF1F08; Fri, 12 Jul 2013 11:49:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CBncRY010744; Fri, 12 Jul 2013 07:49:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CBncfr010735; Fri, 12 Jul 2013 11:49:38 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 11:49:38 GMT Message-Id: <201307121149.r6CBncfr010735@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:49:39 -0000 TB --- 2013-07-12 10:20:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 10:20:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 10:20:16 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-12 10:20:16 - cleaning the object tree TB --- 2013-07-12 10:22:43 - /usr/local/bin/svn stat /src TB --- 2013-07-12 10:22:46 - At svn revision 253259 TB --- 2013-07-12 10:22:47 - building world TB --- 2013-07-12 10:22:47 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 10:22:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 10:22:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 10:22:47 - SRCCONF=/dev/null TB --- 2013-07-12 10:22:47 - TARGET=i386 TB --- 2013-07-12 10:22:47 - TARGET_ARCH=i386 TB --- 2013-07-12 10:22:47 - TZ=UTC TB --- 2013-07-12 10:22:47 - __MAKE_CONF=/dev/null TB --- 2013-07-12 10:22:47 - cd /src TB --- 2013-07-12 10:22:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 10:22:54 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/i386.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/i386.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 11:49:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 11:49:38 - ERROR: failed to build world TB --- 2013-07-12 11:49:38 - 4339.45 user 686.17 system 5361.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 11:49:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D680D67; Fri, 12 Jul 2013 11:49:46 +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 22B4E1F0D; Fri, 12 Jul 2013 11:49:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CBnjPo011030; Fri, 12 Jul 2013 07:49:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CBnjoJ011029; Fri, 12 Jul 2013 11:49:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 11:49:45 GMT Message-Id: <201307121149.r6CBnjoJ011029@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:49:46 -0000 TB --- 2013-07-12 10:20:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 10:20:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 10:20:16 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-12 10:20:16 - cleaning the object tree TB --- 2013-07-12 10:22:42 - /usr/local/bin/svn stat /src TB --- 2013-07-12 10:22:46 - At svn revision 253259 TB --- 2013-07-12 10:22:47 - building world TB --- 2013-07-12 10:22:47 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 10:22:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 10:22:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 10:22:47 - SRCCONF=/dev/null TB --- 2013-07-12 10:22:47 - TARGET=amd64 TB --- 2013-07-12 10:22:47 - TARGET_ARCH=amd64 TB --- 2013-07-12 10:22:47 - TZ=UTC TB --- 2013-07-12 10:22:47 - __MAKE_CONF=/dev/null TB --- 2013-07-12 10:22:47 - cd /src TB --- 2013-07-12 10:22:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 10:22:53 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 11:49:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 11:49:45 - ERROR: failed to build world TB --- 2013-07-12 11:49:45 - 4351.96 user 686.09 system 5368.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 11:50:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 656DBFB1; Fri, 12 Jul 2013 11:50: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 190AF1F3E; Fri, 12 Jul 2013 11:50:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CBosPB015643; Fri, 12 Jul 2013 07:50:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CBos8A015642; Fri, 12 Jul 2013 11:50:54 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 11:50:54 GMT Message-Id: <201307121150.r6CBos8A015642@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:50:55 -0000 TB --- 2013-07-12 10:20:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 10:20:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 10:20:16 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-12 10:20:16 - cleaning the object tree TB --- 2013-07-12 10:22:39 - /usr/local/bin/svn stat /src TB --- 2013-07-12 10:22:42 - At svn revision 253259 TB --- 2013-07-12 10:22:43 - building world TB --- 2013-07-12 10:22:43 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 10:22:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 10:22:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 10:22:43 - SRCCONF=/dev/null TB --- 2013-07-12 10:22:43 - TARGET=arm TB --- 2013-07-12 10:22:43 - TARGET_ARCH=armv6 TB --- 2013-07-12 10:22:43 - TZ=UTC TB --- 2013-07-12 10:22:43 - __MAKE_CONF=/dev/null TB --- 2013-07-12 10:22:43 - cd /src TB --- 2013-07-12 10:22:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 10:22:50 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/arm.armv6/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/arm.armv6/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 11:50:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 11:50:54 - ERROR: failed to build world TB --- 2013-07-12 11:50:54 - 4341.07 user 713.91 system 5437.49 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 11:50:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F3DAFB2; Fri, 12 Jul 2013 11:50: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 21C9E1F3F; Fri, 12 Jul 2013 11:50:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CBos6e015657; Fri, 12 Jul 2013 07:50:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CBosbb015656; Fri, 12 Jul 2013 11:50:54 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 11:50:54 GMT Message-Id: <201307121150.r6CBosbb015656@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:50:55 -0000 TB --- 2013-07-12 10:20:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 10:20:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 10:20:16 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-12 10:20:16 - cleaning the object tree TB --- 2013-07-12 10:22:39 - /usr/local/bin/svn stat /src TB --- 2013-07-12 10:22:43 - At svn revision 253259 TB --- 2013-07-12 10:22:44 - building world TB --- 2013-07-12 10:22:44 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 10:22:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 10:22:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 10:22:44 - SRCCONF=/dev/null TB --- 2013-07-12 10:22:44 - TARGET=arm TB --- 2013-07-12 10:22:44 - TARGET_ARCH=arm TB --- 2013-07-12 10:22:44 - TZ=UTC TB --- 2013-07-12 10:22:44 - __MAKE_CONF=/dev/null TB --- 2013-07-12 10:22:44 - cd /src TB --- 2013-07-12 10:22:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 10:22:50 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/arm.arm/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/arm.arm/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 11:50:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 11:50:54 - ERROR: failed to build world TB --- 2013-07-12 11:50:54 - 4337.52 user 714.24 system 5437.82 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 12:14:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C30A711; Fri, 12 Jul 2013 12:14: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 38D641082; Fri, 12 Jul 2013 12:14:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CCEhqS000700; Fri, 12 Jul 2013 08:14:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CCEhK1000689; Fri, 12 Jul 2013 12:14:43 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 12:14:43 GMT Message-Id: <201307121214.r6CCEhK1000689@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 , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:14:44 -0000 TB --- 2013-07-12 11:50:54 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 11:50:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 11:50:54 - starting HEAD tinderbox run for mips64/mips TB --- 2013-07-12 11:50:54 - cleaning the object tree TB --- 2013-07-12 11:51:51 - /usr/local/bin/svn stat /src TB --- 2013-07-12 11:51:55 - At svn revision 253259 TB --- 2013-07-12 11:51:56 - building world TB --- 2013-07-12 11:51:56 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 11:51:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 11:51:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 11:51:56 - SRCCONF=/dev/null TB --- 2013-07-12 11:51:56 - TARGET=mips TB --- 2013-07-12 11:51:56 - TARGET_ARCH=mips64 TB --- 2013-07-12 11:51:56 - TZ=UTC TB --- 2013-07-12 11:51:56 - __MAKE_CONF=/dev/null TB --- 2013-07-12 11:51:56 - cd /src TB --- 2013-07-12 11:51:56 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 11:52:03 UTC 2013 >>> 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 [...] /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 12:14:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 12:14:43 - ERROR: failed to build world TB --- 2013-07-12 12:14:43 - 1020.09 user 237.72 system 1428.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 12:14:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C94C8813; Fri, 12 Jul 2013 12:14: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 3E9FA1086; Fri, 12 Jul 2013 12:14:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CCElnF001127; Fri, 12 Jul 2013 08:14:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CCEleE001123; Fri, 12 Jul 2013 12:14:47 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 12:14:47 GMT Message-Id: <201307121214.r6CCEleE001123@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 , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:14:48 -0000 TB --- 2013-07-12 11:50:54 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 11:50:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 11:50:54 - starting HEAD tinderbox run for mips/mips TB --- 2013-07-12 11:50:54 - cleaning the object tree TB --- 2013-07-12 11:51:51 - /usr/local/bin/svn stat /src TB --- 2013-07-12 11:51:55 - At svn revision 253259 TB --- 2013-07-12 11:51:56 - building world TB --- 2013-07-12 11:51:56 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 11:51:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 11:51:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 11:51:56 - SRCCONF=/dev/null TB --- 2013-07-12 11:51:56 - TARGET=mips TB --- 2013-07-12 11:51:56 - TARGET_ARCH=mips TB --- 2013-07-12 11:51:56 - TZ=UTC TB --- 2013-07-12 11:51:56 - __MAKE_CONF=/dev/null TB --- 2013-07-12 11:51:56 - cd /src TB --- 2013-07-12 11:51:56 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 11:52:02 UTC 2013 >>> 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 [...] /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 12:14:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 12:14:47 - ERROR: failed to build world TB --- 2013-07-12 12:14:47 - 1023.45 user 237.89 system 1433.26 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 12:18:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD82FC17 for ; Fri, 12 Jul 2013 12:18:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2CC10EA for ; Fri, 12 Jul 2013 12:18:25 +0000 (UTC) Received: (qmail 96472 invoked from network); 12 Jul 2013 13:08:49 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Jul 2013 13:08:49 -0000 Message-ID: <51DFF400.6070504@freebsd.org> Date: Fri, 12 Jul 2013 14:18:08 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fabian Keil Subject: Re: Improved SYN Cookies: Looking for testers References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> <51DE6E86.6080707@freebsd.org> <20130712125640.6d194bd2@fabiankeil.de> In-Reply-To: <20130712125640.6d194bd2@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 12:18:26 -0000 On 12.07.2013 12:56, Fabian Keil wrote: > Andre Oppermann wrote: > >> On 10.07.2013 15:18, Fabian Keil wrote: >>> Andre Oppermann wrote: >>> >>>> We have a SYN cookie implementation for quite some time now but it >>>> has some limitations with current realities for window scaling and >>>> SACK encoding the in the few available bits. > [...] >>>> http://people.freebsd.org/~andre/syncookie-20130708.diff >>> >>> I've been using the patch for a couple of days and didn't notice any >>> issues so far. Privoxy's regression tests continue to work as expected >>> as well. >> >> Thanks for testing and reporting back. >> >> Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1 >> as well to bypass the syn cache entirely? > > I haven't noticed any issues with net.inet.tcp.syncookies_only=1. Excellent. >> It will give a bit of debug log output which is it telling you mostly about >> rounding to the next nearest index value. You can send the output privately >> to me to spot unexpected outliers, if any. > > One unexpected outlier seems to be: Both errors are normal and a sign of lazy application behavior, not a TCP error. > Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 27 bytes of data after socket was closed, sending RST and removing tcpcb This error is not uncommon and happens when the server side has closed the socket (and sent FIN) while the client side is still trying to send data. As the server has closed the socket we can't the deliver the data anymore and respond with a reset to let the client know. It typically happens with web servers and short keep-alive timeouts. > Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) This is the same situation after the previous line but after the inpcb was cleared. Now a second, final (because of the FIN), in-flight packet from the client arrives at the listen socket because the original inpcb is gone now. Since there isn't a matching SYN cache entry it falls back to check for a syn cookie which obviously fails. Having a FIN segment reach syncache is unusual but not wrong. In theory one could send a SYN, receive the SYN-ACK and respond with ACK-FIN in one packet if it carried all data to be sent and the application did a socket write shutdown already. > Client and server are running on the same system. > > As I don't usually use net.inet.tcp.log_debug and haven't been able to intentionally > reproduce the issue (but have seen it a few times), I'm not sure yet if the behaviour > is actually related to the SYN cookie changes at all. It's "normal" behavior and not related to the SYN cookie changes. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 12:19:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C12B0D3B; Fri, 12 Jul 2013 12:19:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC2E1101; Fri, 12 Jul 2013 12:19:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CCJCIU008702; Fri, 12 Jul 2013 08:19:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CCJCfk008698; Fri, 12 Jul 2013 12:19:12 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 12:19:12 GMT Message-Id: <201307121219.r6CCJCfk008698@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:19:13 -0000 TB --- 2013-07-12 11:49:45 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 11:49:45 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 11:49:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-07-12 11:49:45 - cleaning the object tree TB --- 2013-07-12 11:50:27 - /usr/local/bin/svn stat /src TB --- 2013-07-12 11:50:30 - At svn revision 253259 TB --- 2013-07-12 11:50:31 - building world TB --- 2013-07-12 11:50:31 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 11:50:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 11:50:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 11:50:31 - SRCCONF=/dev/null TB --- 2013-07-12 11:50:31 - TARGET=ia64 TB --- 2013-07-12 11:50:31 - TARGET_ARCH=ia64 TB --- 2013-07-12 11:50:31 - TZ=UTC TB --- 2013-07-12 11:50:31 - __MAKE_CONF=/dev/null TB --- 2013-07-12 11:50:31 - cd /src TB --- 2013-07-12 11:50:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 11:50:38 UTC 2013 >>> 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 [...] /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 12:19:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 12:19:12 - ERROR: failed to build world TB --- 2013-07-12 12:19:12 - 1365.26 user 255.53 system 1767.02 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 12:44:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F6AA967; Fri, 12 Jul 2013 12:44:26 +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 D0DF612A5; Fri, 12 Jul 2013 12:44:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CCiPco084523; Fri, 12 Jul 2013 08:44:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CCiP8i084495; Fri, 12 Jul 2013 12:44:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 12:44:25 GMT Message-Id: <201307121244.r6CCiP8i084495@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:44:26 -0000 TB --- 2013-07-12 12:19:13 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 12:19:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 12:19:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-12 12:19:13 - cleaning the object tree TB --- 2013-07-12 12:19:36 - /usr/local/bin/svn stat /src TB --- 2013-07-12 12:19:39 - At svn revision 253259 TB --- 2013-07-12 12:19:40 - building world TB --- 2013-07-12 12:19:40 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 12:19:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 12:19:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 12:19:40 - SRCCONF=/dev/null TB --- 2013-07-12 12:19:40 - TARGET=sparc64 TB --- 2013-07-12 12:19:40 - TARGET_ARCH=sparc64 TB --- 2013-07-12 12:19:40 - TZ=UTC TB --- 2013-07-12 12:19:40 - __MAKE_CONF=/dev/null TB --- 2013-07-12 12:19:40 - cd /src TB --- 2013-07-12 12:19:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 12:19:46 UTC 2013 >>> 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 [...] /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 12:44:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 12:44:25 - ERROR: failed to build world TB --- 2013-07-12 12:44:25 - 1099.48 user 223.50 system 1512.12 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 12:44:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1463AA6; Fri, 12 Jul 2013 12:44: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 7FDF112B7; Fri, 12 Jul 2013 12:44:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CCitIE086258; Fri, 12 Jul 2013 08:44:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CCitrE086257; Fri, 12 Jul 2013 12:44:55 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 12:44:55 GMT Message-Id: <201307121244.r6CCitrE086257@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:44:55 -0000 TB --- 2013-07-12 12:14:43 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 12:14:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 12:14:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-07-12 12:14:43 - cleaning the object tree TB --- 2013-07-12 12:15:33 - /usr/local/bin/svn stat /src TB --- 2013-07-12 12:15:37 - At svn revision 253259 TB --- 2013-07-12 12:15:38 - building world TB --- 2013-07-12 12:15:38 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 12:15:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 12:15:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 12:15:38 - SRCCONF=/dev/null TB --- 2013-07-12 12:15:38 - TARGET=powerpc TB --- 2013-07-12 12:15:38 - TARGET_ARCH=powerpc TB --- 2013-07-12 12:15:38 - TZ=UTC TB --- 2013-07-12 12:15:38 - __MAKE_CONF=/dev/null TB --- 2013-07-12 12:15:38 - cd /src TB --- 2013-07-12 12:15:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 12:15:45 UTC 2013 >>> 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 [...] /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 12:44:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 12:44:55 - ERROR: failed to build world TB --- 2013-07-12 12:44:55 - 1375.95 user 249.68 system 1811.30 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 12:45:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5907BD0; Fri, 12 Jul 2013 12:45: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 93B9812C0; Fri, 12 Jul 2013 12:45:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CCj7Eq086612; Fri, 12 Jul 2013 08:45:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CCj7Io086611; Fri, 12 Jul 2013 12:45:07 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 12:45:07 GMT Message-Id: <201307121245.r6CCj7Io086611@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 , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:45:08 -0000 TB --- 2013-07-12 12:14:47 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 12:14:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 12:14:47 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-07-12 12:14:47 - cleaning the object tree TB --- 2013-07-12 12:15:39 - /usr/local/bin/svn stat /src TB --- 2013-07-12 12:15:42 - At svn revision 253259 TB --- 2013-07-12 12:15:43 - building world TB --- 2013-07-12 12:15:43 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 12:15:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 12:15:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 12:15:43 - SRCCONF=/dev/null TB --- 2013-07-12 12:15:43 - TARGET=powerpc TB --- 2013-07-12 12:15:43 - TARGET_ARCH=powerpc64 TB --- 2013-07-12 12:15:43 - TZ=UTC TB --- 2013-07-12 12:15:43 - __MAKE_CONF=/dev/null TB --- 2013-07-12 12:15:43 - cd /src TB --- 2013-07-12 12:15:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 12:15:50 UTC 2013 >>> 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 [...] /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'long' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'double' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'typeof' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected primary-expression before 'float' /obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no arguments to '__builtin_types_compatible_p' that depend on a template parameter, so a declaration of '__builtin_types_compatible_p' must be available *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 12:45:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 12:45:07 - ERROR: failed to build world TB --- 2013-07-12 12:45:07 - 1387.97 user 255.44 system 1819.13 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 13:18:00 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 589F73EF; Fri, 12 Jul 2013 13:18: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 09B52160E; Fri, 12 Jul 2013 13:17:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CDHxBS021570; Fri, 12 Jul 2013 09:17:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CDHxQ1021569; Fri, 12 Jul 2013 13:17:59 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 13:17:59 GMT Message-Id: <201307121317.r6CDHxQ1021569@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:18:00 -0000 TB --- 2013-07-12 11:49:38 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 11:49:38 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 11:49:38 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-07-12 11:49:38 - cleaning the object tree TB --- 2013-07-12 11:50:21 - /usr/local/bin/svn stat /src TB --- 2013-07-12 11:50:25 - At svn revision 253259 TB --- 2013-07-12 11:50:26 - building world TB --- 2013-07-12 11:50:26 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 11:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 11:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 11:50:26 - SRCCONF=/dev/null TB --- 2013-07-12 11:50:26 - TARGET=pc98 TB --- 2013-07-12 11:50:26 - TARGET_ARCH=i386 TB --- 2013-07-12 11:50:26 - TZ=UTC TB --- 2013-07-12 11:50:26 - __MAKE_CONF=/dev/null TB --- 2013-07-12 11:50:26 - cd /src TB --- 2013-07-12 11:50:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 11:50:33 UTC 2013 >>> 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 [...] ^~~~~~~~~~~~ /obj/pc98.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/pc98.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 13:17:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 13:17:59 - ERROR: failed to build world TB --- 2013-07-12 13:17:59 - 4590.70 user 534.69 system 5300.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 15:40:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F072180; Fri, 12 Jul 2013 15:40:32 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id A62571CB2; Fri, 12 Jul 2013 15:40:31 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.7/8.14.7) with ESMTP id r6CFeTbP020785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 17:40:30 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Fri, 12 Jul 2013 17:40:29 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "O. Hartmann" Subject: Re: CURRENT: Changes in lib/msun/math.h make ports to fail Message-ID: <20130712154029.GA2198@acme.spoerlein.net> Mail-Followup-To: "O. Hartmann" , FreeBSD Ports , FreeBSD CURRENT References: <20130712090231.3ccf1f08@thor.walstatt.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130712090231.3ccf1f08@thor.walstatt.dyndns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 15:40:32 -0000 On Fri, 2013-07-12 at 09:02:31 +0200, O. Hartmann wrote: > > Updating CURRENT from r253216 to r253252 triggers an updating of > several ports to fail, namely, for instance, > > www/firefox > graphiks/webkit-gtk2 > deskuitls/fbreader > graphics/gdal > > The error is in all ports when compiled with CLANG 3.3 -std=c++11 > -stdlib=libc++ similar, routing to math.h. I will show the error for > www/firefox: > > [...] > In file included from ./../../dist/include/mozilla/MathAlgorithms.h:15: > /usr/include/c++/4.2/cmath:468:44: error: __builtin_types_compatible_p > is not valid in C++ __capture_fpclassify(_Tp __f) { return > fpclassify(__f); } ^~~~~~~~~~~~~~~ > /usr/include/math.h:104:2: note: expanded from macro 'fpclassify' > __fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyl) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' > __builtin_types_compatible_p(__typeof(x), long double), > ld(x), > > > [...] > > I was wondering why /usr/include/c++/4.2/cmath gets included and not > the header provided for CLANG. I guess this is a typo/bug. I did do dig > deeper into it. > > Hope someone can fix this. It also breaks a simple buildworld. Coverity Scan broke like this: ===> gnu/lib/libstdc++ (all) c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/data/src/freebsd-head/gnu/lib/libstdc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/data/src/freebsd-head/gnu/lib/libstdc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/data/src/freebsd-head/gnu/lib/libstdc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/data/src/freebsd-head/gnu/lib/libstdc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/data/src/freebsd-head/gnu/lib/libstdc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre In file included from /data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc:53: /usr/obj/data/src/freebsd-head/tmp/usr/include/c++/4.2/cmath:468:44: error: __builtin_types_compatible_p is not valid in C++ __capture_fpclassify(_Tp __f) { return fpclassify(__f); } ^~~~~~~~~~~~~~~ /usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:104:2: note: expanded from macro 'fpclassify' __fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc:53: /usr/obj/data/src/freebsd-head/tmp/usr/include/c++/4.2/cmath:472:42: error: __builtin_types_compatible_p is not valid in C++ __capture_isfinite(_Tp __f) { return isfinite(__f); } ^~~~~~~~~~~~~ /usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:105:21: note: expanded from macro 'isfinite' #define isfinite(x) __fp_type_select(x, __isfinitef, __isfinite, __isfinitel) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and many more. From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 16:05:52 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 13CE4D09; Fri, 12 Jul 2013 16:05:52 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id C43DF1DDF; Fri, 12 Jul 2013 16:05:51 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 7193A6A6002; Fri, 12 Jul 2013 18:05:49 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id r6CG5nCV061125; Fri, 12 Jul 2013 18:05:49 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id r6CG5lq5060665; Fri, 12 Jul 2013 18:05:47 +0200 (CEST) (envelope-from lars) Date: Fri, 12 Jul 2013 18:05:47 +0200 From: Lars Engels To: David Chisnall Subject: Re: FreeBSD-head hang when shutdown by ACPI with Intel GPU and new Xorg and SandyBridge Message-ID: <20130712160547.GP88288@e-new.0x20.net> References: <1601171.hWXcdG7J9D@notebook.alkar.net> <22CEA4A9-5C63-4561-8663-42F8623F1D97@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Df9iGvjWRAzg/a8v" Content-Disposition: inline In-Reply-To: <22CEA4A9-5C63-4561-8663-42F8623F1D97@FreeBSD.org> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.4-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kevin Oberman , "freebsd-x11@freebsd.org" , FreeBSD Current , "Lundberg, Johannes" , Artyom Mirgorodskiy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 16:05:52 -0000 --Df9iGvjWRAzg/a8v Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 11:26:06AM +0100, David Chisnall wrote: > On 12 Jul 2013, at 10:01, "Lundberg, Johannes" wrote: >=20 > >> As the KMS code does not switch the display mode back, once X with KMS > > starts, you can't get a console back. > >=20 > > Is there any solution for this in the works? >=20 > Yes. ray@ is currently being funded by the FreeBSD Foundation to > improve Newcons compatibility with KMS. The Newcons framework is > designed to improve layering in the console. The machine-dependent > part simply provides a framebuffer interface, the machine-independent > part provides the terminal emulator (this also means things like > unicode in the console will work, as will higher-resolution consoles). > It's currently used on a few non-x86 platforms, but it wasn't a > priority for x86 because the PC BIOS text console mostly works and > people who want a better terminal can just run X. It's now become a > priority because of the KMS integration with X.org. Once this work is > completed, we will switch to a new X.org by default and will use the > KMS interface within the kernel for selecting the video mode. =20 Is there a rough ETA for this great improvement? --Df9iGvjWRAzg/a8v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHgKVsACgkQKc512sD3afhz9QCgkYHgZg/N0xcphDKjqPYHx2mL tfwAn21uXD+QLDxLl0yTLdi3t75tRmlN =2UVT -----END PGP SIGNATURE----- --Df9iGvjWRAzg/a8v-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 16:16:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C0DA321B; Fri, 12 Jul 2013 16:16:47 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0241E6F; Fri, 12 Jul 2013 16:16:47 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 16so21260016iea.17 for ; Fri, 12 Jul 2013 09:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=080gMjUYyiD0/PHb/kkcV71HbnZ9j2lWJ1l/2+iWDyM=; b=p0dQlnQBjlxO3/wrsnkArUdPVcRKw0V+NP1s/DtWDZJxC3SQkmlZMPMiptnwqP9Cuq NGl0n4Q3jme7BHxocXH8A0sf8Mq/BO/zulcHzka4d2FyGI9KwQ60Jci/HpxXfbiltGdP fBdbOhqA872YMuWvKuwpdEuaImMm86yLIA+QzKpVgnxckDHzTKbWPJS4LQQkCSWjyfJK 59/0DzsTo5xIAgutuhiJZV6DlD0hWM2GBwRI8NDzyA9M7tF+mXzd58j1UljRYPc9UPnM IrwusFOLdkQn7fLwaV5LXFIFYfpJ5Vyyxdpp3HdL8spphaP5QL4P3o0bYtIQL5JIrrQS hJAA== MIME-Version: 1.0 X-Received: by 10.50.57.51 with SMTP id f19mr1178741igq.26.1373645807137; Fri, 12 Jul 2013 09:16:47 -0700 (PDT) Received: by 10.50.221.179 with HTTP; Fri, 12 Jul 2013 09:16:46 -0700 (PDT) In-Reply-To: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> Date: Fri, 12 Jul 2013 11:16:46 -0500 Message-ID: Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: Scot Hetzel To: David Chisnall Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT , Garrett Wollman , "freebsd-toolchain@FreeBSD.org" , Bruce Evans , Tijl Coosemans , "freebsd-standards@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 16:16:47 -0000 On Thu, Jul 11, 2013 at 9:33 AM, David Chisnall wrote: > On 11 Jul 2013, at 13:11, Bruce Evans wrote: > >> The error message for the __builtin_isnan() version is slightly better up >> to where it says more. >> >> The less-unportable macro can do more classification and detect problems >> at compile time using __typeof(). > > The attached patch fixes the related test cases in the libc++ test suite. Please review. > #define fpclassify(x) \ - ((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \ - : (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \ - : __fpclassifyl(x)) + __fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyd) The last __fpclassifyd should be __fpclassifyl. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 17:13:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 673E1AFA; Fri, 12 Jul 2013 17:13:59 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 10CBE1118; Fri, 12 Jul 2013 17:13:59 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id u16so21061158iet.37 for ; Fri, 12 Jul 2013 10:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QiisUPirFKoVMBGknphIrRZc1nDMAFRG3tSIkRd6f4A=; b=vxMm7x7CcKMfsBiyJzfiOWrjLS025G2jU91bPy+W96nfW9qdCgS9Xw2/DSv+X0SCDb goeFjw/mOmVXX3usiEu1nAVePgNC1I6223OMcOpKWPqRzWc5q7PVNFI0+QYFGlg3kUZC ggLyEeaIXiPbojCUchcVEYkwn7v5YnqwoP7UN+H/MgQgcHRkgt2m0J+I5DYPwVVHkVcN Ct6HMwonTcyBHk8P4lQYoYdW41t6zF9dc10dOCjRECmfC1YjXNVjM6BND8Jsioc5WHRz Qv1suFDojub+xZ9OagB/FmqcP18QB1oBMnyH3u2o2XKuXpKxm6YymlcvdN1sUjCXdNRd mSzA== MIME-Version: 1.0 X-Received: by 10.50.67.43 with SMTP id k11mr1242994igt.26.1373649238734; Fri, 12 Jul 2013 10:13:58 -0700 (PDT) Received: by 10.50.221.179 with HTTP; Fri, 12 Jul 2013 10:13:58 -0700 (PDT) In-Reply-To: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> Date: Fri, 12 Jul 2013 12:13:58 -0500 Message-ID: Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: Scot Hetzel To: David Chisnall Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT , Garrett Wollman , "freebsd-toolchain@FreeBSD.org" , Bruce Evans , Tijl Coosemans , "freebsd-standards@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 17:13:59 -0000 On Fri, Jul 12, 2013 at 11:16 AM, Scot Hetzel wrote: > On Thu, Jul 11, 2013 at 9:33 AM, David Chisnall wrote: >> On 11 Jul 2013, at 13:11, Bruce Evans wrote: >> >>> The error message for the __builtin_isnan() version is slightly better up >>> to where it says more. >>> >>> The less-unportable macro can do more classification and detect problems >>> at compile time using __typeof(). >> >> The attached patch fixes the related test cases in the libc++ test suite. Please review. >> > > #define fpclassify(x) \ > - ((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \ > - : (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \ > - : __fpclassifyl(x)) > + __fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyd) > > The last __fpclassifyd should be __fpclassifyl. > I see it has already been fixed. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 18:17:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C4C50D47; Fri, 12 Jul 2013 18:17:56 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 24A1316C8; Fri, 12 Jul 2013 18:17:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id 40C072A832EB; Fri, 12 Jul 2013 20:11:41 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcgW9ocpDz9X; Fri, 12 Jul 2013 20:11:39 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id BFCAE2A83299; Fri, 12 Jul 2013 20:11:38 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uxhoe-0000d9-Sc; Fri, 12 Jul 2013 20:11:36 +0200 To: John Baldwin From: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 In-Reply-To: <201307110923.06548.jhb@freebsd.org> References: <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> X-Attribution: BOFH Date: Fri, 12 Jul 2013 20:11:36 +0200 Message-Id: Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 18:17:56 -0000 John Baldwin wrote: > On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: > > John Baldwin wrote: > > > On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: > > > > Konstantin Belousov wrote: > > > > > > > > > > Care to provide any useful information ? > > > > > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- > > > handbook/kerneldebug-deadlocks.html > > > > > > > > Well, the system doesn't deadlock it's perfectly useable so long > > > > as you don't touch the file that's wedged. A lot of the time the > > > > userland process is unkillable, but often it is killable. How do > > > > I get from from the PID to where the FS is stuck in the kernel? > > > > > > Use kgdb. 'proc ', then 'bt'. > > > > So, I setup a remote kbgd session, but I still can't figure out how > > to get at the information we need. > > > > (kgdb) proc 5176 > > only supported for core file target > > > > In the mean time, I'll just force it to make a core dump from ddb. > > However, I can't reacreate the issue while the mirror (gmirror) is > > rebuilding, so we'll have to wait for that to finish. > > Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the running > kernel without having to stop it. So, this machine's installworld *always* stalls installing clang. The install can be stopped (ctrl-c) leaving behind this process: root 23147 0.0 0.0 9268 1512 1 D 7:51PM 0:00.01 install -s -o root -g wheel -m 555 clang /usr/bin/clang This is the backtrace from gdb. I suspect frame 4. (kgdb) proc 23147 [Switching to thread 117 (Thread 100059)]#0 sched_switch ( td=0xfffffe000c012920, newtd=0x0, flags=) at /usr/src/sys/kern/sched_ule.c:1954 1954 cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfffffe000c012920, newtd=0x0, flags=) at /usr/src/sys/kern/sched_ule.c:1954 #1 0xffffffff8047539e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0xffffffff804acbea in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0xffffffff80474ee9 in _sleep (ident=, lock=0xffffffff80a20300, priority=84, wmesg=0xffffffff8071129a "wdrain", sbt=, pr=0, flags=) at /usr/src/sys/kern/kern_synch.c:249 #4 0xffffffff804e6523 in waitrunningbufspace () at /usr/src/sys/kern/vfs_bio.c:564 #5 0xffffffff804e6073 in bufwrite (bp=) at /usr/src/sys/kern/vfs_bio.c:1226 #6 0xffffffff804f05ed in cluster_wbuild (vp=0xfffffe008fec4000, size=32768, start_lbn=136, len=, gbflags=) at /usr/src/sys/kern/vfs_cluster.c:1002 #7 0xffffffff804efbc3 in cluster_write (vp=0xfffffe008fec4000, bp=0xffffff80f83da6f0, filesize=4456448, seqcount=127, gbflags=) at /usr/src/sys/kern/vfs_cluster.c:592 #8 0xffffffff805c1032 in ffs_write (ap=0xffffff8121c81850) at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 #9 0xffffffff8067fe21 in VOP_WRITE_APV (vop=, ---Type to continue, or q to quit--- a=) at vnode_if.c:999 #10 0xffffffff80511eca in vn_write (fp=0xfffffe006a5f7410, uio=0xffffff8121c81a90, active_cred=0x0, flags=, td=0x0) at vnode_if.h:413 #11 0xffffffff8050eb3a in vn_io_fault (fp=0xfffffe006a5f7410, uio=0xffffff8121c81a90, active_cred=0xfffffe006a6ca000, flags=0, td=0xfffffe000c012920) at /usr/src/sys/kern/vfs_vnops.c:983 #12 0xffffffff804b506a in dofilewrite (td=0xfffffe000c012920, fd=5, fp=0xfffffe006a5f7410, auio=0xffffff8121c81a90, offset=, flags=0) at file.h:290 #13 0xffffffff804b4cde in sys_write (td=0xfffffe000c012920, uap=) at /usr/src/sys/kern/sys_generic.c:460 #14 0xffffffff8061807a in amd64_syscall (td=0xfffffe000c012920, traced=0) at subr_syscall.c:134 #15 0xffffffff806017ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #16 0x000000000044e75a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Any other process attempting to for instance stat /usr/bin/clang also gets stuck: root 23198 0.0 0.0 8056 1780 1 D+ 7:58PM 0:00.00 stat /usr/bin/clang #0 sched_switch (td=0xffffffff80a67b20, newtd=0x0, flags=) at /usr/src/sys/kern/sched_ule.c:1954 1954 cpuid = PCPU_GET(cpuid); (kgdb) proc 23198 [Switching to thread 107 (Thread 100131)]#0 sched_switch ( td=0xfffffe000ce9a000, newtd=0x0, flags=) at /usr/src/sys/kern/sched_ule.c:1954 1954 cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfffffe000ce9a000, newtd=0x0, flags=) at /usr/src/sys/kern/sched_ule.c:1954 #1 0xffffffff8047539e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0xffffffff804acbea in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0xffffffff804542bc in sleeplk (lk=, flags=2097408, ilk=, wmesg=0xffffffff807017be "ufs", pri=, timo=) at /usr/src/sys/kern/kern_lock.c:226 #4 0xffffffff80453b09 in __lockmgr_args (lk=0xfffffe008fec4068, flags=, ilk=0xfffffe008fec4130, wmesg=0xffffffff807017be "ufs", pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:672 #5 0xffffffff805c1384 in ffs_lock (ap=0xffffff8121de9460) at lockmgr.h:97 #6 0xffffffff80680f4a in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2084 #7 0xffffffff8050fd33 in _vn_lock (vp=0xfffffe008fec4000, flags=, file=0xffffffff807134e1 "/usr/src/sys/kern/vfs_subr.c", line=2099) at vnode_if.h:859 #8 0xffffffff804ff5aa in vget (vp=0xfffffe008fec4000, flags=2097408, td=0xfffffe000ce9a000) at /usr/src/sys/kern/vfs_subr.c:2099 #9 0xffffffff804f4343 in vfs_hash_get (mp=0xfffffe000c736790, hash=7624857, flags=, td=0xfffffe000ce9a000, vpp=0xffffff8121de9680, fn=0) at /usr/src/sys/kern/vfs_hash.c:88 #10 0xffffffff805bc861 in ffs_vgetf (mp=0xfffffe000c736790, ino=7624857, flags=2097152, vpp=0xffffff8121de9680, ffs_flags=0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1672 #11 0xffffffff805c8029 in ufs_lookup_ino (vdp=0xfffffe000c869750, vpp=0xffffff8121de99b0, cnp=0xffffff8121de99d8, dd_ino=0x0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:749 #12 0xffffffff8067f1ac in VOP_CACHEDLOOKUP_APV (vop=, a=) at vnode_if.c:197 #13 0xffffffff804ede7f in vfs_cache_lookup (ap=) at vnode_if.h:80 #14 0xffffffff8067f08c in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:129 #15 0xffffffff804f594c in lookup (ndp=0xffffff8121de9958) at vnode_if.h:54 #16 0xffffffff804f5144 in namei (ndp=0xffffff8121de9958) at /usr/src/sys/kern/vfs_lookup.c:292 #17 0xffffffff8050ae85 in kern_statat_vnhook (td=0xfffffe000ce9a000, flag=, fd=0, path=0x0, pathseg=UIO_USERSPACE, sbp=0xffffff8121de9a60, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2322 #18 0xffffffff8050af70 in sys_lstat (td=0x0, uap=0xffffff8121de9b80) at /usr/src/sys/kern/vfs_syscalls.c:2303 #19 0xffffffff8061807a in amd64_syscall (td=0xfffffe000ce9a000, traced=0) at subr_syscall.c:134 #20 0xffffffff806017ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #21 0x00000008009355da in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) We've tried different disks and different servers, and they all fail the same way. It appears peculiar to amd64 since all our i386 seems unaffected. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 20:11:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5105CFA; Fri, 12 Jul 2013 20:11:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 558B21CC3; Fri, 12 Jul 2013 20:11:00 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6CKApX5049241; Fri, 12 Jul 2013 23:10:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6CKApX5049241 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6CKApU5049239; Fri, 12 Jul 2013 23:10:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jul 2013 23:10:51 +0300 From: Konstantin Belousov To: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 Message-ID: <20130712201051.GI91021@kib.kiev.ua> References: <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rMuTkhzRlt+HYtLC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 20:11:01 -0000 --rMuTkhzRlt+HYtLC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 08:11:36PM +0200, Ian FREISLICH wrote: > John Baldwin wrote: > > On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: > > > John Baldwin wrote: > > > > On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: > > > > > Konstantin Belousov wrote: > > > > > >=20 > > > > > > Care to provide any useful information ? > > > > > >=20 > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- > > > > handbook/kerneldebug-deadlocks.html > > > > >=20 > > > > > Well, the system doesn't deadlock it's perfectly useable so long > > > > > as you don't touch the file that's wedged. A lot of the time the > > > > > userland process is unkillable, but often it is killable. How do > > > > > I get from from the PID to where the FS is stuck in the kernel? > > > >=20 > > > > Use kgdb. 'proc ', then 'bt'. > > >=20 > > > So, I setup a remote kbgd session, but I still can't figure out how > > > to get at the information we need. > > >=20 > > > (kgdb) proc 5176 > > > only supported for core file target > > >=20 > > > In the mean time, I'll just force it to make a core dump from ddb. > > > However, I can't reacreate the issue while the mirror (gmirror) is > > > rebuilding, so we'll have to wait for that to finish. > >=20 > > Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the ru= nning > > kernel without having to stop it. >=20 > So, this machine's installworld *always* stalls installing clang. > The install can be stopped (ctrl-c) leaving behind this process: >=20 > root 23147 0.0 0.0 9268 1512 1 D 7:51PM 0:00.01 install -= s -o root -g wheel -m 555 clang /usr/bin/clang >=20 > This is the backtrace from gdb. I suspect frame 4. >=20 > (kgdb) proc 23147 > [Switching to thread 117 (Thread 100059)]#0 sched_switch ( > td=3D0xfffffe000c012920, newtd=3D0x0, flags=3D) > at /usr/src/sys/kern/sched_ule.c:1954 > 1954 cpuid =3D PCPU_GET(cpuid); > Current language: auto; currently minimal > (kgdb) bt > #0 sched_switch (td=3D0xfffffe000c012920, newtd=3D0x0,=20 > flags=3D) at /usr/src/sys/kern/sched_ule.c:1954 > #1 0xffffffff8047539e in mi_switch (flags=3D260, newtd=3D0x0) > at /usr/src/sys/kern/kern_synch.c:487 > #2 0xffffffff804acbea in sleepq_wait (wchan=3D0x0, pri=3D0) > at /usr/src/sys/kern/subr_sleepqueue.c:620 > #3 0xffffffff80474ee9 in _sleep (ident=3D,=20 > lock=3D0xffffffff80a20300, priority=3D84, wmesg=3D0xffffffff8071129a = "wdrain",=20 > sbt=3D, pr=3D0, flags=3D) > at /usr/src/sys/kern/kern_synch.c:249 > #4 0xffffffff804e6523 in waitrunningbufspace () > at /usr/src/sys/kern/vfs_bio.c:564 > #5 0xffffffff804e6073 in bufwrite (bp=3D) > at /usr/src/sys/kern/vfs_bio.c:1226 > #6 0xffffffff804f05ed in cluster_wbuild (vp=3D0xfffffe008fec4000, size= =3D32768,=20 > start_lbn=3D136, len=3D, gbflags=3D) > at /usr/src/sys/kern/vfs_cluster.c:1002 > #7 0xffffffff804efbc3 in cluster_write (vp=3D0xfffffe008fec4000,=20 > bp=3D0xffffff80f83da6f0, filesize=3D4456448, seqcount=3D127,=20 > gbflags=3D) at /usr/src/sys/kern/vfs_cluster.c:5= 92 > #8 0xffffffff805c1032 in ffs_write (ap=3D0xffffff8121c81850) > at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 > #9 0xffffffff8067fe21 in VOP_WRITE_APV (vop=3D,=20 > ---Type to continue, or q to quit---=20 > a=3D) at vnode_if.c:999 > #10 0xffffffff80511eca in vn_write (fp=3D0xfffffe006a5f7410,=20 > uio=3D0xffffff8121c81a90, active_cred=3D0x0, flags=3D,=20 > td=3D0x0) at vnode_if.h:413 > #11 0xffffffff8050eb3a in vn_io_fault (fp=3D0xfffffe006a5f7410,=20 > uio=3D0xffffff8121c81a90, active_cred=3D0xfffffe006a6ca000, flags=3D0= ,=20 > td=3D0xfffffe000c012920) at /usr/src/sys/kern/vfs_vnops.c:983 > #12 0xffffffff804b506a in dofilewrite (td=3D0xfffffe000c012920, fd=3D5,= =20 > fp=3D0xfffffe006a5f7410, auio=3D0xffffff8121c81a90,=20 > offset=3D, flags=3D0) at file.h:290 > #13 0xffffffff804b4cde in sys_write (td=3D0xfffffe000c012920,=20 > uap=3D) at /usr/src/sys/kern/sys_generic.c:460 > #14 0xffffffff8061807a in amd64_syscall (td=3D0xfffffe000c012920, traced= =3D0) > at subr_syscall.c:134 > #15 0xffffffff806017ab in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:387 > #16 0x000000000044e75a in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb)=20 Please apply (mostly debugging) patch below, then reproduce the issue. I need the backtrace of the 'main' hung process, assuming it is stuck in the waitrunningbufspace(). Also, from the same kgdb session, print runningbufreq, runningbufspace and lorunningspace. diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index 68021e0..205e9b3 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -474,10 +474,12 @@ runningbufwakeup(struct buf *bp) { long space, bspace; =20 - if (bp->b_runningbufspace =3D=3D 0) - return; - space =3D atomic_fetchadd_long(&runningbufspace, -bp->b_runningbufspace); bspace =3D bp->b_runningbufspace; + if (bspace =3D=3D 0) + return; + space =3D atomic_fetchadd_long(&runningbufspace, -bspace); + KASSERT(space >=3D bspace, ("runningbufspace underflow %ld %ld", + space, bspace)); bp->b_runningbufspace =3D 0; /* * Only acquire the lock and wakeup on the transition from exceeding @@ -561,7 +563,7 @@ waitrunningbufspace(void) =20 mtx_lock(&rbreqlock); while (runningbufspace > hirunningspace) { - ++runningbufreq; + runningbufreq =3D 1; msleep(&runningbufreq, &rbreqlock, PVM, "wdrain", 0); } mtx_unlock(&rbreqlock); --rMuTkhzRlt+HYtLC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4GLKAAoJEJDCuSvBvK1BQPYP/3tj9KA9tIg+4DtJq2Otehji juvxbqQKxttj6Cdr6hE4vv63qUGE2K0iCtKvlkEIG60AS3jBMha4gEZxVbrYZEE4 i3HgF0PTqY4SRCzCJ4cHBul7c6Dwxce1A+l+NdGakssYgi2bgX9NI/7kJf7mSFZs vPs6q3GuOuAqyxbaltOiFF/1NR+y1QZdriJSCOORYKL4bwB2ZTiUTJtakJdhOKn9 1XXtunxbFZqjjoA6zHz7uJdIBNSBkp4rgUEhho8wjTvS0/5Ku1bhVW+1TS6DkKp3 w2X0Zlcx3O9JFwsBKEuqPwp2E7u4l7+CA8U89/q7ba6EwWV3a8Emh7wdDcY86CKM y5/oaclz5xVu4Nef81LYGmLdwa6w16w7Zg6VV9gu3jnb4alPzDjN0wdNu5uusPPw i1XDexk32XPmXXCljdW8KWfcdQ7pMk4H2sX0r/Hp1cFOmc+68Snpm2ODiQEGfJDQ DWYrZWVMoLXIRK7dsBTyKrLTq06vwcdUJZlESivbST24vQF9Ehfbs2nHCvi4jYi8 q/Kuoeyp8p2vPawXONnQKMZtipVspG4uoY/Lei83L3cakvn3N9FbiPcuyoVN92SD CFkCLx8a8qXn1HY+Js9qCZOfNFLhas4XtqsGp6xv3pR93JIfEi4yxF/wozs2XbRn q+gm6hr+ueyCtENxFZFU =foli -----END PGP SIGNATURE----- --rMuTkhzRlt+HYtLC-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 20:54:48 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F2B2577; Fri, 12 Jul 2013 20:54:48 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 40FD91E5C; Fri, 12 Jul 2013 20:54:48 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.7/8.14.7) with ESMTP id r6CKsksn026842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 22:54:46 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Fri, 12 Jul 2013 22:54:46 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org, mav@FreeBSD.org Subject: Sound lag over HDMI Message-ID: <20130712205446.GB2198@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org, mav@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 20:54:48 -0000 Hey, I'm trying to setup XBMC on a -CURRENT box with an IvyBridge CPU and GPU. While testing playback via mplayer on a LG TV over HDMI, I noticed that sound is lagging video by about 100-200ms or so. When I switch to using the jack outputs powered by some Realtek chip, audio is perfectly fine. Is HDMI lag a known problem? Can this be fixed? root@coyote:~# dmesg | egrep vgapci\|pcm vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xc0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 pcm0: at nid 20 and 24 on hdaa0 pcm1: at nid 30 and 31 on hdaa0 pcm2: at nid 6 on hdaa1 pcm3: at nid 7 on hdaa1 drmn0: on vgapci0 Cheers, Uli From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 21:34:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F035D4A8; Fri, 12 Jul 2013 21:34:31 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 49A551066; Fri, 12 Jul 2013 21:34:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id C5EBD2B432CD; Fri, 12 Jul 2013 23:34:22 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1CIrIhdCLax; Fri, 12 Jul 2013 23:34:21 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 617C02B43218; Fri, 12 Jul 2013 23:34:21 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uxkyo-0002mE-MJ; Fri, 12 Jul 2013 23:34:18 +0200 To: Konstantin Belousov From: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 In-Reply-To: <20130712201051.GI91021@kib.kiev.ua> References: <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> X-Attribution: BOFH Date: Fri, 12 Jul 2013 23:34:18 +0200 Message-Id: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 21:34:32 -0000 Konstantin Belousov wrote: > > --rMuTkhzRlt+HYtLC > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Jul 12, 2013 at 08:11:36PM +0200, Ian FREISLICH wrote: > > John Baldwin wrote: > > > On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: > > > > John Baldwin wrote: > > > > > On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: > > > > > > Konstantin Belousov wrote: > > > > > > >=20 > > > > > > > Care to provide any useful information ? > > > > > > >=20 > > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- > > > > > handbook/kerneldebug-deadlocks.html > > > > > >=20 > > > > > > Well, the system doesn't deadlock it's perfectly useable so long > > > > > > as you don't touch the file that's wedged. A lot of the time the > > > > > > userland process is unkillable, but often it is killable. How do > > > > > > I get from from the PID to where the FS is stuck in the kernel? > > > > >=20 > > > > > Use kgdb. 'proc ', then 'bt'. > > > >=20 > > > > So, I setup a remote kbgd session, but I still can't figure out how > > > > to get at the information we need. > > > >=20 > > > > (kgdb) proc 5176 > > > > only supported for core file target > > > >=20 > > > > In the mean time, I'll just force it to make a core dump from ddb. > > > > However, I can't reacreate the issue while the mirror (gmirror) is > > > > rebuilding, so we'll have to wait for that to finish. > > >=20 > > > Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the ru= > nning > > > kernel without having to stop it. > >=20 > > So, this machine's installworld *always* stalls installing clang. > > The install can be stopped (ctrl-c) leaving behind this process: > >=20 > > root 23147 0.0 0.0 9268 1512 1 D 7:51PM 0:00.01 install -= > s -o root -g wheel -m 555 clang /usr/bin/clang > >=20 > > This is the backtrace from gdb. I suspect frame 4. > >=20 > > (kgdb) proc 23147 > > [Switching to thread 117 (Thread 100059)]#0 sched_switch ( > > td=3D0xfffffe000c012920, newtd=3D0x0, flags=3D) > > at /usr/src/sys/kern/sched_ule.c:1954 > > 1954 cpuid =3D PCPU_GET(cpuid); > > Current language: auto; currently minimal > > (kgdb) bt > > #0 sched_switch (td=3D0xfffffe000c012920, newtd=3D0x0,=20 > > flags=3D) at /usr/src/sys/kern/sched_ule.c:1954 > > #1 0xffffffff8047539e in mi_switch (flags=3D260, newtd=3D0x0) > > at /usr/src/sys/kern/kern_synch.c:487 > > #2 0xffffffff804acbea in sleepq_wait (wchan=3D0x0, pri=3D0) > > at /usr/src/sys/kern/subr_sleepqueue.c:620 > > #3 0xffffffff80474ee9 in _sleep (ident=3D,=20 > > lock=3D0xffffffff80a20300, priority=3D84, wmesg=3D0xffffffff8071129a = > "wdrain",=20 > > sbt=3D, pr=3D0, flags=3D) > > at /usr/src/sys/kern/kern_synch.c:249 > > #4 0xffffffff804e6523 in waitrunningbufspace () > > at /usr/src/sys/kern/vfs_bio.c:564 > > #5 0xffffffff804e6073 in bufwrite (bp=3D) > > at /usr/src/sys/kern/vfs_bio.c:1226 > > #6 0xffffffff804f05ed in cluster_wbuild (vp=3D0xfffffe008fec4000, size= > =3D32768,=20 > > start_lbn=3D136, len=3D, gbflags=3D zed out>) > > at /usr/src/sys/kern/vfs_cluster.c:1002 > > #7 0xffffffff804efbc3 in cluster_write (vp=3D0xfffffe008fec4000,=20 > > bp=3D0xffffff80f83da6f0, filesize=3D4456448, seqcount=3D127,=20 > > gbflags=3D) at /usr/src/sys/kern/vfs_cluster.c:5= > 92 > > #8 0xffffffff805c1032 in ffs_write (ap=3D0xffffff8121c81850) > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 > > #9 0xffffffff8067fe21 in VOP_WRITE_APV (vop=3D,=20 > > ---Type to continue, or q to quit---=20 > > a=3D) at vnode_if.c:999 > > #10 0xffffffff80511eca in vn_write (fp=3D0xfffffe006a5f7410,=20 > > uio=3D0xffffff8121c81a90, active_cred=3D0x0, flags=3D out>,=20 > > td=3D0x0) at vnode_if.h:413 > > #11 0xffffffff8050eb3a in vn_io_fault (fp=3D0xfffffe006a5f7410,=20 > > uio=3D0xffffff8121c81a90, active_cred=3D0xfffffe006a6ca000, flags=3D0= > ,=20 > > td=3D0xfffffe000c012920) at /usr/src/sys/kern/vfs_vnops.c:983 > > #12 0xffffffff804b506a in dofilewrite (td=3D0xfffffe000c012920, fd=3D5,= > =20 > > fp=3D0xfffffe006a5f7410, auio=3D0xffffff8121c81a90,=20 > > offset=3D, flags=3D0) at file.h:290 > > #13 0xffffffff804b4cde in sys_write (td=3D0xfffffe000c012920,=20 > > uap=3D) at /usr/src/sys/kern/sys_generic.c:460 > > #14 0xffffffff8061807a in amd64_syscall (td=3D0xfffffe000c012920, traced= > =3D0) > > at subr_syscall.c:134 > > #15 0xffffffff806017ab in Xfast_syscall () > > at /usr/src/sys/amd64/amd64/exception.S:387 > > #16 0x000000000044e75a in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb)=20 > > Please apply (mostly debugging) patch below, then reproduce the issue. > I need the backtrace of the 'main' hung process, assuming it is stuck > in the waitrunningbufspace(). Also, from the same kgdb session, print > runningbufreq, runningbufspace and lorunningspace. This is the hung process after applying the patch. I see no console messages on recreating the issue. (kgdb) proc 23113 [Switching to thread 102 (Thread 100146)]#0 sched_switch ( td=0xfffffe006971e000, newtd=0x0, flags=) at /usr/src/sys/kern/sched_ule.c:1954 1954 cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfffffe006971e000, newtd=0x0, flags=) at /usr/src/sys/kern/sched_ule.c:1954 #1 0xffffffff8047539e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0xffffffff804acbea in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0xffffffff80474ee9 in _sleep (ident=, lock=0xffffffff80a20300, priority=84, wmesg=0xffffffff8071129a "wdrain", sbt=, pr=0, flags=) at /usr/src/sys/kern/kern_synch.c:249 #4 0xffffffff804e6527 in waitrunningbufspace () at /usr/src/sys/kern/vfs_bio.c:566 #5 0xffffffff804e6073 in bufwrite (bp=) at /usr/src/sys/kern/vfs_bio.c:1228 #6 0xffffffff804f05ed in cluster_wbuild (vp=0xfffffe007f90d750, size=32768, start_lbn=825, len=, gbflags=) at /usr/src/sys/kern/vfs_cluster.c:1002 #7 0xffffffff804efbc3 in cluster_write (vp=0xfffffe007f90d750, bp=0xffffff80f86bcd90, filesize=27033600, seqcount=127, gbflags=) at /usr/src/sys/kern/vfs_cluster.c:592 #8 0xffffffff805c1032 in ffs_write (ap=0xffffff8121e34850) at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 #9 0xffffffff8067fe21 in VOP_WRITE_APV (vop=, ---Type to continue, or q to quit--- a=) at vnode_if.c:999 #10 0xffffffff80511eca in vn_write (fp=0xfffffe000ccb5870, uio=0xffffff8121e34a90, active_cred=0x0, flags=, td=0x0) at vnode_if.h:413 #11 0xffffffff8050eb3a in vn_io_fault (fp=0xfffffe000ccb5870, uio=0xffffff8121e34a90, active_cred=0xfffffe000cf28800, flags=0, td=0xfffffe006971e000) at /usr/src/sys/kern/vfs_vnops.c:983 #12 0xffffffff804b506a in dofilewrite (td=0xfffffe006971e000, fd=5, fp=0xfffffe000ccb5870, auio=0xffffff8121e34a90, offset=, flags=0) at file.h:290 #13 0xffffffff804b4cde in sys_write (td=0xfffffe006971e000, uap=) at /usr/src/sys/kern/sys_generic.c:460 #14 0xffffffff8061807a in amd64_syscall (td=0xfffffe006971e000, traced=0) at subr_syscall.c:134 #15 0xffffffff806017ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #16 0x000000000044e75a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 4 #4 0xffffffff804e6527 in waitrunningbufspace () at /usr/src/sys/kern/vfs_bio.c:566 566 msleep(&runningbufreq, &rbreqlock, PVM, "wdrain", 0); (kgdb) print runningbufreq $1 = 1 (kgdb) print runningbufspace $2 = 0 (kgdb) print lorunningspace $3 = 4587520 (kgdb) print hirunningspace $4 = 4194304 -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 21:38:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9CEE478C; Fri, 12 Jul 2013 21:38:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by mx1.freebsd.org (Postfix) with ESMTP id EBDDD10AF; Fri, 12 Jul 2013 21:38:43 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id 10so7879960lbf.8 for ; Fri, 12 Jul 2013 14:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3WknHIWlEzQB4+/EE3g4+BQfoTH9BUTnUA+qSBpdZ1Q=; b=M1y0M8Ua4b/aG8b4/FXjeubGN8yUxeywsQH4212f1YdyxuOOQZVnJhM7w/bHlgKaGG P+qe8JK3nsDcjjD9AxzkZpaYWteQng+JIqHghNR/7rAvBE2vRMOzvz+JbccYP1NAEPtu SUjCTk6GxWcTB5h97N1D3okUjSiFMRSBXbs0T4c8AAAqlKwKJUGdU01n74dQFlOEZ6Bm UwCkBkqWoAhIo/8okh90pqRgTMtVZjcDLV34oq64hBvqBZiPkRsXu04zD25pegqbMVuS WeACh/Q0mM9O0okuTdqwaK+ck9rJ9/6jK/9wew0SSvMVVyTI17xRhN48A3P4/YQRNMEl HR9A== X-Received: by 10.112.13.199 with SMTP id j7mr20506551lbc.25.1373665122774; Fri, 12 Jul 2013 14:38:42 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id v18sm14576964lbd.5.2013.07.12.14.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 14:38:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <51E0775F.3070805@FreeBSD.org> Date: Sat, 13 Jul 2013 00:38:39 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: uqs@FreeBSD.org Subject: Re: Sound lag over HDMI References: <20130712205446.GB2198@acme.spoerlein.net> In-Reply-To: <20130712205446.GB2198@acme.spoerlein.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 21:38:44 -0000 On 12.07.2013 23:54, Ulrich Spörlein wrote: > I'm trying to setup XBMC on a -CURRENT box with an IvyBridge CPU and > GPU. While testing playback via mplayer on a LG TV over HDMI, I noticed > that sound is lagging video by about 100-200ms or so. When I switch to > using the jack outputs powered by some Realtek chip, audio is perfectly > fine. > > Is HDMI lag a known problem? Can this be fixed? > > root@coyote:~# dmesg | egrep vgapci\|pcm > vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xc0000000-0xdfffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > pcm0: at nid 20 and 24 on hdaa0 > pcm1: at nid 30 and 31 on hdaa0 > pcm2: at nid 6 on hdaa1 > pcm3: at nid 7 on hdaa1 > drmn0: on vgapci0 I don't know what to say. I am now using HDMI audio from NVIDIA card to quite old external 5.1 receiver with XBMC every day, and I haven't noticed lags. Before that I've also successfully used SPDIF connection for the long time. Though I've never specially tested it somehow other then watching movies. :) If you have some good testing methodology -- please, welcome to share. By the HDA driver HDMI is handled exactly the same way as analog output from the point of data buffering, so I would not expect there major differences. You may try to experiment with hw.snd.latency sysctl to tune buffering in kernel to see whether it affect the result. Also you may compare delays when doing AC3/DTS pass-through with case of software decoding and discrete (multichannel) PCM playback. The only potentially related effect I have noticed is that my receiver eats first second or about that of playback stream. It makes short sounds like GUI event notifications inaudible sometimes. I guess that could be made to restore audio sync after some unavoidable startup delay, but that is only my guess. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 21:48:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 92EA298C; Fri, 12 Jul 2013 21:48:01 +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 399A71114; Fri, 12 Jul 2013 21:48:00 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UxlC2-002rxb-V6>; Fri, 12 Jul 2013 23:47:59 +0200 Received: from g231188215.adsl.alicedsl.de ([92.231.188.215] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UxlC2-003DTm-Px>; Fri, 12 Jul 2013 23:47:58 +0200 Date: Fri, 12 Jul 2013 23:47:49 +0200 From: "O. Hartmann" To: Scot Hetzel Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity Message-ID: <20130712234749.5afa3c9b@thor.walstatt.dyndns.org> In-Reply-To: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ZSAD9CXLaxRHx01iUtdTl3B"; protocol="application/pgp-signature" X-Originating-IP: 92.231.188.215 Cc: David Chisnall , "freebsd-toolchain@FreeBSD.org" , Garrett Wollman , FreeBSD CURRENT , Bruce Evans , Tijl Coosemans , "freebsd-standards@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 21:48:01 -0000 --Sig_/ZSAD9CXLaxRHx01iUtdTl3B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 12 Jul 2013 12:13:58 -0500 Scot Hetzel wrote: > On Fri, Jul 12, 2013 at 11:16 AM, Scot Hetzel > wrote: > > On Thu, Jul 11, 2013 at 9:33 AM, David Chisnall > > wrote: > >> On 11 Jul 2013, at 13:11, Bruce Evans wrote: > >> > >>> The error message for the __builtin_isnan() version is slightly > >>> better up to where it says more. > >>> > >>> The less-unportable macro can do more classification and detect > >>> problems at compile time using __typeof(). > >> > >> The attached patch fixes the related test cases in the libc++ test > >> suite. Please review. > >> > > > > #define fpclassify(x) \ > > - ((sizeof (x) =3D=3D sizeof (float)) ? __fpclassifyf(x) \ > > - : (sizeof (x) =3D=3D sizeof (double)) ? __fpclassifyd(x) \ > > - : __fpclassifyl(x)) > > + __fp_type_select(x, __fpclassifyf, __fpclassifyd, > > __fpclassifyd) > > > > The last __fpclassifyd should be __fpclassifyl. > > > I see it has already been fixed. >=20 >=20 Obviously not really fixed, but even worse: if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64 revision 253287) isnan(x) where x is a "const double", I receive now the following error (which doesn't appear on previous versions): [...] Making all in scaling /bin/sh ../../libtool --tag=3DCC --mode=3Dcompile cc -DHAVE_CONFIG_H -I. -I../.. -I. -I../ -I/usr/local/include -O0 -march=3Dnative -g -pipe -DHAVE_INLINE -g -O2 -MT libscaling_la-scalingTransientCroft.lo -MD -MP -MF .deps/libscaling_la-scalingTransientCroft.Tpo -c -o libscaling_la-scalingTransientCroft.lo `test -f 'scalingTransientCroft.c' || echo './'`scalingTransientCroft.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I../.. -I. -I../ -I/usr/local/include -O0 -march=3Dnative -g -pipe -DHAVE_INLINE -g -O2 -MT libscaling_la-scalingTransientCroft.lo -MD -MP -MF .deps/libscaling_la-scalingTransientCroft.Tpo -c scalingTransientCroft.c -o libscaling_la-scalingTransientCroft.o scalingTransientCroft.c:48:12: error: controlling expression type 'const double' not compatible with any generic association type if (isnan(Dsg) || isnan(Dsc)) ^~~ /usr/include/math.h:109:19: note: expanded from macro 'isnan' __fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl) ^ /usr/include/math.h:86:49: note: expanded from macro '__fp_type_select' #define __fp_type_select(x, f, d, ld) _Generic((x),=20 [...] The variables in question (Dsg and Dsc) are of type "const double". --Sig_/ZSAD9CXLaxRHx01iUtdTl3B Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJR4HmNAAoJEOgBcD7A/5N8l/QH/35RmvVTNDC6a4uuInnSk27p eCprNuBQBFJvRVOAsNk22JmwNwH3MaKoSCbWQ8kaek0FMZiIL8CqZnujst+ONi5j 4rS5x1YTNlZrgl2vA/k0kdXbxXBb9gU7vbxGPGhwV+URo+zF5Fxbp/bq5+DIU+qQ 1sBGwv3gKFXsDqAUJ+Fhb/8u7V8NtyLwJLHlqVCpMFYMopeChw/936tATSeZZKkj iCU71toRC8ErBpVGQGHzhLde7GfI4RFhCJMPCFp/Iv/87Dia5DeGNz3xk35BzodG CF7sXwAowQJbv6ff4NLy/EfCxI6b0rZOrUQ7M8MvxKMh0MTt9bsomftaAwDGFB0= =/XUd -----END PGP SIGNATURE----- --Sig_/ZSAD9CXLaxRHx01iUtdTl3B-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 23:16:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01B67AEA; Fri, 12 Jul 2013 23:16:41 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id 64C011649; Fri, 12 Jul 2013 23:16:41 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id e11so8473711wgh.6 for ; Fri, 12 Jul 2013 16:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=xOaZy4Coy+aSVnh9zIlRFj/2K8LjuDUwsycZfdNHX1A=; b=eojxj+Uv4+BMARqGPPlGCrZDuAqsh4odVOzBCgthuHcNdCZwBt7z1QZLpWrKRV5Ar9 Q6j/sNHNiuz4IkJI2a+cKyi7qK43Nqq+yEzvdw4dy3S0izFKK2/LnECIql0+58JmkbW/ h+6AYuJ7c5oW2koYNTSnRWAqKAS6b1HFjOmaBYipPTe+Lz/82Yq8JASI5fx06zyBrPcZ LPZ96AqoKF4saGzm8aqfi5zI5pa6oo2LyV8M2EB2ZlhAUMGdZHsJFynXHHvpEuwPw29G NrdBhO4ed7KgUq/c7JYS/g/P+EWEwxnN30TF4Q6fV3g1T8zcqp0V5dsZhocKN9oEl6eT dSLw== X-Received: by 10.180.126.10 with SMTP id mu10mr2838688wib.64.1373671000475; Fri, 12 Jul 2013 16:16:40 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id fb9sm5896688wid.2.2013.07.12.16.16.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jul 2013 16:16:39 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 13 Jul 2013 01:16:37 +0200 From: Baptiste Daroussin To: current@FreeBSD.org, ports@FreeBSD.org Subject: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130712231637.GS85556@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6pbY/KU4ayLo+qis" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jul 2013 23:16:42 -0000 --6pbY/KU4ayLo+qis Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have just committed (r253305) a change the make pkg_install not being built and installed by default on HEAD. If you are still relying on it, be careful and add WITH_PKGTOOLS=yes in your src.conf(5) regards, Bapt --6pbY/KU4ayLo+qis Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHgjlUACgkQ8kTtMUmk6ExtJgCdEYr1g4YX/htq/3EvYXrDKeZa /n4An33atlR29EuD6wgcnpI/lBb9Ga4g =1tvx -----END PGP SIGNATURE----- --6pbY/KU4ayLo+qis-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 23:42:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C72BF38; Fri, 12 Jul 2013 23:42: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 D64311703; Fri, 12 Jul 2013 23:42:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CNghRT047568; Fri, 12 Jul 2013 19:42:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CNgglu047567; Fri, 12 Jul 2013 23:42:42 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 23:42:42 GMT Message-Id: <201307122342.r6CNgglu047567@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 23:42:50 -0000 TB --- 2013-07-12 22:21:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 22:21:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 22:21:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-12 22:21:22 - cleaning the object tree TB --- 2013-07-12 22:21:49 - /usr/local/bin/svn stat /src TB --- 2013-07-12 22:21:56 - At svn revision 253263 TB --- 2013-07-12 22:21:57 - building world TB --- 2013-07-12 22:21:57 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 22:21:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 22:21:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 22:21:57 - SRCCONF=/dev/null TB --- 2013-07-12 22:21:57 - TARGET=sparc64 TB --- 2013-07-12 22:21:57 - TARGET_ARCH=sparc64 TB --- 2013-07-12 22:21:57 - TZ=UTC TB --- 2013-07-12 22:21:57 - __MAKE_CONF=/dev/null TB --- 2013-07-12 22:21:57 - cd /src TB --- 2013-07-12 22:21:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 22:22:05 UTC 2013 >>> 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 Jul 12 23:31:41 UTC 2013 TB --- 2013-07-12 23:31:41 - generating LINT kernel config TB --- 2013-07-12 23:31:41 - cd /src/sys/sparc64/conf TB --- 2013-07-12 23:31:41 - /usr/bin/make -B LINT TB --- 2013-07-12 23:31:41 - cd /src/sys/sparc64/conf TB --- 2013-07-12 23:31:41 - /usr/sbin/config -m LINT TB --- 2013-07-12 23:31:41 - building LINT kernel TB --- 2013-07-12 23:31:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 23:31:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 23:31:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 23:31:41 - SRCCONF=/dev/null TB --- 2013-07-12 23:31:41 - TARGET=sparc64 TB --- 2013-07-12 23:31:41 - TARGET_ARCH=sparc64 TB --- 2013-07-12 23:31:41 - TZ=UTC TB --- 2013-07-12 23:31:41 - __MAKE_CONF=/dev/null TB --- 2013-07-12 23:31:41 - cd /src TB --- 2013-07-12 23:31:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 12 23:31:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c /src/sys/net80211/ieee80211_output.c: In function 'ieee80211_encap': /src/sys/net80211/ieee80211_output.c:1330: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1359: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' /src/sys/net80211/ieee80211_output.c:1370: error: 'struct ieee80211_meshcntl_ae10' has no member named 'mc_global' *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 23:42:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 23:42:42 - ERROR: failed to build LINT kernel TB --- 2013-07-12 23:42:42 - 3800.99 user 642.62 system 4880.33 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 12 23:52:21 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CE8E426D; Fri, 12 Jul 2013 23:52:21 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9E49B1752; Fri, 12 Jul 2013 23:52:21 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r6CNqKbt022934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Jul 2013 18:52:20 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Fri, 12 Jul 2013 18:52:20 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaA Date: Fri, 12 Jul 2013 23:52:19 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> In-Reply-To: <20130712231637.GS85556@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <86AC2E33CB253943A77C6DF7F3A69F94@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-12_10:2013-07-12,2013-07-12,1970-01-01 signatures=0 Cc: Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 23:52:21 -0000 On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: > Hi, >=20 > I have just committed (r253305) a change the make pkg_install not being b= uilt > and installed by default on HEAD. >=20 > If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes in= your > src.conf(5) I think while a good move, we need to allow a window of development to re-w= ork other HEAD components. It might also be worth developing a lint-tool to make sure we get every las= t instance (both from C code and sh code) within our base before we motion = to cut a release with this change. I for one am effected and will have to change things. Can you point us at a guide (or even better, a Wiki) that can smooth the pr= ocess? --=20 Devin NOTE: I cut ports off the CC as they don't need to worry about this ("this"= being heading toward cut of a RELEASE with untold uses of pkg_tools in bas= e) _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 01:12:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD67DFBD for ; Sat, 13 Jul 2013 01:12:44 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) by mx1.freebsd.org (Postfix) with ESMTP id BAE091AD1 for ; Sat, 13 Jul 2013 01:12:44 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id A3F6156F for ; Fri, 12 Jul 2013 20:03:53 -0500 (CDT) Date: Fri, 12 Jul 2013 20:03:45 -0500 (CDT) From: Dan Mack To: freebsd-current@freebsd.org Subject: lost my r2xxxxx subversion id in uname & kern.version 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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 01:12:44 -0000 I'm not sure exactly when but recently I've lost the subversion id from kern.version and hence uname and motd. Subsequent fresh rebuilds from source don't bring it back even after wiping out the tree. Today it looks like this: root@olive:~ # uname -a FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri Jul 12 19:38:24 CDT 2013 root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 root@olive:~ # sysctl kern.version kern.version: FreeBSD 10.0-CURRENT #0: Fri Jul 12 19:38:24 CDT 2013 root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN Previously it would have '#0 r253307' in it's place. This only happened on 1 of 3 build machines. dan From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 01:29:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42849364; Sat, 13 Jul 2013 01:29:37 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA6B1B27; Sat, 13 Jul 2013 01:29:36 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id E035C8755; Sat, 13 Jul 2013 01:29:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us E035C8755 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 12 Jul 2013 21:29:33 -0400 From: Glen Barber To: Dan Mack Subject: Re: lost my r2xxxxx subversion id in uname & kern.version Message-ID: <20130713012933.GB2239@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 01:29:37 -0000 --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 08:03:45PM -0500, Dan Mack wrote: > I'm not sure exactly when but recently I've lost the subversion id > from kern.version and hence uname and motd. >=20 > Subsequent fresh rebuilds from source don't bring it back even after > wiping out the tree. >=20 > Today it looks like this: >=20 > root@olive:~ # uname -a > FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri > Jul 12 19:38:24 CDT 2013 > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 > root@olive:~ # sysctl kern.version > kern.version: FreeBSD 10.0-CURRENT #0: Fri Jul 12 19:38:24 CDT 2013 > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN >=20 > Previously it would have '#0 r253307' in it's place. >=20 > This only happened on 1 of 3 build machines. >=20 Did you upgrade subversion but not the src tree? Glen --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR4K19AAoJEFJPDDeguUajusIH/RiZJ2pBxln1cfa2FI4RZqF9 8yC9KEEzp7tDXwOBgnbnapCH4RIu1DDPA5aI+x16w7x6u0cgUsUFqFGr4in7B24l cIW/rYHKfnN5+CQac4+dFZErEGl0IqMtq1S0gw5MSEJaiU6uCoeh1iszmRiWGb7a SOdi1OBrjNtSWMSNqaSMIcdCRZSqUi4Z2EEjY6QqbOm4hXjl7fQAD1gKB6etiMOe 9Pg4wOUD0Y0N0fNDEBM3vcxLWk4cEZRC037/WThyxNxENakXfHNr4oA2mkwPZ3Nd EsaCrAOCvWRdezXHaJPnBMaD4OKKhDeieEjBvQVTlhy44ObBUseXzQSsuTg9N8U= =Mxt6 -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 05:42:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FB21F56; Sat, 13 Jul 2013 05:42:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 997F111CA; Sat, 13 Jul 2013 05:42:25 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6D5gKZi072119; Sat, 13 Jul 2013 08:42:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6D5gKZi072119 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6D5gKhE072118; Sat, 13 Jul 2013 08:42:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Jul 2013 08:42:20 +0300 From: Konstantin Belousov To: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 Message-ID: <20130713054220.GJ91021@kib.kiev.ua> References: <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D1DlOxT2xGoS+WIB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 05:42:26 -0000 --D1DlOxT2xGoS+WIB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 12, 2013 at 11:34:18PM +0200, Ian FREISLICH wrote: > (kgdb) print runningbufreq > $1 = 1 > (kgdb) print runningbufspace > $2 = 0 > (kgdb) print lorunningspace > $3 = 4587520 > (kgdb) print hirunningspace > $4 = 4194304 This is extremely weird. The hirunningspace is less then lorunningspace, am I right ? This causes the runningbufspace machinery to never wake up waiters, I believe. The process is put on sleep when hirunningspace is reached, but would be woken up after we cross lorunningspace. If the space never goes up to your bigger lorunningspace, you get the process stuck forever, owning vnode lock and making machine inoperable. I just verified on the 4G VM on amd64, my numbers for lo is 4587520, for high 6881280. Verify your tuning and kernel options, which you should have provided with the original report, I think. --D1DlOxT2xGoS+WIB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4Oi7AAoJEJDCuSvBvK1BoyEP/iAMyHlwFAvxY8eeDWmgOCZH 76F5LMvoEnECUHm/tCgFdp9fArULIsAab9go+WQ+xn0CQ1ybFRM6ow0m6wehxIRl 0wySu2jDOhhY0zSYS8O0Ereo4Rk1FHce1uw0a5JhPpj8WfSElJsF/zMZ6AvEvZ0w sbTbIyyZNzDIk76G9HWKpLye78zn1SFVxnnzHLXe3VrkpTnCdV+zJT97v9i76wzD +YduVPmZTSOTSGYsGlMsxqJW79YTw7WEI7TYhbQPDqUKMNIEMTUZHRn2pbr/ioMc /QZR4/G7THc4zGP3H2/KrRBCncvrXf+z6TyWkSsqj06dX1VkDXyIpTFHs6krFKcn KzHbXDpZ+RxvC1jifIgfvbG3TtGxrGe2VbMFJ5hfuXyCmojBL9wz1WLtyACPlgd4 hdMsReP7/TtB26zSJZoI/ow6fzsjbQd2wz6qvl5e+JFoMM7i0x2ep+IraP43M2oc OEzvVXZRf9w+VI9gzglhvhfUu5+lM1nqwtm24uzv/bukZpiVRPHDQhvQo6iVxoPj XNXkAY8s+VwbT6Ohnp4laTk+A248Udv4ZFAC+HuPWrooIIF2SfifMqvCK98UxMd2 1n9rufckXhH87q1nW5hHnkNB9aBpWYX0TlJHdEMnUwsX0KfE0iv6Y7IMynux8xV8 clf8AgXVtOvJuA9ja3u1 =bA8l -----END PGP SIGNATURE----- --D1DlOxT2xGoS+WIB-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 08:07:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2C9016F; Sat, 13 Jul 2013 08:07:37 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id 8F44716B1; Sat, 13 Jul 2013 08:07:36 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id ey16so1391056wid.3 for ; Sat, 13 Jul 2013 01:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wOWuMaKwuMIPd1rAwvctgXIOjOigoOX3SolOIWXeFnE=; b=sDxuAgV+37IK9dkMV4GPz6+h49t13RUHDUvfam8ZDFXNEaMwLZELjEZPgYdI1IhW0j XO6YPIJznXQ8UoYFTZfC/ESUJnqgmLdKuHS6pFIxQWfWDmo6enRe1XJhRLyjo0TmGRFD NIMWtH9NevXx2yCDuq8iXe8XvUjQC8Nm7nY1P+mSuu3fyBGmPwTCKT1HcBjGeZIGdVnj Qv0Qo389hOx55mEM8mbQI0BTP0yUgakSjNlWCfYJ+NxjKFKPjkznfCenqMcoD95d0j0a qHwouoDVv2AUG2P9ZI3kE3rscui+AhJZugbVJiNwhBcm7kOrkq/7MrIWigGtRvFfiJMB AXdg== X-Received: by 10.180.78.98 with SMTP id a2mr3646171wix.27.1373702855646; Sat, 13 Jul 2013 01:07:35 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id h8sm7428833wie.1.2013.07.13.01.07.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jul 2013 01:07:34 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 13 Jul 2013 10:07:32 +0200 From: Baptiste Daroussin To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130713080732.GV85556@ithaqua.etoilebsd.net> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v7CWsE/Dy737oYst" Content-Disposition: inline In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 08:07:37 -0000 --v7CWsE/Dy737oYst Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: > On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: >=20 > > Hi, > >=20 > > I have just committed (r253305) a change the make pkg_install not being= built > > and installed by default on HEAD. > >=20 > > If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes = in your > > src.conf(5) >=20 > I think while a good move, we need to allow a window of development to re= -work other HEAD components. >=20 > It might also be worth developing a lint-tool to make sure we get every l= ast instance (both from C code and sh code) within our base before we motio= n to cut a release with this change. >=20 > I for one am effected and will have to change things. If you are referring to bsdconfig's package management, it is not working a= nyway HEAD as we do not and will not provides any pkg_install for HEAD via any of= the usual distribution process: http, ftp, CD. Secondly if I'm properly reading src.conf.5 bsdconfig is not installed by default, which means we have a non default code depending on a now non defa= ult code, I don't see a problem here, should I? regards, Bapt --v7CWsE/Dy737oYst Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHhCsQACgkQ8kTtMUmk6Eys+ACaA5cu2Cf4c0Ye6maA3pFtQDWx 1dEAoIMvcZsXE1P69d6v8PrFQrvs5/WO =1Mgk -----END PGP SIGNATURE----- --v7CWsE/Dy737oYst-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 08:14:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3C7B2BD; Sat, 13 Jul 2013 08:14:23 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 6582016DE; Sat, 13 Jul 2013 08:14:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id A8D572A832E8; Sat, 13 Jul 2013 10:14:17 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l8HkUnZ+I04; Sat, 13 Jul 2013 10:14:15 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 349802A832A5; Sat, 13 Jul 2013 10:14:15 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uxuy4-0003KB-OZ; Sat, 13 Jul 2013 10:14:12 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 To: Konstantin Belousov From: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 In-Reply-To: <20130713054220.GJ91021@kib.kiev.ua> References: <20130713054220.GJ91021@kib.kiev.ua> <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> X-Attribution: BOFH Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1373703160_23330" Date: Sat, 13 Jul 2013 10:14:06 +0200 Message-Id: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 08:14:24 -0000 This is a multipart MIME message. --==_Exmh_1373703160_23330 Content-Type: text/plain; charset=us-ascii Konstantin Belousov wrote: > On Fri, Jul 12, 2013 at 11:34:18PM +0200, Ian FREISLICH wrote: > > (kgdb) print runningbufreq > > $1 = 1 > > (kgdb) print runningbufspace > > $2 = 0 > > (kgdb) print lorunningspace > > $3 = 4587520 > > (kgdb) print hirunningspace > > $4 = 4194304 > > This is extremely weird. The hirunningspace is less then lorunningspace, > am I right ? This causes the runningbufspace machinery to never wake up Yes. This state of affairs doesn't happen on r251445 and further testing on my side shows it doesn't hapen on all my amd64 servers. It appears that this particular server type (Dell R200) running amd64 with geom_mirror is affected. I will have to test further by destroying the mirror and removing it from the kernel and see if I can still reproduce the issue. Perhaps r251446 exposes insufficient locking on opperations affecting these variables. FWIW, I cannot reproduce the problem if the mirror is rebuilding. > I just verified on the 4G VM on amd64, my numbers for lo is 4587520, > for high 6881280. Verify your tuning and kernel options, which you should > have provided with the original report, I think. Sorry about that (and I'm relieved:) I had originally compiled with CPUTYPE?=opteron which is incorrect for this CPU. However the problem persists with CPUTYPE?=core2, but I'm not sure how much of a difference this makes with clang. Also, I have another affected host that's compiled with gcc and the correct CPUTYPE so I doubt it's the compiler. I've attached make.conf, kernelconfig and dmesg.boot. You'll notice it's r251446M - which is a result of your patch. Ian -- Ian Freislich --==_Exmh_1373703160_23330 Content-Type: text/plain ; name="FIREWALL"; charset=us-ascii Content-Description: FIREWALL Content-Disposition: attachment; filename="FIREWALL" cpu HAMMER ident "FIREWALL" options SCHED_ULE options INET #InterNETworking options FFS #Berkeley Fast Filesystem options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options SOFTUPDATES #Enable FFS soft updates support options PSEUDOFS #Pseudo-filesystem framework options PROCFS options GEOM_PART_GPT options GEOM_LABEL options GEOM_MIRROR options GEOM_GATE # Userland services. options COMPAT_43 options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD32 options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options COMPAT_FREEBSD5 #Compatible with FreeBSD4 options COMPAT_FREEBSD6 #Compatible with FreeBSD4 options COMPAT_FREEBSD7 #Compatible with FreeBSD4 options COMPAT_LINUX32 options LINPROCFS options LINSYSFS options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options CONSPEED=115200 options PRINTF_BUFR_SIZE=128 device pf device pflog device pfsync options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options KDB_TRACE options KDB_UNATTENDED options ALT_BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC makeoptions DEBUG=-g # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel device cpufreq device acpi device pci device smb device smbus device ichsmb # ATA controllers device mfi device scbus # SCSI bus (required for ATA/SCSI) device ahci # AHCI-compatible SATA controllers device ata device ada # Direct Access (disks) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct ATA/SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux device psm # PS/2 mouse device vga # VGA video card driver device sc device agp # support several AGP chipsets # Serial (COM) ports device uart device smb device smbus device ichsmb device miibus device bce device bge device em device igb device vlan option VLAN_ARRAY device carp # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter device usb device uhci device ehci device ohci device ums device ukbd device ucom device ulpt device uplcom device umass device uhid --==_Exmh_1373703160_23330 Content-Type: text/plain ; name="dmesg.boot"; charset=us-ascii Content-Description: dmesg.boot Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2 r251446M: Sat Jul 13 09:14:34 SAST 2013 ianf@fw1.smmt.gp-online.net:/usr/obj/usr/src/sys/FIREWALL amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.82-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbff Features2=0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3966435328 (3782 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x7f irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x5f irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 bge0: mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci3 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:25:64:3c:33:8d pcib4: irq 17 at device 28.5 on pci0 pci4: on pcib4 bge1: mem 0xdfef0000-0xdfefffff irq 17 at device 0.0 on pci4 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:25:64:3c:33:8e uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xdfcffc00-0xdfcfffff irq 21 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib5: at device 30.0 on pci0 pci5: on pcib5 vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdfff0000-0xdfffffff irq 19 at device 5.0 on pci5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x90 on acpi0 uart0: console (115200,n,8,1) orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata3 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1333409705 Hz quality 1000 WARNING: DIAGNOSTIC option enabled, expect reduced performance. cd0 at ata2 bus 0 scbus0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered GEOM: ada0: the secondary GPT header is not in the last LBA. GEOM: ada1: the secondary GPT header is not in the last LBA. GEOM_MIRROR: Device mirror/d0 launched (2/2). Root mount waiting for: usbus3 Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 uhub4: on usbus3 uhub4: MTT enabled Root mount waiting for: usbus3 uhub4: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/mirror/d0p2 [rw]... bge0: link state changed to UP carp: VHID 3@vlan3: INIT -> BACKUP carp: demoted by -240 to 2400 (interface up) vlan3: link state changed to UP carp: VHID 4@vlan4: INIT -> BACKUP carp: demoted by -240 to 2160 (interface up) vlan4: link state changed to UP carp: VHID 5@vlan5: INIT -> BACKUP carp: demoted by -240 to 1920 (interface up) vlan5: link state changed to UP carp: VHID 6@vlan6: INIT -> BACKUP carp: demoted by -240 to 1680 (interface up) vlan6: link state changed to UP carp: VHID 7@vlan7: INIT -> BACKUP carp: demoted by -240 to 1440 (interface up) vlan7: link state changed to UP carp: VHID 8@vlan8: INIT -> BACKUP carp: demoted by -240 to 1200 (interface up) vlan8: link state changed to UP carp: VHID 9@vlan9: INIT -> BACKUP carp: demoted by -240 to 960 (interface up) vlan9: link state changed to UP carp: VHID 12@vlan12: INIT -> BACKUP carp: demoted by -240 to 720 (interface up) vlan12: link state changed to UP carp: VHID 13@vlan13: INIT -> BACKUP carp: demoted by -240 to 480 (interface up) vlan13: link state changed to UP carp: VHID 40@vlan40: INIT -> BACKUP carp: demoted by -240 to 240 (interface up) vlan40: link state changed to UP bge1: link state changed to UP --==_Exmh_1373703160_23330 Content-Type: text/plain ; name="make.conf"; charset=us-ascii Content-Description: make.conf Content-Disposition: attachment; filename="make.conf" MAKE_IDEA= YES # IDEA (128 bit symmetric encryption) PRINTERDEVICE= ps USA_RESIDENT=NO CPUTYPE?=core2 HAVE_MOTIF= yes MAKE_KERBEROS5= yes ENABLE_SUID_K5SU= yes KERNCONF=FIREWALL BOOT_COMCONSOLE_SPEED=115200 #WITHOUT_CLANG_IS_CC=yes WITH_PKGNG= yes # added by use.perl 2013-06-13 18:12:04 PERL_VERSION=5.14.4 --==_Exmh_1373703160_23330-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 10:03:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4DBD1FAA; Sat, 13 Jul 2013 10:03:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B6B4F1951; Sat, 13 Jul 2013 10:03:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6DA3ccd026051; Sat, 13 Jul 2013 13:03:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6DA3ccd026051 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6DA3b9G026050; Sat, 13 Jul 2013 13:03:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Jul 2013 13:03:37 +0300 From: Konstantin Belousov To: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 Message-ID: <20130713100337.GK91021@kib.kiev.ua> References: <20130713054220.GJ91021@kib.kiev.ua> <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiQkvLGLJxajv8+M" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 10:03:44 -0000 --IiQkvLGLJxajv8+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 13, 2013 at 10:14:06AM +0200, Ian FREISLICH wrote: > Konstantin Belousov wrote: > > On Fri, Jul 12, 2013 at 11:34:18PM +0200, Ian FREISLICH wrote: > > > (kgdb) print runningbufreq > > > $1 =3D 1 > > > (kgdb) print runningbufspace > > > $2 =3D 0 > > > (kgdb) print lorunningspace > > > $3 =3D 4587520 > > > (kgdb) print hirunningspace > > > $4 =3D 4194304 > >=20 > > This is extremely weird. The hirunningspace is less then lorunningspac= e, > > am I right ? This causes the runningbufspace machinery to never wake up >=20 > Yes. This state of affairs doesn't happen on r251445 and further > testing on my side shows it doesn't hapen on all my amd64 servers. > It appears that this particular server type (Dell R200) running > amd64 with geom_mirror is affected. I will have to test further > by destroying the mirror and removing it from the kernel and see > if I can still reproduce the issue. Perhaps r251446 exposes > insufficient locking on opperations affecting these variables. No. The lorunningspace is constant for the system lifetime. It can only be changed by the sysctl vfs.lorunningspace. Look into /etc/sysctl.conf or scripts which apply sysctl settings. Boot the system single-user and show the sysctl vfs.lorunningspace sysctl vfs.hirunningspace Compare the values from single user with the values after the system booted normal. >=20 > > I just verified on the 4G VM on amd64, my numbers for lo is 4587520, > > for high 6881280. Verify your tuning and kernel options, which you sho= uld > > have provided with the original report, I think. >=20 > Sorry about that (and I'm relieved:) I had originally compiled with > CPUTYPE?=3Dopteron which is incorrect for this CPU. However the > problem persists with CPUTYPE?=3Dcore2, but I'm not sure how much of > a difference this makes with clang. Also, I have another affected > host that's compiled with gcc and the correct CPUTYPE so I doubt > it's the compiler. >=20 This is irrelevant, CPU type cannot affect the calculation, unless the compiler is horribly broken. --IiQkvLGLJxajv8+M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4SX5AAoJEJDCuSvBvK1BqYsP+gMJ/db3BzdxhYpPZlP3CmgX xUz+cCtjTF0bLW6GgSV0Yd2aK4yHlanr38LmBAHUVuNXq5Mr9vvxhvebqCzyxrFq ar3JiR3v6rMu0J6I0shIqGSrRJeY7ZsHPn/Tb1hGLzaqtdXzFxs5fS4QGhBjnaMZ Mbg1zjNZjonSVkimFIhFSijklmRXfxIuihOi8bzpMmKWNW2ruYWb2kE9vHd7teEM AaSLhfaqTnlpXyyR/yEpZPigyE/ksUrzHOHvUDu1pMdXqcxZYEeg9KXJSJz/ro8R 6rFvImmT8MGBv43arbup5AGJ12RGc0INkKXj1KGQrLpM/mVrpYPAkLHhtv0miIxp Eymg/cUH13NYm9Et6pG7SQibE7leebmWYr6EIj63unM+H/wx2QVVJoUGJZHmUppF j16KlhqL1A9xWHoUIMQH5hWtkst5luFX+0ItyJesVKMDn60ck81cyGyqt5xiI9yI Xaw5zSK9RNC1Z4hXaTYmwkU7AvprX0s/hl9fuFW930TQYnYXP5/3PmkZyIgLAD8k tUcNV81+Du3nXMarDx+7196gQiFP9Ynz8SyoLU7aDRdmf0XgeZFizzy9TEB0BEe9 NXvaJ/m6wUWua/a1tGq3vD/3kF5y8w9EgA2ZNXkHNIV2gUZsYYYtKXNC6B/6OWu9 QO48a4CuxkzgK7sL2bon =xVOK -----END PGP SIGNATURE----- --IiQkvLGLJxajv8+M-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 11:11:18 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7191AAC8; Sat, 13 Jul 2013 11:11:18 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0831AE2; Sat, 13 Jul 2013 11:11:18 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id A11105606D; Sat, 13 Jul 2013 06:11:11 -0500 (CDT) Date: Sat, 13 Jul 2013 06:11:11 -0500 From: Mark Linimon To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130713111111.GA13680@lonesome.com> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130713080732.GV85556@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 11:11:18 -0000 fwiw, nanobsd also is still on pkg_*, but I intend to come up with patches for that if someone else has not already done so. mcl From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 11:40:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CC31A37C for ; Sat, 13 Jul 2013 11:40:15 +0000 (UTC) (envelope-from demonking@hotmail.de) Received: from dub0-omc2-s7.dub0.hotmail.com (dub0-omc2-s7.dub0.hotmail.com [157.55.1.146]) by mx1.freebsd.org (Postfix) with ESMTP id 720261C0C for ; Sat, 13 Jul 2013 11:40:15 +0000 (UTC) Received: from DUB121-W39 ([157.55.1.137]) by dub0-omc2-s7.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 13 Jul 2013 04:39:06 -0700 X-TMN: [VLghGtz0AhLOHUrA3puRdjampIFDIf6J] X-Originating-Email: [demonking@hotmail.de] Message-ID: From: Denis D To: "freebsd-current@freebsd.org" Subject: msk0 watchdog timeout and interrupt storm Date: Sat, 13 Jul 2013 13:39:06 +0200 Importance: Normal In-Reply-To: References: , <20130710065701.GD2753@michelle.cdnetworks.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2013 11:39:06.0306 (UTC) FILETIME=[94D81A20:01CE7FBD] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 11:40:15 -0000 > If you use dual-boot=2C please try "cold-boot" it. Other OS may have =0A= =0A= > put the PHY into weird state. Cold-boot shall make firmware restore =0A= =0A= > its PHY configuration. =0A= =0A= >=20 =0A= =0A= =0A= =0A= Hello pyunyh=2C=0A= =0A= =0A= =0A= when i really understand the word coldbootkorrekt=2Cit means=2C that i have= to shutdown my pc. And start it (during he was off) and boot into FreeBSD.=0A= =0A= =0A= =0A= My PC was off for 9 hours because of work=2C but still the same "watchdog t= imeout" error.=0A= =0A= =0A= =0A= Maybe some other solutions? = From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 10:13:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A36E2BA; Sat, 13 Jul 2013 10:13:24 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4E65E1988; Sat, 13 Jul 2013 10:13:23 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6DAD3hL037645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 13 Jul 2013 10:13:06 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_6B70CB09-FD89-4DA2-BEA2-1A534D35DC7A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: David Chisnall In-Reply-To: <20130712234749.5afa3c9b@thor.walstatt.dyndns.org> Date: Sat, 13 Jul 2013 11:12:59 +0100 Message-Id: <9B0A6D14-640E-4ADD-8E58-0B7867C7C674@FreeBSD.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> <20130712234749.5afa3c9b@thor.walstatt.dyndns.org> To: "O. Hartmann" X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Sat, 13 Jul 2013 11:55:18 +0000 Cc: Ed Schouten , Scot Hetzel , David Chisnall , "freebsd-toolchain@FreeBSD.org" , Garrett Wollman , FreeBSD Current , Bruce Evans , Tijl Coosemans , "freebsd-standards@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 10:13:24 -0000 --Apple-Mail=_6B70CB09-FD89-4DA2-BEA2-1A534D35DC7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Jul 2013, at 22:47, "O. Hartmann" = wrote: > Obviously not really fixed, but even worse: >=20 > if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64 > revision 253287) isnan(x) where x is a "const double", I receive now > the following error (which doesn't appear on previous versions): Thanks. This is now fixed, however the _Generic() usage that we had = there is also present in tgmath.h, and so this file will also need to be = fixed in the same way. I've now tested the macros with clang/c99, clang/c11, clang/c++98 and = clang/c++11, and gcc/c89 and they all seem to work for unqualified, = const, volatile, and const-volatile qualified types. I've added Ed to the cc: list, as he wrote this code in tgmath.h. David --Apple-Mail=_6B70CB09-FD89-4DA2-BEA2-1A534D35DC7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR4SgrAAoJEKx65DEEsqIdX+EQAMQpv3rkIYsk3U/45VwY9exf 4fjD7vuwWpsIeqtd9YL8Ru6bJ6dHsEk5P+6ffOHrzdzQfTyxDmU9jco9YcTPVkv8 OrMZ+Ld7ROuGQPX6QIPg63zGfRfREL+Lntabkbm0yGRZIr3Uf6EEham5DIMFp+OB MSqNq1AoMTc27zCACCimW3L6jbT3xrD6XLExR0hum4wAR2LAuflxodHESXmlo7n5 y+Oh+OuO/U60EkXoOoColAMEicLdvci+eoq35DbyReVO7DEf3o2eNd9PVmssVcZ+ 0RfC3KCzFqybbOyw3ZAbgoY+B9BDXgX3p75g4Qk9TKTTaAvwLHUFj0S+A0u8Rrb6 eNFw0ZGfLii/ao1RrWLnsHOiPKovf/uBRC3LDcpeOOJr8AyLOlpinBTaeGEnS4dS HnnJzHmKpOM0qJ6dSlwkQvA4AePRRzsTrm4viLuwsI8IionG+OPkNs7FuxORTW5I tKoFUwFKhzbU6p4XVuhEStowL4cqT4Ba9EbK07HWqMJ5xNBA0BPpTEKd4RVorXOm 54K0sIz3AB/TQk7I01iWmFOebaVMYorlBP6NMqvNWW9h35PRFyBrfxQVVYHmINrr F7hpH0oL5gJBCFVLUxhBlATJiM7FdbB0sHqXaFEqpdZjKUt9X8dysWJYHNXpoJOh GDnQq1VQEBMDqPjx9C53 =TyR3 -----END PGP SIGNATURE----- --Apple-Mail=_6B70CB09-FD89-4DA2-BEA2-1A534D35DC7A-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 11:59:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A0D0D52; Sat, 13 Jul 2013 11:59:24 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 9C1281CCC; Sat, 13 Jul 2013 11:59:23 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so1331885wgg.2 for ; Sat, 13 Jul 2013 04:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IGfJkcF8AsSKNu/J1PSSKjR2T+Zqt79/DTjeRThk/6E=; b=lRucpdYyi4NwWwST3CyL99UrO+i4XbJnmadC7i5fjCKPihW0/DlPWu5dYEPPgfkzQi 0u5WRnd24dgLXVYNPiWtLVj/OTZY6P/vQxIc77Nxig8Pv2XOLGf2vx/Avqu+ip6KXSn3 frVxfGPloc+g3Wexq38VzvBn1nsW3g+xJLAJlqVg4SJU76rBM03De4JuxWifuiSRa0M1 n2vu8M9up1YZc0LNP229kVpQ6v1ytswx0igRi3N1040MaCnwtBKlWUZmEkwmsYU1xrzP kulacXBWZx/VENhd169iy+d77CVVPdFLY/HThF1RzrFQKhOptQsaU39YXoOR4yQfTT2L ROQA== X-Received: by 10.194.173.37 with SMTP id bh5mr27275921wjc.30.1373716762432; Sat, 13 Jul 2013 04:59:22 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id h8sm8483198wie.1.2013.07.13.04.59.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jul 2013 04:59:21 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 13 Jul 2013 13:59:19 +0200 From: Baptiste Daroussin To: Mark Linimon Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130713115919.GX85556@ithaqua.etoilebsd.net> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <20130713111111.GA13680@lonesome.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6yuPXOSZRpyw7iEV" Content-Disposition: inline In-Reply-To: <20130713111111.GA13680@lonesome.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 11:59:24 -0000 --6yuPXOSZRpyw7iEV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 13, 2013 at 06:11:11AM -0500, Mark Linimon wrote: > fwiw, nanobsd also is still on pkg_*, but I intend to come up with > patches for that if someone else has not already done so. >=20 > mcl There are lots of patches available everyone to have nanobsd using pkgng I didn't commit any, because I do find the nanobsd dev a bit weird, lots of different version everywhere, lots of different patches etc. regards, Bapt --6yuPXOSZRpyw7iEV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHhQRcACgkQ8kTtMUmk6EzH3gCcDjhntf3wYpqadi/5CUyxbsJt kS8AoL8tEySQug6/TAx5tN7ayDMWPRTh =Q+nK -----END PGP SIGNATURE----- --6yuPXOSZRpyw7iEV-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 12:58:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52B868E1; Sat, 13 Jul 2013 12:58:36 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 0651C1F80; Sat, 13 Jul 2013 12:58:35 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so14110160oag.16 for ; Sat, 13 Jul 2013 05:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ad+pOi0kOCbew1SHsaphUzwYpnOkg2ma6BNkLivZCOo=; b=TOLtUSI54hBieDnh2EzyCK3hjHluR7hPD3r0XlgiJROorHnyHGLmLEsjkSmBK1KOXp hg0CjAnm63X9s2jDqm7VyzUr2CrMVwQpeph8rJkqbsnw2Pu6XJfKhCbG9PI8hDBmO9ao KsakanVy1HxtEU2jNPIIw+nQozKmpDya495Jq9XRfdtf8sndUVn7zPhe//zQoI5aXznu XZ16rrJmdQVAxJ/5Y0hNM7AdC2HE1cHZfLs5zYBgoxJpPYH6Su2IyepFogjfBFYx3OGG ErYq0/h8wU5jF6JwGpqgvztIfAO6e8taawVjNXwdx/d+XzPwG4XkyE8L3dhG73gRgL52 4mOg== MIME-Version: 1.0 X-Received: by 10.182.46.230 with SMTP id y6mr38572729obm.79.1373720315564; Sat, 13 Jul 2013 05:58:35 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Sat, 13 Jul 2013 05:58:35 -0700 (PDT) In-Reply-To: <20130713115919.GX85556@ithaqua.etoilebsd.net> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <20130713111111.GA13680@lonesome.com> <20130713115919.GX85556@ithaqua.etoilebsd.net> Date: Sat, 13 Jul 2013 08:58:35 -0400 Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Outback Dingo To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mark Linimon , Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 12:58:36 -0000 On Sat, Jul 13, 2013 at 7:59 AM, Baptiste Daroussin wrote: > On Sat, Jul 13, 2013 at 06:11:11AM -0500, Mark Linimon wrote: > > fwiw, nanobsd also is still on pkg_*, but I intend to come up with > > patches for that if someone else has not already done so. > > > > mcl > > There are lots of patches available everyone to have nanobsd using pkgng > > I didn't commit any, because I do find the nanobsd dev a bit weird, lots of > different version everywhere, lots of different patches etc. > > would someone like to forward their patches for pkg on nanobsd to the list > regards, > Bapt > From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 12:26:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0909A388; Sat, 13 Jul 2013 12:26:10 +0000 (UTC) (envelope-from pasi.parviainen@iki.fi) Received: from sypressi.dnainternet.net (sypressi.dnainternet.net [83.102.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id AC5C81DF2; Sat, 13 Jul 2013 12:26:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sypressi.dnainternet.net (Postfix) with ESMTP id 5BFB72618E4; Sat, 13 Jul 2013 15:20:22 +0300 (EEST) X-Virus-Scanned: DNA Postiturva at dnainternet.net X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-9999 required=6 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from sypressi.dnainternet.net ([83.102.40.135]) by localhost (sypressi.dnainternet.net [127.0.0.1]) (DNA Postiturva, port 10041) with ESMTP id vCYO0WFvf7n2; Sat, 13 Jul 2013 15:20:21 +0300 (EEST) Received: from luumupuu.dnainternet.net (luumupuu.dnainternet.net [83.102.40.213]) by sypressi.dnainternet.net (Postfix) with ESMTP id DC8C72618E9; Sat, 13 Jul 2013 15:20:21 +0300 (EEST) Received: from [192.168.0.2] (host-109-204-160-251.tp-fne.tampereenpuhelin.net [109.204.160.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luumupuu.dnainternet.net (Postfix) with ESMTPS id 79EDD5FA7F; Sat, 13 Jul 2013 15:20:12 +0300 (EEST) Message-ID: <51E145CC.8080900@iki.fi> Date: Sat, 13 Jul 2013 15:19:24 +0300 From: Pasi Parviainen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Chisnall Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <20130711202908.L84170@besplex.bde.org> <20130712234749.5afa3c9b@thor.walstatt.dyndns.org> <9B0A6D14-640E-4ADD-8E58-0B7867C7C674@FreeBSD.org> In-Reply-To: <9B0A6D14-640E-4ADD-8E58-0B7867C7C674@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 13 Jul 2013 13:05:30 +0000 Cc: Scot Hetzel , "freebsd-standards@FreeBSD.org" , "freebsd-toolchain@FreeBSD.org" , Garrett Wollman , FreeBSD Current , Bruce Evans , Tijl Coosemans , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 12:26:10 -0000 On 13.7.2013 13:12, David Chisnall wrote: > On 12 Jul 2013, at 22:47, "O. Hartmann" wrote: > >> Obviously not really fixed, but even worse: >> >> if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64 >> revision 253287) isnan(x) where x is a "const double", I receive now >> the following error (which doesn't appear on previous versions): > > Thanks. This is now fixed, however the _Generic() usage that we had there is also present in tgmath.h, and so this file will also need to be fixed in the same way. > > I've now tested the macros with clang/c99, clang/c11, clang/c++98 and clang/c++11, and gcc/c89 and they all seem to work for unqualified, const, volatile, and const-volatile qualified types. > > I've added Ed to the cc: list, as he wrote this code in tgmath.h. > > David > Instead of listing all possible type qualifier combinations (like in r253319), how about using a comma operator to strip away type qualifiers? Since only the result type of the expression matters and it isn't evaluated at all. like: #define __fp_type_select(x, f, d, ld) _Generic((0,(x)), Pasi From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 13:20:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 319BF4E3; Sat, 13 Jul 2013 13:20:51 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by mx1.freebsd.org (Postfix) with ESMTP id E95CE1048; Sat, 13 Jul 2013 13:20:50 +0000 (UTC) Received: from [78.35.189.104] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UxzgV-0004XA-LV; Sat, 13 Jul 2013 15:16:23 +0200 Date: Sat, 13 Jul 2013 14:30:31 +0200 From: Fabian Keil To: Andre Oppermann Subject: Re: Improved SYN Cookies: Looking for testers Message-ID: <20130713143026.1318d00e@fabiankeil.de> In-Reply-To: <51DFF400.6070504@freebsd.org> References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> <51DE6E86.6080707@freebsd.org> <20130712125640.6d194bd2@fabiankeil.de> <51DFF400.6070504@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/y//ueHw1WD_x_.PJFMw3EG7"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 13:20:51 -0000 --Sig_/y//ueHw1WD_x_.PJFMw3EG7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > On 12.07.2013 12:56, Fabian Keil wrote: > > Andre Oppermann wrote: > > > >> On 10.07.2013 15:18, Fabian Keil wrote: > >>> Andre Oppermann wrote: =20 > >> It will give a bit of debug log output which is it telling you mostly = about > >> rounding to the next nearest index value. You can send the output pri= vately > >> to me to spot unexpected outliers, if any. > > > > One unexpected outlier seems to be: >=20 > Both errors are normal and a sign of lazy application behavior, not a TCP > error. Thanks for the explanation. Makes sense. Fabian --Sig_/y//ueHw1WD_x_.PJFMw3EG7 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHhSGcACgkQBYqIVf93VJ3JGgCfZ6QR0tz8LB7a+yHAqdhZ/nsM m1IAoMmn+KLf6Yc1Z6B3bgW1j3Uv8hOo =UX+A -----END PGP SIGNATURE----- --Sig_/y//ueHw1WD_x_.PJFMw3EG7-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 15:18:02 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9AADA4B1; Sat, 13 Jul 2013 15:18:02 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 66457168C; Sat, 13 Jul 2013 15:18:02 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r6DFHrCq025163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Jul 2013 10:17:53 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Sat, 13 Jul 2013 10:17:53 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gA== Date: Sat, 13 Jul 2013 15:17:52 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> In-Reply-To: <20130713080732.GV85556@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-13_05:2013-07-12,2013-07-13,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 15:18:02 -0000 On Jul 13, 2013, at 1:07 AM, Baptiste Daroussin wrote: On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: Hi, I have just committed (r253305) a change the make pkg_install not being bui= lt and installed by default on HEAD. If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes in y= our src.conf(5) I think while a good move, we need to allow a window of development to re-w= ork other HEAD components. It might also be worth developing a lint-tool to make sure we get every las= t instance (both from C code and sh code) within our base before we motion = to cut a release with this change. I for one am effected and will have to change things. If you are referring to bsdconfig's package management, If you choose to read into it that way, sure. Yes. that's what I'm talking = about. NOTE: I can't be the only person in HEAD that's using pkg_install still. it is not working anyway HEAD as we do not and will not provides any pkg_install for HEAD via any of= the usual distribution process: http, ftp, CD. I'm quite aware that changes will be needed. I'm still interested in a "tra= nsition wiki" if one exists. Secondly if I'm properly reading src.conf.5 If there's a reference to "WITH_BSDCONFIG" in src.conf.5, that needs to be = removed. I wasn't aware that it was referenced in there. bsdconfig is not installed by default, Wrong, please see... http://svnweb.freebsd.org/base?view=3Drevision&revision=3D252862 which means we have a non default code depending on a now non default code, Wrong. I don't see a problem here, should I? Yes. -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 15:07:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44360417; Sat, 13 Jul 2013 15:07:10 +0000 (UTC) (envelope-from miwi@bsdhash.org) Received: from bsdhash.org (bsdhash.org [94.23.250.27]) by mx1.freebsd.org (Postfix) with ESMTP id 130A51650; Sat, 13 Jul 2013 15:07:09 +0000 (UTC) Received: from [192.168.0.105] (kbu-124-234.tm.net.my [210.186.124.234]) by bsdhash.org (Postfix) with ESMTPA id 3DE84512EE; Sat, 13 Jul 2013 23:07:06 +0800 (MYT) Subject: Re: errors building 9-STABLE on recent HEAD Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Martin Wilke In-Reply-To: <20130624201149.GB70873@lor.one-eyed-alien.net> Date: Sat, 13 Jul 2013 23:07:04 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1A835C0A-9A00-49B9-948C-CF69631CA2B7@bsdhash.org> References: <20130624201149.GB70873@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Sat, 13 Jul 2013 15:18:51 +0000 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 15:07:10 -0000 Hi, I see exactly the same error on pointyhat too, did you find any work = around for that? On Jun 25, 2013, at 4:11 AM, Brooks Davis wrote: > I recently upgraded my main buildbox from an ancient 9.0-STABLE = snapshot > to head and I've run into an issue building 9-STABLE on it. Initally > this was broken by the switch to bmake, but Simon committed a work > around that and using the fmake port also works around it. Now I'm > seeing a strange error in yacc generated code. I say strange because > yacc is correctly being bootstrapped so we're using the expected = version > and not the one in HEAD. >=20 > Does anyone have any insight into this issue? >=20 > cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=3D64 -I. = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd = -I/home/bed22/obj/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/i= nclude -DTARGET=3D\"x86_64-unknown-freebsd\" = -DDEFAULT_EMULATION=3D\"elf_x86_64_fbsd\" -DSCRIPTDIR=3D\"/usr/libdata\" = -DBFD_VERSION_STRING=3D\""2.17.50 [FreeBSD] 2007-07-03"\" = -DBINDIR=3D\"/usr/bin\" -DTARGET_SYSTEM_ROOT=3D\"\" = -DTOOLBINDIR=3D\"//usr/bin/libexec\" -D_GNU_SOURCE = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/l= d = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/b= fd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized = -Wno-pointer-sign -c ldlex.c > cc1: warnings being treated as errors > : In function 'yy_get_next_buffer': > :3229: warning: passing argument 2 of 'yy_input' from > incompatible pointer type > *** [ldlex.o] Error code 1 >=20 > Stop in /home/bed22/src-9/gnu/usr.bin/binutils/ld. > *** [all] Error code 1 >=20 > Thanks, > Brooks +-----------------oOO--(_)--OOo-------------------------+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 16:39:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 729A77B2; Sat, 13 Jul 2013 16:39:36 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA8F18B5; Sat, 13 Jul 2013 16:39:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id 925B52B43283; Sat, 13 Jul 2013 18:39:32 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2ThyXa+wBmu; Sat, 13 Jul 2013 18:39:30 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 940F42B43262; Sat, 13 Jul 2013 18:39:30 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uy2r2-0003r7-0x; Sat, 13 Jul 2013 18:39:28 +0200 To: Konstantin Belousov From: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 In-Reply-To: <20130713100337.GK91021@kib.kiev.ua> References: <20130713100337.GK91021@kib.kiev.ua> <20130713054220.GJ91021@kib.kiev.ua> <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> X-Attribution: BOFH Date: Sat, 13 Jul 2013 18:39:28 +0200 Message-Id: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 16:39:36 -0000 Konstantin Belousov wrote: > > Yes. This state of affairs doesn't happen on r251445 and further > > testing on my side shows it doesn't hapen on all my amd64 servers. > > It appears that this particular server type (Dell R200) running > > amd64 with geom_mirror is affected. I will have to test further > > by destroying the mirror and removing it from the kernel and see > > if I can still reproduce the issue. Perhaps r251446 exposes > > insufficient locking on opperations affecting these variables. > No. The lorunningspace is constant for the system lifetime. > It can only be changed by the sysctl vfs.lorunningspace. > Look into /etc/sysctl.conf or scripts which apply sysctl settings. Wipes egg from face. /etc/sysctl.conf: vfs.hirunningspace=4194304 So, then did r251446 actually start using this value or did other values get significantly tuned up? I recall now setting this nearly a year ago when we did our ZFS tuning and it was a four fold increase on the defaults. Sorry for the noise. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 16:46:31 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A95A8FB; Sat, 13 Jul 2013 16:46:31 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 472C618E4; Sat, 13 Jul 2013 16:46:31 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id r6DGkUuP011313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Jul 2013 11:46:30 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sat, 13 Jul 2013 11:46:29 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOA Date: Sat, 13 Jul 2013 16:46:29 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-13_06:2013-07-12,2013-07-13,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 16:46:31 -0000 On Jul 13, 2013, at 8:17 AM, Teske, Devin wrote: On Jul 13, 2013, at 1:07 AM, Baptiste Daroussin wrote: On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: Hi, I have just committed (r253305) a change the make pkg_install not being bui= lt and installed by default on HEAD. If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes in y= our src.conf(5) [snip] I for one am effected and will have to change things. If you are referring to bsdconfig's package management, [snip] Yes. that's what I'm talking about. [snip] it is not working anyway HEAD as we do not and will not provides any pkg_install for HEAD via any of= the usual distribution process: http, ftp, CD. The FTP mirror of packages is going away? (if you said yes and pointed at a= prior conversation about leading up to this, I would not be surprised -- I= 'm just questioning it because I don't see the value in pairing-down method= s of acquisition) If this is the case, what's the surviving acquisition method? A custom TCP = protocol perhaps? There may be those that wish to use pkg in the pkg_add manner and download = things and then inspect them manually before adding them. For example, I of= ten go the freshports.org to find a package that fil= ls a need... download it from the official FTP server(s), inspect all of th= em, and choose the one that best fits me need (and only then installing fro= m the local file; tossing the rest). If I go through the "pkg" tool, I have= to inspect things *after* they've been installed which is not to my satisf= action. [snip bsdconfig is not installed by default, Wrong, please see... http://svnweb.freebsd.org/base?view=3Drevision&revision=3D252862 [snip] The first thing that comes to mind in reprogramming bsdconfig's package man= agement for pkgng... We have a *very* large list of FTP mirrors. This will presumably be replace= d with a list of "pkg" mirrors. Do we have such a list that we want to program into the base configuration = of bsdconfig? -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 16:48:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F3E1A18; Sat, 13 Jul 2013 16:48:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2089B18FD; Sat, 13 Jul 2013 16:48:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6DGmENX010088; Sat, 13 Jul 2013 19:48:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6DGmENX010088 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6DGmElm010087; Sat, 13 Jul 2013 19:48:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Jul 2013 19:48:14 +0300 From: Konstantin Belousov To: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 Message-ID: <20130713164814.GM91021@kib.kiev.ua> References: <20130713054220.GJ91021@kib.kiev.ua> <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V9aszxPoayjYMR8r" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 16:48:24 -0000 --V9aszxPoayjYMR8r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 13, 2013 at 06:39:28PM +0200, Ian FREISLICH wrote: > Konstantin Belousov wrote: > > > Yes. This state of affairs doesn't happen on r251445 and further > > > testing on my side shows it doesn't hapen on all my amd64 servers. > > > It appears that this particular server type (Dell R200) running > > > amd64 with geom_mirror is affected. I will have to test further > > > by destroying the mirror and removing it from the kernel and see > > > if I can still reproduce the issue. Perhaps r251446 exposes > > > insufficient locking on opperations affecting these variables. > > No. The lorunningspace is constant for the system lifetime. > > It can only be changed by the sysctl vfs.lorunningspace. > > Look into /etc/sysctl.conf or scripts which apply sysctl settings. >=20 > Wipes egg from face. >=20 > /etc/sysctl.conf: >=20 > vfs.hirunningspace=3D4194304 >=20 > So, then did r251446 actually start using this value or did other > values get significantly tuned up? I recall now setting this nearly > a year ago when we did our ZFS tuning and it was a four fold increase > on the defaults. r251446 optimized the wakeups by only doing wakeups when runningbufspace actually crossed the lorunningspace. Before, wakeups were performed always on the runningbufspace changes. For ZFS, these settings are completely irrelevant, ZFS does not use buffer cache. --V9aszxPoayjYMR8r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4YTNAAoJEJDCuSvBvK1BNi4P/0wsjlnSlpPtxr4JBaANzOLg NaRIT0ClVuXFF176Bm+mre1MMkCgq4Y6phxnwEk0Iab7Ml0Bfjp+9gDJjmNT3DN0 xledgFQkcM7G8yWqRVepsadWrUkJdNH7xcvb5ZqN89m7sxfaOeVvCmCDGAu3oAj5 iSOy9MkTCeH0OrOxgIN3DI1r8dqWELjOx0NTKVujPF1KvOFgBqSkLZUU/aQQaVad zxGI7h5pt7C73MT6HDsnQWcte4Cm2moigLZy4S3uS1WMeKP55dFZl/yKq69WOcvX Tv10IT+WpdxJz8apO42oTo/vbFS2vMh3D5G4kJVUTAj2eO9uagPbRkL/xW1og/Cw 0xWCDYnIzNB42DLz//S30wCvmzijWOldufu2AZsmnrO+IPm0niTgHPU6BR1oZD4i Ex3Yrqx+bxrRniAlaxGNmRNeoR8LZercVrzmRBQ3p5mExzYhYOJg3iblTsAHXPCs MpqXiHt/TfzT/a+AnD16Mr1+kTzjTmt2/tawHpp6ITjjmBVUQrYdF7USv95mHE5V cP6V2PBEgbEAjkLAi9J/mJw4PQq0wYrFIQVJlbQ3/5Xhwx2LNBeqokJMtHBdQT16 Y9k8hQuhST14HZOfRPoZ8zhPy+if/JsTDS1kE/ij93tU+gLl6ryoKNp7TjLB68vx eqrvkJucZK7bLwRr1S6f =aDN7 -----END PGP SIGNATURE----- --V9aszxPoayjYMR8r-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 16:55:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 10B3BC41 for ; Sat, 13 Jul 2013 16:55:14 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB139192E for ; Sat, 13 Jul 2013 16:55:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:a8be:8596:6f0d:32f3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 96AE04AC1C; Sat, 13 Jul 2013 20:55:12 +0400 (MSK) Date: Sat, 13 Jul 2013 20:55:03 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <12010148266.20130713205503@serebryakov.spb.ru> To: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 In-Reply-To: References: <20130713100337.GK91021@kib.kiev.ua> <20130713054220.GJ91021@kib.kiev.ua> <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@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: Sat, 13 Jul 2013 16:55:14 -0000 Hello, Ian. You wrote 13 =D0=B8=D1=8E=D0=BB=D1=8F 2013 =D0=B3., 20:39:28: IF> So, then did r251446 actually start using this value or did other IF> values get significantly tuned up? According to diff between 45 and 46 here are a lot of conditions on hirunningspace in code now, which were absent in past. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 17:29:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6E6445D; Sat, 13 Jul 2013 17:29:41 +0000 (UTC) (envelope-from ianf@cloudseed.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 706831A2F; Sat, 13 Jul 2013 17:29:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id DBA962B43283; Sat, 13 Jul 2013 19:29:39 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAnb8fEPSe0X; Sat, 13 Jul 2013 19:29:38 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 6A9412B43262; Sat, 13 Jul 2013 19:29:38 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uy3dY-0003tu-En; Sat, 13 Jul 2013 19:29:36 +0200 To: Konstantin Belousov From: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 In-Reply-To: <20130713164814.GM91021@kib.kiev.ua> References: <20130713164814.GM91021@kib.kiev.ua> <20130713054220.GJ91021@kib.kiev.ua> <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> X-Attribution: BOFH Date: Sat, 13 Jul 2013 19:29:36 +0200 Message-Id: X-Mailman-Approved-At: Sat, 13 Jul 2013 17:33:04 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 17:29:41 -0000 Konstantin Belousov wrote: > > So, then did r251446 actually start using this value or did other > > values get significantly tuned up? I recall now setting this nearly > > a year ago when we did our ZFS tuning and it was a four fold increase > > on the defaults. > > r251446 optimized the wakeups by only doing wakeups when runningbufspace > actually crossed the lorunningspace. Before, wakeups were performed > always on the runningbufspace changes. > > For ZFS, these settings are completely irrelevant, ZFS does not use > buffer cache. A year is so long ago... It might have been tuning for our postgres servers. It might be worth while putting in a sanity check that doesn't allow hirunningspace to be set lower than lorunningspace. Thanks for your patience. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 18:16:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5D3247AC; Sat, 13 Jul 2013 18:16:19 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id F381A1BB1; Sat, 13 Jul 2013 18:16:18 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id hu16so918313qab.1 for ; Sat, 13 Jul 2013 11:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MB6StIhO4a8Xv1x52eX3kzO0pPGm32iTW+FGClJRwl4=; b=giAUsVi8SQGacZ4pNoZsG4YVzoIZyxfA/kcgNlB1L8vb7YelUaV3pQPcMkuw1//7Ac mDqVDFa0/9A+awcUzkLV5Uk0/oGiJ6A+PG8HbaUSjaraHX5kqvD5rNZb0D8R9MmyY+vj uQHe3/Y8kskocMQ4+CrUO441aM9x25I22sjYZV85ZxqHB7u3i22e7w5YaL4q/Eh+/Zpj WBBa8cdM7kTmBRm75BK3QiiQ8a6wrs+yOeYOlFwRIx3V5DwLFHsJIbJk3pRkOTanhs8C GlyKSQIm4BCqR0rfHQXXFDUZKEaiiEFcyYhj2tJR/x6cM9K8dX5XEtqCQow+UFwfOhpY 3+LA== MIME-Version: 1.0 X-Received: by 10.229.134.2 with SMTP id h2mr8365062qct.94.1373739378484; Sat, 13 Jul 2013 11:16:18 -0700 (PDT) Received: by 10.224.138.78 with HTTP; Sat, 13 Jul 2013 11:16:18 -0700 (PDT) In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> Date: Sat, 13 Jul 2013 21:16:18 +0300 Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Kimmo Paasiala To: Devin Teske Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Baptiste Daroussin , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 18:16:19 -0000 On Sat, Jul 13, 2013 at 7:46 PM, Teske, Devin w= rote: > > On Jul 13, 2013, at 8:17 AM, Teske, Devin wrote: > > > On Jul 13, 2013, at 1:07 AM, Baptiste Daroussin wrote: > > On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: > On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: > > Hi, > > I have just committed (r253305) a change the make pkg_install not being b= uilt > and installed by default on HEAD. > > If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes in= your > src.conf(5) > > [snip] > > I for one am effected and will have to change things. > > If you are referring to bsdconfig's package management, > > [snip] Yes. that's what I'm talking about. [snip] > > > it is not working anyway > HEAD as we do not and will not provides any pkg_install for HEAD via any = of the > usual distribution process: http, ftp, CD. > > > > The FTP mirror of packages is going away? (if you said yes and pointed at= a prior conversation about leading up to this, I would not be surprised --= I'm just questioning it because I don't see the value in pairing-down meth= ods of acquisition) > > If this is the case, what's the surviving acquisition method? A custom TC= P protocol perhaps? > > There may be those that wish to use pkg in the pkg_add manner and downloa= d things and then inspect them manually before adding them. For example, I = often go the freshports.org to find a package that f= ills a need... download it from the official FTP server(s), inspect all of = them, and choose the one that best fits me need (and only then installing f= rom the local file; tossing the rest). If I go through the "pkg" tool, I ha= ve to inspect things *after* they've been installed which is not to my sati= sfaction. > > > [snip > bsdconfig is not installed by > default, > > Wrong, please see... > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D252862 > [snip] > > The first thing that comes to mind in reprogramming bsdconfig's package m= anagement for pkgng... > > We have a *very* large list of FTP mirrors. This will presumably be repla= ced with a list of "pkg" mirrors. > > Do we have such a list that we want to program into the base configuratio= n of bsdconfig? > -- > Devin > Come on, this only concerns 10-CURRENT. Where is it stated that the FTP mirrors for FreeBSD 8/9 packages are going away? -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 18:54:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBB611D8; Sat, 13 Jul 2013 18:54:24 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 885B21CB6; Sat, 13 Jul 2013 18:54:24 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r6DIsNED018490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Jul 2013 13:54:23 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sat, 13 Jul 2013 13:54:23 -0500 From: "Teske, Devin" To: Kimmo Paasiala Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgA== Date: Sat, 13 Jul 2013 18:54:21 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-13_07:2013-07-12,2013-07-13,1970-01-01 signatures=0 Cc: Baptiste Daroussin , Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 18:54:24 -0000 On Jul 13, 2013, at 11:16 AM, Kimmo Paasiala wrote: > On Sat, Jul 13, 2013 at 7:46 PM, Teske, Devin = wrote: >>=20 >> On Jul 13, 2013, at 8:17 AM, Teske, Devin wrote: >>=20 >>=20 >> On Jul 13, 2013, at 1:07 AM, Baptiste Daroussin wrote: >>=20 >> On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: >> On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: >>=20 >> Hi, >>=20 >> I have just committed (r253305) a change the make pkg_install not being = built >> and installed by default on HEAD. >>=20 >> If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes i= n your >> src.conf(5) >>=20 >> [snip] >>=20 >> I for one am effected and will have to change things. >>=20 >> If you are referring to bsdconfig's package management, >>=20 >> [snip] Yes. that's what I'm talking about. [snip] >>=20 >>=20 >> it is not working anyway >> HEAD as we do not and will not provides any pkg_install for HEAD via any= of the >> usual distribution process: http, ftp, CD. >>=20 >>=20 >>=20 >> The FTP mirror of packages is going away? (if you said yes and pointed a= t a prior conversation about leading up to this, I would not be surprised -= - I'm just questioning it because I don't see the value in pairing-down met= hods of acquisition) >>=20 >> If this is the case, what's the surviving acquisition method? A custom T= CP protocol perhaps? >>=20 >> There may be those that wish to use pkg in the pkg_add manner and downlo= ad things and then inspect them manually before adding them. For example, I= often go the freshports.org= to find a package that fills a need... download it from the official FTP s= erver(s), inspect all of them, and choose the one that best fits me need (a= nd only then installing from the local file; tossing the rest). If I go thr= ough the "pkg" tool, I have to inspect things *after* they've been installe= d which is not to my satisfaction. >>=20 >>=20 >> [snip >> bsdconfig is not installed by >> default, >>=20 >> Wrong, please see... >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D252862 >> [snip] >>=20 >> The first thing that comes to mind in reprogramming bsdconfig's package = management for pkgng... >>=20 >> We have a *very* large list of FTP mirrors. This will presumably be repl= aced with a list of "pkg" mirrors. >>=20 >> Do we have such a list that we want to program into the base configurati= on of bsdconfig? >> -- >> Devin >>=20 >=20 > Come on, this only concerns 10-CURRENT. Right; which is why -current is CC'd. > Where is it stated that the > FTP mirrors for FreeBSD 8/9 packages are going away? >=20 I don't know where you got the impression that I was concerned with 8/9 pac= kages. I'm strictly concerned with HEAD and strictly concerned with planning for t= he future. So yes... I'm asking... in a HEAD world, what is the "officially supported"= method of acquisition? I saw mention on a page that "rsync access will provided for those who want= to mirror" but my I'm not really interested in mirroring while I would lik= e to continue to be able to grab packages myself without installing them. Maybe the answer is that "pkg" has a method of acquiring a single package (= without dependencies) without downloading it. That would solve my personal = workflow issue (again, I like to download tarballs, inspect them, and then = install them from the locally downloaded file -- then if it passes validati= on tests, that downloaded file is migrated to our own distribution servers;= it's a work-flow for validating packages -- it has less to do with how pkg= ng works and more just whether I can get packages in a fashion such as FTP = or HTTP or whatever. Now that aside, bsdconfig currently is a different story. To rewrite the pa= ckages module to work in a HEAD world for HEAD, using pkgng servers, I'm go= ing to have to change the way things are done. Currently there is an abstra= ction layer for fetching packages from media (which can be FTP, HTTP, HTTP = Proxy, NFS, Local Directory, CDROM, a DOS partition, a UFS partition, and [= god forbid] Floppy -- with perhaps SMB/CIFS down the road). When it wants t= o add a package, it calls the routine to get the package data by name on st= andard-out and pumps it into pkg_add (after of course initializing the medi= a). This abstraction layer is useful to pkgng as it prepares the source. What I= *suspect* will have to stop happening is the direct-fetching of the packag= e data and piping that into a program (however, I *could* continue to do th= at .. "pkg" supports adding of local packages and iirc supports reading fro= m standard-in). Instead, perhaps just call "pkg" in a small-handful of diff= erent ways (pointed at an ftp server; pointed at a local file; pointed at h= ttp; etc.). But the preparation of an NFS mount would be handled by the abs= traction layer leading up to the calling of pkg. That issue aside (whether to have pkg do the bidding or to use the existing= abstraction framework to fetch the file), there are benefits to each route. I'm leaning the latter route (of having bsdconfig's abstraction layer do th= e fetching and simply have pkg add a file from stdin) because I can then wr= ite a program that is essentially a more advanced version of sysutils/pv (a= nd would be BSD licensed). There are certainly things that pkg can excel at that the latter method may= by-pass (which might make it undesirable). For example, bsdconfig currentl= y reads the INDEX file and handles dependencies itself. It could continue t= o do this, but we want pkg to handle the dependencies. If I chose to continue to do things in this manner, it would be bad (I esti= mate) because I believe that shoving dependencies into pkg in an ordered fa= shion before adding the requested package would ultimately cause the depend= encies to _not_ be recognized as leaves (correct me if I'm wrong), meaning = that something like "cutleaves" wouldn't be able to prune them from the thr= ee after the dependencies have been gone. So to take full advantage of all the features of pkg, I think I'll relegate= the idea of a sysutils/pv to working for the distfetch side of things (ano= ther topic) and just wield pkg in one of a small-handful of ways pointed di= rectly at media. Which brings us back around to the question at hand... Does it support FTP? HTTP? HTTP Proxy? Local File? (that's about all that I= need -- the last-one... Local File would be for repositories mounted via t= he preparation-framework which is part of the abstraction layer -- we'd jus= t ignore the acquisition methods thereof). If FTP access (or any of the other remote access methods) are going away fo= r HEAD pkg access, I'll need to know so I can make the appropriate changes = in the HEAD branch of bsdconfig. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 20:12:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 253C92E5; Sat, 13 Jul 2013 20:12:27 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id D53441E8C; Sat, 13 Jul 2013 20:12:26 +0000 (UTC) Received: from rnote.ddteam.net (44-80-135-95.pool.ukrtel.net [95.135.80.44]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 98129C492D; Sat, 13 Jul 2013 23:12:18 +0300 (EEST) Date: Sat, 13 Jul 2013 23:12:10 +0300 From: Aleksandr Rybalko To: Lars Engels Subject: Re: FreeBSD-head hang when shutdown by ACPI with Intel GPU and new Xorg and SandyBridge Message-Id: <20130713231210.4b92aaf2.ray@freebsd.org> In-Reply-To: <20130712160547.GP88288@e-new.0x20.net> References: <1601171.hWXcdG7J9D@notebook.alkar.net> <22CEA4A9-5C63-4561-8663-42F8623F1D97@FreeBSD.org> <20130712160547.GP88288@e-new.0x20.net> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , "freebsd-x11@freebsd.org" , FreeBSD Current , David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 20:12:27 -0000 On Fri, 12 Jul 2013 18:05:47 +0200 Lars Engels wrote: > On Fri, Jul 12, 2013 at 11:26:06AM +0100, David Chisnall wrote: > > On 12 Jul 2013, at 10:01, "Lundberg, Johannes" > > wrote: > > > > >> As the KMS code does not switch the display mode back, once X > > >> with KMS > > > starts, you can't get a console back. > > > > > > Is there any solution for this in the works? > > > > Yes. ray@ is currently being funded by the FreeBSD Foundation to > > improve Newcons compatibility with KMS. The Newcons framework is > > designed to improve layering in the console. The machine-dependent > > part simply provides a framebuffer interface, the > > machine-independent part provides the terminal emulator (this also > > means things like unicode in the console will work, as will > > higher-resolution consoles). It's currently used on a few non-x86 > > platforms, but it wasn't a priority for x86 because the PC BIOS > > text console mostly works and people who want a better terminal can > > just run X. It's now become a priority because of the KMS > > integration with X.org. Once this work is completed, we will > > switch to a new X.org by default and will use the KMS interface > > within the kernel for selecting the video mode. > > Is there a rough ETA for this great improvement? I hope first things to test will be available on begin of the August. But it is just hope yet :) Thanks. -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 23:51:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4EFB67C8 for ; Sat, 13 Jul 2013 23:51:02 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 216881385 for ; Sat, 13 Jul 2013 23:51:01 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 63CFF28936 for ; Sat, 13 Jul 2013 19:51:00 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Sat, 13 Jul 2013 19:51:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= Xtycii5X9YUIklvvsds380NABJ0=; b=V4G1xXhH0ivJvBUiaqashxFnFtlprxHp xyqFDVD69fI4FSRPItSQa8IV1pz5AfEkrS8tl9AaCKIFGH5lo/Ti8imJUBfw1aGG yhrKhEOWRzigwyx22+GSqALmgwtYwO19xB9CiXvymlCCbh4qOf0wAZ+0LIR2VJx7 O3CkW7ZuZ4I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=Xtycii5X9YUIklvvsds380NABJ0=; b=b1j z8P9NEBrmV7tMV5xPxiIVM+EpoOQfxXN638mtAnMU4IN9O24uY2PbQXQO16psW72 gMbv/tYMN5/K4rf6HegIxq4d32THCo+XYsevOCSDIo7iL99CRYLY/Oq9oZQit9ic XwS9wsRc3P77EDsfLbGvZbFD4y0PsQFFqtYXEN/U= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 424E5B00003; Sat, 13 Jul 2013 19:51:00 -0400 (EDT) Message-Id: <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> X-Sasl-Enc: TSvs5wnrBwcU5ITntvkndveStbnsZA18fj+wicmddoj2 1373759460 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cea5092a In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Date: Sat, 13 Jul 2013 18:51:00 -0500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jul 2013 23:51:02 -0000 On Sat, Jul 13, 2013, at 13:54, Teske, Devin wrote: > > > If FTP access (or any of the other remote access methods) are going away > for HEAD pkg access, I'll need to know so I can make the appropriate > changes in the HEAD branch of bsdconfig. > It's simpler than you think. The new pkg uses libfetch. You can have your PACAKGESITE be file:// ftp:// http:// https:// ... I do suspect that HTTP_PROXY support is probably not available as I recall seeing a post where someone was asking about that getting implemented for fetch. I'll have to research that again, though.